Please help me to find out the reason of the following behaviour.
I have two applications running in Tomcat container: my application and Hudson (v2.2.0). Tomcat is started with -Dhttp.proxyHost=proxy -Dhttp.proxyPost=8080 options so that my application uses proxy to access external WebServices.
I have detected the following very strange behaviour of Hudson running a maven build: At some point of time (just before maven is launched), the http.proxyHost system property is set to null. Perhaps I am following the wrong trace, by my application (which is deployed to the same Tomcat) crashes as it cannot open the connection and I think this two are relative.
I have installed the custom ProxySelector to report when the proxy is reset. It looks like http.proxyHost is reset just before maven starts the dependency resolving:
15.12 10:13:35 DEBUG [org.CustomProxySelector] Using proxy DIRECT for URL http://repo.internal/nexus/content/groups/development/org/parent/1.0.0-SNAPSHOT/maven-metadata.xml.sha1. Proxy settings: http.proxyHost=null, ftp.proxyHost=proxy
java.lang.Exception
at org.CustomProxySelector.select(CustomProxySelector.java:42)
at org.CustomProxySelector.select(CustomProxySelector.java:38)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:906)
at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:836)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1172)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:115)
at org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116)
at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88)
at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.verifyChecksum(WagonRepositoryConnector.java:708)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.run(WagonRepositoryConnector.java:625)
at org.sonatype.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:64)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
15.12 10:13:35 INFO [hudson.maven.MavenModuleSetBuild] using maven 3 3.0.3
15.12 10:16:10 INFO [hudson.model.Run] common-ops #87 main build action completed: SUCCESS
I might be wrong in what is actually happening: Maven should run in separate JVM, but how CustomProxySelector which I install to JVM static variable in my project, is visible from Maven JVM? If "parent" JVM and "forked" JVM share the same root classloader then perhaps they share the system properties as well. That means, if Maven build (even temporary) sets http.proxyHost to null and my process opens URL as this time, it will fail.
My question is: If above behaviour is a bug in Hudson / Maven? What can be a workaround (except trivial running 2 Tomcat servers).
Related
I am trying to build java software in tfs using ANT. I see this error
No agent found in pool XYZ pool which satisfies the specified demands:
ant
Agent.Version -gtVersion 1.91.0
And this is the screenshot of agent pool
In the system capabilities of the agent I see agent version as 2.131.0.
I am not understanding what does the error tell. Also I don't get what does Agent.version mean?
Below is the tfs build definition, I am not sure I have configured the tfs ANT correctly.
No agent found in pool XYZ pool which satisfies the specified demands:
ant
Agent.Version -gtVersion 1.91.0
The error means you have an environment issue , such as ant not installed or couldn't captured by TFS build agent.
The build agent will not detect the environment changes after you installed it. It will only detect during the installation.
Since you are using vNext build agent, first double check some capabilities added in Settings- Agent Queues- Agent Pool - Agent- Capabilities.
Then you need to restart corresponding VSO agent service. After this trigger the build again.
I try to connect Java Mission Control (JMC) with Wildfly 16. Application server lays on Docker.
I successfully connected to wildfly via jconsole, to manage it I followed steps described here.
Unfortunately, I have no luck to connect via JMC. The URL which I use looks like this:
service:jmx:remoting-jmx://192.168.99.100:9990
I tried to set Xbootclasspath to jboss-cli-client.jar as it was described here, but I just get Unable to connect error.
I set the same jars, which are used for jconsole, but still I got Unable to connect.
I gave a try to adding flags on container site, as it was shown here, but with these flags, even wildfly haven't started.
Then, I found here the idea to hardcode some jboss classes to enable connection via remoting-jmx. I changed version of jars, according to these provided by wildfly16 and put it to jmc.ini like this.
-Xbootclasspath/a:"C:/Program Files/Java/jdk-10.0.2/lib/missioncontrol/dropins/jboss-cli-client.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/remoting-jmx/main/remoting-jmx-3.0.1.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/remoting/main/jboss-remoting-5.0.8.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/logging/main/jboss-logging-3.3.2.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/xnio/main/xnio-api-3.6.5.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/xnio/nio/main/xnio-nio-3.6.5.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/marshalling/main/jboss-marshalling-2.0.6.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/marshalling/river/main/jboss-marshalling-river-2.0.6.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/as/cli/main/wildfly-cli-8.0.0.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/staxmapper/main/staxmapper-1.3.0.Final;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/as/protocol/main/wildfly-protocol-8.0.0.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/dmr/main/jboss-dmr-1.5.0.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/as/controller-client/main/wildfly-controller-client-8.0.0.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/threads/main/jboss-threads-2.3.3.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.1.7.Final.jar"
After that, finally, I have another error, which is
Could not initialize class org.jboss.remotingjmx.RemotingConnector
I added dependencies of remoting-jmx-3.0.1.Final to Xbootclasspath, but I got still the same error.
My question is, have you got any idea, how to make this connection works ? Maybe someone have done it in different way ?
Any advices how can i debug this problem, will be priceless? Because I'm lack of ideas how to solve it.
In %WILDFLY_HOME%\bin\standalone.conf.bat
put:
set "JAVA_OPTS=%JAVA_OPTS% -XX:+FlightRecorder"
In jmc.ini below -vmargs put
-Xbootclasspath/a:C:\%wildfly_home%\bin\client\jboss-cli-client.jar
(%wildfly_home% is different of course, or just copy jboss-cli-client.jar to another directory and correct the path)
3. Run JMC, then Create New Connection - in Connection Properties pane push the button "Custom JMX service URL", put:
service:jmx:http-remoting-jmx://localhost:9990
In the credentials fields just put user and password, they should be created for Realm Management (e.g. using %wildfly_home%\bin\add-user.bat)
Hope this helps someone.
Solution doesn't work on java 11 for me. Mission control fails on connect to wildfly with error:
Caused by: java.lang.NoClassDefFoundError: org/ietf/jgss/GSSManager
at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3137)
at java.base/java.lang.Class.getConstructor0(Class.java:3342)
at java.base/java.lang.Class.getConstructor(Class.java:2151)
at java.base/java.security.Provider.newInstanceUtil(Provider.java:152)
at java.base/java.security.Provider$Service.newInstance(Provider.java:1824)
at org.wildfly.security.WildFlyElytronBaseProvider$ProviderService.newInstance(WildFlyElytronBaseProvider.java:218)
at org.wildfly.security.sasl.util.SecurityProviderSaslClientFactory.createSaslClient(SecurityProviderSaslClientFactory.java:94)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
at org.wildfly.security.sasl.util.ProtocolSaslClientFactory.createSaslClient(ProtocolSaslClientFactory.java:50)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
at org.wildfly.security.sasl.util.ServerNameSaslClientFactory.createSaslClient(ServerNameSaslClientFactory.java:50)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
at org.wildfly.security.sasl.util.ServerNameSaslClientFactory.createSaslClient(ServerNameSaslClientFactory.java:50)
at org.wildfly.security.sasl.util.FilterMechanismSaslClientFactory.createSaslClient(FilterMechanismSaslClientFactory.java:102)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
at org.wildfly.security.sasl.util.LocalPrincipalSaslClientFactory.createSaslClient(LocalPrincipalSaslClientFactory.java:76)
at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory.lambda$createSaslClient$0(PrivilegedSaslClientFactory.java:64)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory.createSaslClient(PrivilegedSaslClientFactory.java:64)
at org.wildfly.security.auth.client.AuthenticationConfiguration.createSaslClient(AuthenticationConfiguration.java:1545)
at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.createSaslClient(AuthenticationContextConfigurationClient.java:430)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:419)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:244)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
Besides, jmc that was embedded to jdk 8 isn't able to start flight recording for java 11 process.
So after investigation i found out that this class is loaded with bootstrap classloader. According to https://openjdk.java.net/jeps/261
jdk.security.jgss module isn't defined to bootstrap classloader. But classes in jboss-cli-client.jar(it originates from wildfly-elytron project) need jgss classes in runtime.
So i found out dirty workaround for this problem: bootstrap needed classes from jre 8 in jmc.ini. Full option for linux is:
-vmargs -Xbootclasspath/a:<path_to_wildfly>/jboss-cli-client.jar:<path_to_jdk8>/jre/lib/rt.jar
And for windows:
-vmargs -Xbootclasspath/a:<path_to_wildfly>\jboss-cli-client.jar;<path_to_jdk8>\jre\lib\rt.jar
after this jmc(run on 11 jdk) succesfully connects to wildfly(run on 11 jdk) and can start and analyze flight recordings.
I am trying to deploy a maven EAR application to a Glassfish 3 server through Netbeans using right click -> debug and it fails with: GlassFish Server, deploy, Error writing request body to server, false
The output is:
BUILD SUCCESS
------------------------------------------------------------------------
Total time: 0.977 s
Finished at: 2017-10-02T21:00:19+03:00
Final Memory: 9M/393M
------------------------------------------------------------------------
Deploying on GlassFish Server
profile mode: false
debug mode: false
force redeploy: true
Distributing /path/to/ear.ear
GlassFish Server, deploy, Error writing request body to server, false
The Glassfish log contains no logging information.
The Netbeans IDE log contains the following:
INFO [glassfish]: Requested Entity: public id = -//GlassFish.org//DTD GlassFish Application Server 3.1 Resource Definitions//EN, system id = http://glassfish.org/dtds/glassfish-resources_1_5.dtd
INFO [null]: Last record repeated again.
WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save()
INFO [org.netbeans.modules.glassfish.tooling.admin.RunnerHttpDeploy]: IO exception caught in handleSend() method:
java.io.IOException: Error writing request body to server
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.checkError(HttpURLConnection.java:3518)
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.write(HttpURLConnection.java:3501)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:126)
at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:253)
at java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:255)
at java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360)
at java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:238)
at java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377)
[catch] at org.netbeans.modules.glassfish.tooling.admin.RunnerHttpDeploy.handleSend(RunnerHttpDeploy.java:267)
at org.netbeans.modules.glassfish.tooling.admin.Runner.handleHTTPConnection(Runner.java:828)
at org.netbeans.modules.glassfish.tooling.admin.Runner.call(Runner.java:939)
at org.netbeans.modules.glassfish.tooling.admin.Runner.call(Runner.java:73)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
INFO [org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment]
The module has not been deployed.
See the server log for details.
[catch] at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:259)
at org.netbeans.modules.maven.j2ee.execution.DeploymentHelper.perform(DeploymentHelper.java:208)
at org.netbeans.modules.maven.j2ee.execution.CoSAlternativeExecutorImpl.execute(CoSAlternativeExecutorImpl.java:90)
at org.netbeans.modules.maven.cos.CoSAlternativeExecutor.execute(CoSAlternativeExecutor.java:87)
at org.netbeans.modules.maven.cos.CosChecker.checkRunMainClass(CosChecker.java:209)
at org.netbeans.modules.maven.cos.CosChecker.checkRunConfig(CosChecker.java:163)
at org.netbeans.modules.maven.execute.MavenCommandLineExecutor.run(MavenCommandLineExecutor.java:225)
at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153)
INFO [glassfish]: Requested Entity: public id = -//GlassFish.org//DTD GlassFish Application Server 3.1 Resource Definitions//EN, system id = http://glassfish.org/dtds/glassfish-resources_1_5.dtd
INFO [null]: Last record repeated again.
WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save()
INFO [org.netbeans.modules.glassfish.tooling.admin.RunnerHttpDeploy]: IO exception caught in handleSend() method:
java.io.IOException: Error writing request body to server
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.checkError(HttpURLConnection.java:3518)
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.write(HttpURLConnection.java:3501)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:126)
at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:253)
at java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:255)
at java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360)
at java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:238)
at java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377)
[catch] at org.netbeans.modules.glassfish.tooling.admin.RunnerHttpDeploy.handleSend(RunnerHttpDeploy.java:267)
at org.netbeans.modules.glassfish.tooling.admin.Runner.handleHTTPConnection(Runner.java:828)
at org.netbeans.modules.glassfish.tooling.admin.Runner.call(Runner.java:939)
at org.netbeans.modules.glassfish.tooling.admin.Runner.call(Runner.java:73)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
INFO [org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment]
The module has not been deployed.
See the server log for details.
[catch] at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:259)
at org.netbeans.modules.maven.j2ee.execution.DeploymentHelper.perform(DeploymentHelper.java:208)
at org.netbeans.modules.maven.j2ee.execution.ExecutionChecker.executionResult(ExecutionChecker.java:93)
at org.netbeans.modules.maven.execute.MavenCommandLineExecutor.run(MavenCommandLineExecutor.java:315)
at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153)
Netbeans version: 8.2
Glassfish version: 3.1.2.2 (build 5)
Platform: reproducible on both Windows10 + Debian9
Maven version: 3.3.9
JDK: 1.7.0_80
Glassfish secure admin is enabled
The EAR produced can be normally deployed to Glassfish using the asadmin command. It is only when trying to deploy it through Netbeans that it fails so.
EDIT
It seems that when secure admin is disabled i am able to perform the deployment through Netbeans. I have come across some problems with the secure admin and ssl.
This is the best answer i could find that described the issue i am experiencing: https://intellij-support.jetbrains.com/hc/en-us/community/posts/206913035-Glassfish-3-1-remote-deploy-not-working (even though it is for another IDE).
This is not an accepted solution though because the secure admin is a requirement for everyday dev work.
EDIT 2
After experimenting a bit more i have observed the following:
Since the Glassfish logs are empty, and the netbeans IDE log contains an error having to do with HttpUrlConnection i think that after netbeans finishes the build process it fails to write the EAR to the socket.
I have experimented with other EAR projects (generated a new maven EAR from netbeans) and it deploys OK to Glassfish.
I have come across an article that mentions a bug in Netbeans failing to write archives of a certain size. I have tried to generate a new maven project with a large final EAR size but it deploys OK. The bug is quite old and has since been fixed: https://netbeans.org/bugzilla/show_bug.cgi?id=206946
EDIT 3
After experimenting with the POM file and removing all dependencies and trying adding one by one back in it seems that this issue is triggered by the inclusion of an EJB dependency.
Including a depencency of type ejb and declaring it as an ejbModule in the maven ear plugin modules section seems to be triggering the issue.
<dependency>
<groupId>com.foo</groupId>
<artifactId>BAR</artifactId>
<version>1.0</version>
<type>ejb</type>
</dependency>
.
.
.
.
<ejbModule>
<groupId>com.foo</groupId>
<artifactId>BAR</artifactId>
<altDeploymentDescriptor>AltDD.xml</altDeploymentDescriptor>
</ejbModule>
I still don't know why this issue is triggered. I have read online that there might be an issue with file size but i have been unable to reproduce it.
This might be happening on Netbeans when stopped on a breakpoint, and then some deployments might tend to fail immediately.
The BUG-253630 mentions a reproducible scenario for such as use case:-
1. Run app with DoS off (DoS state MODULE_NOT_DEPLOYED)
2. Debug it
3. App stopped at breakpoint
4. Change source (DoS state SERVER_STATE_UNSUPPORTED)
5. Continue with the app (release breakpoint, detach JPDA)
6. Change source (DoS state MODULE_UPDATED)
Also, make sure that for remote administration you will have to set an admin password before performing the actual enabling:
asadmin change-admin-password --domain_name [DOMAIN_NAME]
asadmin enable-secure-admin --port [PORT_NAME]
..and apart from just that, you can even try setting the password as empty if that might help as well.
I decided to learn how to debug Java EE apps.
I have a simple JSF/EJB/JPA app which I deploy and run via Intellij IDEA. That means that I have a so called Run/Debug configuration where I had specified an artifact to deploy(a war file) an application server path(wildfly-8.2.0.Final/bin/standalone.bat is used) an a url to be opened in browser after deployment(its a web app). Works awesome - no problems. But when I run debug which as far as I understand uses basically the same configuration but only adds
JAVA_OPTS -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:52764,suspend=y,server=n
to the enviroment variables I have problems.
D:\Proc\wildfly-8.2.0.Final\bin\standalone.bat
D:\Proc\JDK\jdk1.8.0_31\bin\java -classpath "D:\Proc\IntelliJ IDEA
14.1.3\lib\idea_rt.jar;D:\Proc\IntelliJ IDEA 14.1.3\lib\util.jar" -Dfile.encoding=windows-1251 com.intellij.rt.execution.CommandLineWrapper
C:\Users\username\AppData\Local\Temp\classpath0.tmp
com.intellij.javaee.oss.process.JavaeeProcess 53821
com.intellij.javaee.oss.jboss.agent.JBoss71Agent Detected server admin
port: 9990 [2015-05-30 04:35:06,499] Artifact portfolio:war exploded:
Server is not connected. Deploy is not available. Detected server http
port: 8080 Calling
"D:\Proc\wildfly-8.2.0.Final\bin\standalone.conf.bat" "JAVA_OPTS
already set in environment; overriding default settings with values:
-agentlib:jdwp=transport=dt_socket,address=127.0.0.1:52764,suspend=y,server=n
" Setting JAVA property to "D:\Proc\JDK\jdk1.8.0_31\bin\java"
JBoss Bootstrap Environment
JBOSS_HOME: "D:\Proc\wildfly-8.2.0.Final"
JAVA: "D:\Proc\JDK\jdk1.8.0_31\bin\java"
JAVA_OPTS: "-Dprogram.name=standalone.bat
-agentlib:jdwp=transport=dt_socket,address=127.0.0.1:52764,suspend=y,server=n
"
===============================================================================
Connected to the target VM, address: '127.0.0.1:52764', transport:
'socket'
After that I guess the deployment phase fails with an exception and a debugger as supposed by its default behavior stops on the line that throws an exception in URLClassLoader:
What's going on? Why does the same configuration behave differently? I need something to start with...
Thx.
The reason is that Intellij Idea overwrites the JAVA_OPTS enviroment variable when started in debug mode. You can verify this in the Run/Debug Configurations Dialog. Select your configuration and have a look at the Startup/Connection tab. Select Debug and you can see below that the checkmark for Pass environment variables is set.
There is an entry for JAVA_OPTS. It probably overrides all settings made in standalone.conf (standalone.conf.bat for windows). These settings can be important for operation. Especially if you customize some settings in standalone.conf you can see them in run mode but not in debug mode.
I have a web application running on tomcat. I want to deploy it on a weblogic server but i get some problems.
Error(s) found in module 'BatchMonitoring'. Publish was cancelled. See "Problems" view for details.
Target runtime SpringSource dm Server (Runtime) v1.0 is not defined. at BatchMonitoring
Java compiler level does not match the version of the installed Java project facet. at BatchMonitoring
java.lang.IllegalArgumentException: Cannot find state with id 'displayError' in flow 'admin_main' -- Known state ids are 'array<String>['queryAll', 'mainForm', 'register']'
at org.springframework.webflow.engine.Flow.getStateInstance(Flow.java:348)
at org.springframework.webflow.engine.support.DefaultTargetStateResolver.resolveTargetState(DefaultTargetStateResolver.java:60)
at org.springframework.webflow.engine.Transition.execute(Transition.java:217)
at org.springframework.webflow.engine.impl.FlowExecutionImpl.execute(FlowExecutionImpl.java:391)
at org.springframework.webflow.engine.impl.RequestControlContextImpl.execute(RequestControlContextImpl.java:214)
at org.springframework.webflow.engine.support.TransitionExecutingFlowExecutionExceptionHandler.handle(TransitionExecutingFlowExecutionExceptionHandler.java:110)
at org.springframework.webflow.engine.FlowExecutionExceptionHandlerSet.handleException
Seems like you had problems with Java versions of what Tomcat is using(points to JAVA_HOME) at environmental variable and JDK of Weblogic. Also it would be good if you send some logs and exception messages.