Seems that the new release by default starts the Embedded Mongo when it's found on the classpath instead of using the mongo template defined in the application.properties.
The workaround is to temporary remove flapdoodle.embed from the dependency list even if it's in test scope
2020-06-24 09:22:53.048 INFO 51028 --- [ Thread-305] o.s.b.a.mongo.embedded.EmbeddedMongo : 2020-06-24T09:22:53.047+0200 I CONTROL [initandlisten] MongoDB starting : pid=51029 port=63665 dbpath=/var/folders/7x/ss8w17pd4bsfrg1x1t56sl00zq753h/T/embedmongo-db-20d4fbe0-abac-4715-8ae0-b863f7bc9627 64-bit host=M84452
This is discussed in https://github.com/spring-projects/sts4/issues/493.
The short version is that the behavior of the launch configs slightly changed due to the (now correct) usage of the "exclude test classes" checkbox of the Eclipse platform. Make sure that when you re-use existing launch configs that this checkbox is set correctly.
Related
So I deployed a build that runs perfectly on my windows machine to a Linux box earlier this morning and when I tried to start the service I got the error below.
Caused by: java.lang.IllegalStateException: AutoConfigure cycle detected between org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration and org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration
So I copied all of the libs from the target machine to my windows machine and ran the application from a windows command prompt. The application started fine.
So I eventually remote debugged the application and came up with a very interesting issue that has got my head scratching.
But before I went further I switched on -verbose to make sure the class in question was being loaded from the same jar in both windows and linux.
[Loaded org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration from file:/apps/IRDrsudbld/<project structure>/lib/spring-boot-autoconfigure-1.5.8.RELEASE.jar]
And it is.
So when I debug in linux and look at the metadata for the two classes
this = {AutoConfigurationSorter$AutoConfigurationClass#3645}
className = "org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration"
metadataReaderFactory = {ConcurrentReferenceCachingMetadataReaderFactory#3637}
autoConfigurationMetadata = {AutoConfigurationMetadataLoader$PropertiesAutoConfigurationMetadata#3611}
It states the following
"org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration.AutoConfigureBefore" -> "org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration"
"org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration.AutoConfigureAfter" -> "org.springframework.boot.autoconfigure.data.couchbase.CouchbaseDataAutoConfiguration,
org.springframework.boot.autoconfigure.hazelcast.HazelcastAutoConfiguration,
org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration,
org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration"
But the line in bold is completely wrong as the 1.5.8 source code has the annotations below.
#Configuration
#ConditionalOnClass({CacheManager.class})
#ConditionalOnBean({CacheAspectSupport.class})
#ConditionalOnMissingBean(value = {CacheManager.class},name = {"cacheResolver"})
#EnableConfigurationProperties({CacheProperties.class})
#AutoConfigureBefore({HibernateJpaAutoConfiguration.class})
#AutoConfigureAfter({CouchbaseAutoConfiguration.class, HazelcastAutoConfiguration.class,
RedisAutoConfiguration.class})
#Import({CacheAutoConfiguration.CacheConfigurationImportSelector.class})
public class CacheAutoConfiguration {
Has anyone seen an issue like this before as I am completely mystified as to what is happening here.
Thanks
After debugging the code it appears that one of the internal shaded jar files contains a spring-autoconfigure-metadata.properties which is for spring boot 2. When the application is executed on linux this jar file is loaded after the spring boot autoconfigure one and replaces the
org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration.AutoConfigureAfter
Property with one that is not valid for the spring boot version in my application.
At least I have found out what the problem is.
I have build a very simple project of hello world in
Payara 5 (5.181)
JSF 2.3
JDK 1.8
CDI 2.0
Maven
and encountered a problem
Unable to start server due following issues: Launch process failed with exit code 1
in console it throws an error of :
Error: Could not find or load main class server\payara5\glassfish.lib.grizzly-npn-bootstrap.jar
[PIC] Payara 5 Error
It seems that the Payara Tools for Eclipse suffer by several bugs that may cause this. In my case, the following workarounds helped:
The Payara installation path should not contain spaces (e.g. Program Files\Payara)
It seems that only Java 8 is supported at the time
Open the domain.xml configuration file for the domain you are trying to start (typically payara_install_path/glassfish/domains/domain1/config/domain1.xml) and search for "Xbootclasspath". You should find a couple of lines like
<jvm-options>[1.8.0|1.8.0u120]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.6.jar</jvm-options>
<jvm-options>[1.8.0u121|1.8.0u160]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.7.jar</jvm-options>
<jvm-options>[1.8.0u161|1.8.0u190]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.8.jar</jvm-options>
<jvm-options>[1.8.0u191|1.8.0u500]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.8.1.jar</jvm-options>
Depending of your installed Java version (try running java --version) and choose the appropriate line (most likely the last one). Remove the remaining lines and remove the [...] part at the beginning of the chosen line so you will get something like
<jvm-options>-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.8.1.jar</jvm-options>
After this, the tools seem to start normally.
The Problem is with Java version. The grizzly-npn-bootstrap-1.8.1.jar Jar is placed in bootclasspath, thats why it requires proper java version to start payara server. So remove unnecessary bootstrap jar from domain.xml.
In Windows:
1) Go To ---C:\Users\xxxx\payara5\glassfish\domains\domain1\config\domain.xml
2) According to my java verson(java version "1.8.0_191") I deleted the following lines from domain.xml. So delete according to your java version.
<jvm-options>[1.8.0|1.8.0u120]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.6.jar</jvm-options>
<jvm-options>[1.8.0u121|1.8.0u160]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.7.jar</jvm-options>
<jvm-options>[1.8.0u161|1.8.0u190]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.8.jar</jvm-options>
3) Remove this [1.8.0u191|1.8.0u500] part from jvm-options & Edit the line in your domain.xml(w.r.t java -version) as shown below
<jvm-options>-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.8.1.jar</jvm-options>
4) restart your server.
As Radkovo said, "The Payara installation path should not contain spaces (e.g. Program Files\Payara)", so I moved the Payara to the Documents folder.
Problem solved!
I'm using Intellij 13.1.5 on Ubuntu 14.0.4 (amd64), Maven 3.0.5, Java Oracle 1.7.0_72
I noticed some irregularities with maven whilst using Intellij namely dependencies added and removed where not reflected in the module or in the External Libaries listing.
Then when I ran Intellij from the shell I saw this exception:
[ 14649] WARN - #org.jetbrains.idea.maven - Cannot open index /home/sbotting/.IntelliJIdea13/system/Maven/Indices/Index0
org.jetbrains.idea.maven.indices.MavenIndexException: Cannot open index /home/sbotting/.IntelliJIdea13/system/Maven/Indices/Index0
at org.jetbrains.idea.maven.indices.MavenIndex.open(MavenIndex.java:164)
at org.jetbrains.idea.maven.indices.MavenIndex.<init>(MavenIndex.java:139)
at org.jetbrains.idea.maven.indices.MavenIndices.load(MavenIndices.java:59)
at org.jetbrains.idea.maven.indices.MavenIndices.<init>(MavenIndices.java:47)
at org.jetbrains.idea.maven.indices.MavenIndicesManager.ensureInitialized(MavenIndicesManager.java:107)
at org.jetbrains.idea.maven.indices.MavenIndicesManager.getIndicesObject(MavenIndicesManager.java:91)
at org.jetbrains.idea.maven.indices.MavenIndicesManager.ensureIndicesExist(MavenIndicesManager.java:164)
at org.jetbrains.idea.maven.indices.MavenProjectIndicesManager$3.run(MavenProjectIndicesManager.java:120)
at com.intellij.util.ui.update.MergingUpdateQueue.execute(MergingUpdateQueue.java:320)
at com.intellij.util.ui.update.MergingUpdateQueue.execute(MergingUpdateQueue.java:310)
at com.intellij.util.ui.update.MergingUpdateQueue$2.run(MergingUpdateQueue.java:254)
at com.intellij.util.ui.update.MergingUpdateQueue.flush(MergingUpdateQueue.java:269)
at com.intellij.util.ui.update.MergingUpdateQueue.flush(MergingUpdateQueue.java:227)
at com.intellij.util.ui.update.MergingUpdateQueue.run(MergingUpdateQueue.java:217)
at com.intellij.util.concurrency.QueueProcessor.runSafely(QueueProcessor.java:238)
at com.intellij.util.Alarm$Request$1.run(Alarm.java:327)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at com.intellij.util.concurrency.QueueProcessor$RunnableConsumer.consume(QueueProcessor.java:298)
at com.intellij.util.concurrency.QueueProcessor$RunnableConsumer.consume(QueueProcessor.java:295)
at com.intellij.util.concurrency.QueueProcessor$2$1.run(QueueProcessor.java:110)
at com.intellij.util.concurrency.QueueProcessor.runSafely(QueueProcessor.java:238)
at com.intellij.util.concurrency.QueueProcessor$2.consume(QueueProcessor.java:107)
at com.intellij.util.concurrency.QueueProcessor$2.consume(QueueProcessor.java:104)
at com.intellij.util.concurrency.QueueProcessor$3$1.run(QueueProcessor.java:215)
at com.intellij.util.concurrency.QueueProcessor.runSafely(QueueProcessor.java:238)
at com.intellij.util.concurrency.QueueProcessor$3.run(QueueProcessor.java:212)
at com.intellij.openapi.application.impl.ApplicationImpl$8.run(ApplicationImpl.java:419)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
Caused by: java.lang.RuntimeException: Cannot reconnect.
at org.jetbrains.idea.maven.server.RemoteObjectWrapper.perform(RemoteObjectWrapper.java:111)
at org.jetbrains.idea.maven.server.MavenIndexerWrapper.createIndex(MavenIndexerWrapper.java:61)
at org.jetbrains.idea.maven.indices.MavenIndex.createContext(MavenIndex.java:305)
at org.jetbrains.idea.maven.indices.MavenIndex.access$500(MavenIndex.java:40)
at org.jetbrains.idea.maven.indices.MavenIndex$IndexData.<init>(MavenIndex.java:611)
at org.jetbrains.idea.maven.indices.MavenIndex.doOpen(MavenIndex.java:185)
at org.jetbrains.idea.maven.indices.MavenIndex.open(MavenIndex.java:161)
... 33 more
Caused by: java.rmi.RemoteException: Cannot start maven service; nested exception is:
com.intellij.execution.ExecutionException: -Xmixed mixed mode execution (default)
-Xint interpreted mode execution only
-Xbootclasspath:<directories and zip/jar files separated by :>
set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by :>
append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by :>
prepend in front of bootstrap class path
-Xdiag show additional diagnostic messages
-Xnoclassgc disable class garbage collection
-Xincgc enable incremental garbage collection
-Xloggc:<file> log GC status to a file with time stamps
-Xbatch disable background compilation
-Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size
-Xss<size> set java thread stack size
-Xprof output cpu profiling data
-Xfuture enable strictest checks, anticipating future default
-Xrs reduce use of OS signals by Java/VM (see documentation)
-Xcheck:jni perform additional checks for JNI functions
-Xshare:off do not attempt to use shared class data
-Xshare:auto use shared class data if possible (default)
-Xshare:on require using shared class data, otherwise fail.
-XshowSettings show all settings and continue
-XshowSettings:all
show all settings and continue
-XshowSettings:vm show all vm related settings and continue
-XshowSettings:properties
show all property settings and continue
-XshowSettings:locale
show all locale related settings and continue
The -X options are non-standard and subject to change without notice
at org.jetbrains.idea.maven.server.MavenServerManager.create(MavenServerManager.java:124)
at org.jetbrains.idea.maven.server.MavenServerManager.create(MavenServerManager.java:65)
at org.jetbrains.idea.maven.server.RemoteObjectWrapper.getOrCreateWrappee(RemoteObjectWrapper.java:41)
at org.jetbrains.idea.maven.server.MavenServerManager$5.create(MavenServerManager.java:387)
at org.jetbrains.idea.maven.server.MavenServerManager$5.create(MavenServerManager.java:383)
at org.jetbrains.idea.maven.server.RemoteObjectWrapper.getOrCreateWrappee(RemoteObjectWrapper.java:41)
at org.jetbrains.idea.maven.server.MavenIndexerWrapper.getRemoteId(MavenIndexerWrapper.java:159)
at org.jetbrains.idea.maven.server.MavenIndexerWrapper.access$100(MavenIndexerWrapper.java:37)
at org.jetbrains.idea.maven.server.MavenIndexerWrapper$1.execute(MavenIndexerWrapper.java:64)
at org.jetbrains.idea.maven.server.RemoteObjectWrapper.perform(RemoteObjectWrapper.java:105)
... 39 more
Caused by: com.intellij.execution.ExecutionException: -Xmixed mixed mode execution (default)
-Xint interpreted mode execution only
-Xbootclasspath:<directories and zip/jar files separated by :>
set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by :>
append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by :>
prepend in front of bootstrap class path
-Xdiag show additional diagnostic messages
-Xnoclassgc disable class garbage collection
-Xincgc enable incremental garbage collection
-Xloggc:<file> log GC status to a file with time stamps
-Xbatch disable background compilation
-Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size
-Xss<size> set java thread stack size
-Xprof output cpu profiling data
-Xfuture enable strictest checks, anticipating future default
-Xrs reduce use of OS signals by Java/VM (see documentation)
-Xcheck:jni perform additional checks for JNI functions
-Xshare:off do not attempt to use shared class data
-Xshare:auto use shared class data if possible (default)
-Xshare:on require using shared class data, otherwise fail.
-XshowSettings show all settings and continue
-XshowSettings:all
show all settings and continue
-XshowSettings:vm show all vm related settings and continue
-XshowSettings:properties
show all property settings and continue
-XshowSettings:locale
show all locale related settings and continue
The -X options are non-standard and subject to change without notice.
at com.intellij.execution.rmi.RemoteProcessSupport.acquire(RemoteProcessSupport.java:142)
at org.jetbrains.idea.maven.server.MavenServerManager.create(MavenServerManager.java:121)
... 48 more
I've tried deleting the ~/.IntelliJIdea13/system/Maven/
with no result
My M2_HOME is properly set to /usr/share/maven
I assume that the solution lies in finding the underlying cause for the ExecutionException although the diagnostic doesn't really help with this.
I've tried reverting back to Intellij 12.0.4 and it works fine (in terms of Maven - although sadly it doesn't support svn 1.8)
also the output seems to come from the java -X command which gives you a printout of all the -X options
Any suggestions?
I had this problem all of a sudden (after an update + Windows Update). I tried a lot of things, and in the end, set Settings > Build, Execution, Deployment > Build Tools > Maven > Importing > JDK for Importer to Use JAVA_HOME (which I've set up as an env var pointing to a JDK install). That seems to work.
Go to file and select the project from the menu structure.
Then change the JDK version form the list of JDKs.
In the Settings > Maven > Importing in box for "VM options for importer:" box I had -Xmx512m -X
for some reason there was a loose -X I removed that and everything is now working fine.
My hosts file lack of the line:
127.0.0.1 localhost
lead to this problem.
I had this issue and it was due to me changing the JDK for importing in Intellij
I changed it from using internal JRE to java 1.8.0_74
I changed this back to use the Internal JRE of intellij and it worked.
Didn't need to change anything with my .m2 settings
Using version 3.7 of equinox I can set :
Constants.FRAMEWORK_STORAGE_CLEAN, "true" and
"osgi.console", consolePortasString()
With equinox version 3.9 setting FRAMEWORK_STORAGE_CLEAN to "true" does not work but setting to "onFirstInit" does.
Has the "true"setting been intentionally dropped from equinox?
Also the console port setting does not work in 3.9.
What is the suggested/intended method for setting these values in 3.9?
I am using WebLogic 10.3 with a Java EE application. Can anyone please tell me how to debug this application?
I think the other answers are somewhat wrong. For windows, if you setup an environment variable called debugFlag to be true or in solaris/unix do the same
debugFlag=true
export debugFlag
DEBUG_PORT=8453
export DEBUG_PORT
, then setDomainEnv.sh or setDomainEnv.cmd are going to be called to start WLS by the other scripts. They look for the debugFlag and DEBUG_PORT, as long as the "production" flag is not set it will pick up the right parameters from the script for debugging (-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=%DEBUG_PORT%,server=y,suspend=n -Djava.compiler=NONE).
YOU SHOULD NOT BE HACKING THESE SCRIPTS. It's going to make deployment and maintenance hard, the entire purpose of the setDomainEnv script is so that the right defaults are used and maintained across the cluster and throughout the entire environment. They are poorly documented I admit.
Note, if you are using the Oracle weblogic maven plugin, the target wls:deploy or wls:start-server will then pick up those environment settings when starting because they call the commands under the hood, and those in turn first call setDomainEnv.
As of right now, if you are using eclipse and have set up a Oracle WebLogicServer, the maven plugin will not attach to it into debug mode when you issue a mvn:deploy, you can either restart it in debug mode (silly), or create a 'Run ==> Debug ==> DebugConfigurations ==> RemoteJavaApplication' with a connection type of 'standard (socket attach)', a host of 'localhost' (or the remote server) and a port (default for me is '8453'). You can then do Run ==> Debug Configurations ==> Local Server Attach.
For me this worked:
In the folder WEBLOGIC_HOME\user_projects\domains\my_domain\bin
There is a file setDomainEnv.cmd
In it I found the code:
if "%debugFlag%"=="true" (
set JAVA_DEBUG=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=%DEBUG_PORT%,server=y,suspend=n -Djava.compiler=NONE
set JAVA_OPTIONS=%JAVA_OPTIONS% %enableHotswapFlag% -ea -da:com.bea... -da:javelin... -da:weblogic... -ea:com.bea.wli... -ea:com.bea.broker... -ea:com.bea.sbconsole...
) else (
set JAVA_OPTIONS=%JAVA_OPTIONS% %enableHotswapFlag% -da
)
I just put the lines for debug outside the if clause:
set JAVA_DEBUG=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=%DEBUG_PORT%,server=y,suspend=n -Djava.compiler=NONE
set JAVA_OPTIONS=%JAVA_OPTIONS% %enableHotswapFlag% -ea -da:com.bea... -da:javelin... -da:weblogic... -ea:com.bea.wli... -ea:com.bea.broker... -ea:com.bea.sbconsole...
if "%debugFlag%"=="true" (
set JAVA_DEBUG=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=%DEBUG_PORT%,server=y,suspend=n -Djava.compiler=NONE
set JAVA_OPTIONS=%JAVA_OPTIONS% %enableHotswapFlag% -ea -da:com.bea... -da:javelin... -da:weblogic... -ea:com.bea.wli... -ea:com.bea.broker... -ea:com.bea.sbconsole...
) else (
set JAVA_OPTIONS=%JAVA_OPTIONS% %enableHotswapFlag% -da
)
After these settings you can debug on port 8453
The port is also configured in this file, you can also change it:
if "%DEBUG_PORT%"=="" (
set DEBUG_PORT=8453
)
Stop the server, run the script, start the server.
Now your weblogic server is setup for debugging.
The best approach to enable debug on weblogic server is as follows:
create a script file
put these lines into your script (for windows):
set debugFlag=true
set DEBUG_PORT=9001
call the start script (e.g.): C:\Oracle\Middleware\user_projects\domains\domain1\bin\startWebLogic.cmd)
So, there will be 3 lines on the script, that's all you need...
There are also more variables you can use....
WLS_REDIRECT_LOG=log_path <- redirect output to a file instead of console window...
JAVA_OPTIONS <- more options for the JVM
EXTRA_JAVA_PROPERTIES <- define aditional properties you may need
What I did to get the Eclipse Debugger working with Weblogic 10 was to lookup the startWeblogic.cmd file in the folder weblogic.10.3.3.0\user_projects\domains\base_domain\bin\ and modify the following line (around line 95):
set JAVA_OPTIONS=%SAVE_JAVA_OPTIONS%
to
set JAVA_OPTIONS=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8453,server=y,suspend=n %SAVE_JAVA_OPTIONS%
Then I stopped any weblogic server that was running from within Eclipse and started Weblogic using the startWebLogic.cmd file.
Then I created a new debug configuration in Eclipse. Go to debug configurations, choose 'Remote Java Application', it should recognize your project, use Standard (Socket attach) for the connection type and specify port 8453 in the connection properties.
Now apply and run. Set some breakpoints in a piece of code that will regularly run and see if it is working.
Try remote debugging the application. You can try these links, thay may be helpful:
http://download.oracle.com/docs/cd/E15051_01/wlw/docs103/guide/ideuserguide/servers/conWebLogicServer.html#DebugRemote
http://eclipse.sys-con.com/node/169364
http://www.jacoozi.com/index.php?option=com_content&task=view&id=119&Itemid=134
Jonnathan Q answer helped me to launch Weblogic in debug mode also. For unix you can use the syntax like this in shell scripts:
debugFlag=true
export debugFlag
DEBUG_PORT=9001
export DEBUG_PORT
and then run startWeblogic.sh and startManagedWeblogic.sh if necessary.
UPDATE: to make our IDEs (Eclipse, IDEA) to stop on breakpoints we deployed our webapp on AdminServer, because in case of deploying to the node in clustered environment our IDEs didn't stop at breakpoints at all.