I've tried many times to debug a Test in managed container enviroment.
I get errors like JDWP Transport Error, socket failed to initialize. Means I can not initialize arquillian with the below property tag.
My arquillian.xml file looks like this:
<arquillian xmlns="http://jboss.org/schema/arquillian"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://jboss.org/schema/arquillian
http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
<engine>
<property name="deploymentExportPath">target/arq.deployments</property>
</engine>
<container qualifier="jboss" default="true">
<protocol type="jmx-as7">
<property name="executionType">MANAGED</property>
</protocol>
<configuration>
<property name="javaVmArguments">-Xrunjdwp:transport=dt_socket,address=55407,server=y,suspend=y -Xmx512m -XX:MaxPermSize=128m</property>
</configuration>
</container>
</arquillian>
Am I missing something?
There are 3 JVM running in this case. So this is a special debug case.
1st JVM-> Started by Arquillian/Junit to perform the tests.
2nd JVM-> Started by Arquillian to run managed Jboss.
3rd JVM-> It's a remote debugging configuration that must be ported to JVM
number 2 in order to debug 2nd JVM. Check out this blog
So this is the idea, Run test (2nd JVM will be suspended until a JVM is attached to it), then run a new remote configuration, as soon as this starts, the past JVM will run.
It's a bit confusing but works.
Note that if you only have 2 JVM in simple debug mode, you will be debugging arquillian/junit JVM, which is not the one you are interested.
Related
I am having problems running tests with arquillian/wildfly 10.0.0.Final.
The error is a LifecycleException: Could not start container, due to TimeoutException: Managed Server was not started within [120] s (I have upped the timeout from 60 to see if it would make a difference).
Funny thing is, Wildfly starts fine (within the default 60s) and then sits there
until it's told to shut down, which it does.
I had tests in another project which used to run but now don't run anymore, they fail with the same error (although they do still run on Jenkins).
Also, turning on Shrinkwrap.writeTo(System.out, Formatters.VERBOSE) (used to build the war file) does not produce any output (which I also know it did in the past)
What has changed:
The server was hooked up to LDAP to managed admin logins, and a datasource was added
Eclipse was updated to Neon 3
Arquillian configuration file is:
<arquillian xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://jboss.org/schema/arquillian" xsi:schemaLocation="http://jboss.org/schema/arquillian http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
<container qualifier="wildfly" default="true">
<configuration>
<property name="jbossHome">/Users/turekg/dev/apps/wildfly-10.0.0.Final</property>
<property name="startupTimeoutInSeconds">120</property>
</configuration>
</container>
I am using ant with Ivy to manage test dependencies and these are:
<dependency org="org.jboss.arquillian" name="arquillian-bom" rev="1.1.11.Final" conf="test->default"/>
<dependency org="org.jboss.arquillian.junit" name="arquillian-junit-container" rev="1.1.11.Final" conf="test->default"/>
<dependency org="org.wildfly.arquillian" name="wildfly-arquillian-container-managed" rev="2.0.0.Final" conf="test->default"/>
<dependency org="org.wildfly.security" name="wildfly-security-manager" rev="1.1.2.Final" conf="test->default"/>
<dependency org="org.jboss.shrinkwrap.resolver" name="shrinkwrap-resolver-depchain" rev="2.2.4" conf="test->default"/>
<dependency org="org.jboss.arquillian.extension" name="arquillian-rest-client-impl-3x" rev="1.0.0.Final-SNAPSHOT" conf="test->default"/>
Thanx
Gaby
The objective I have is to develop a bus with Mule, to run it into a JBoss.
My IDE is eclipse kepler, I have the Anypoint Studio plugin installed, a JBoss 7.1.1, a 3.5 CE runtime, Maven etc etc.
I took a look a this page : Deploy War into Mule Standalone server but I don't see haw it could help.
Context :
- Jboss is an imposed choice. I know it exists an EE version of the runtime, specially for the HA ability (that I need), but it's not an option for my client.
As it's "easier" to test my flows on the standalone (CE) runtime, I wanted to find a way to develop one Mule project to execute it on a CE runtime during the developing phase, and on a JBoss AS during the integration phase.
To do that, I tried to define :
- a jar maven project which contains all the flow
- a "mule" maven project, with the previous jar as the dependency
- a war maven project which athe previous jar and all the module/transport mule jars as dependencies
When I build the mule zip, my jar is included inside, but when it's executed none of ny flew is registered. So it doesn't work.
When I execute the war on JBoss, everything looks fine for the "first" flow (the input one), but I have a crash when the second one is called using a VM connector (other issue, I'll make another request)
Is there a way to do something working with this approach?
I tried to define 2 pom for the same mule project (one pom which generate a war, and a standalone-pom which generate the mule zip), but this is not very "easy to use" for my team, as the eclipse integration of this kind of project is not very friendly.
The last thing I can try is to keep the mule project pom with a mule packaging, and add a maven assembly to build the jar I could include in my war, but I'd prefer a nicer solution...
Thanks for all of your ideas!
Ah, the test flew I'm trying to integrate.
I have 3 flew :
- The first one stands for the HTTP request (to call my CE runtime)
- The second one stands for the Servlet request (to call my JBoss)
- The third one is called by both my CE runtime and my JBoss input flow, throw the VM connector. I'm thinking replace the VM connector by a Flow Call, as the VM inbound-endpoint is not registered when it's embedded into my war (but it works when executed in a CE runtime...)
main file :
<flow name="muleFlow1" doc:name="muleFlow1">
<http:inbound-endpoint exchange-pattern="request-response"
host="localhost" port="8081" doc:name="HTTP" />
<echo-component doc:name="Echo" />
<vm:outbound-endpoint path="receiver"
exchange-pattern="request-response" responseTimeout="10000" doc:name="VM" />
</flow>
<flow name="muleFlow2" doc:name="muleFlow2">
<servlet:inbound-endpoint path="servlet"
responseTimeout="10000" doc:name="Servlet" />
<echo-component doc:name="Echo" />
<vm:outbound-endpoint path="receiver"
exchange-pattern="request-response" responseTimeout="10000" doc:name="VM" />
</flow>
second file :
<flow name="otroFlow1" doc:name="otroFlow1">
<vm:inbound-endpoint path="receiver"
exchange-pattern="request-response" responseTimeout="10000" doc:name="VM" />
<set-payload value="it works" doc:name="Set Payload" />
<echo-component doc:name="Echo" />
</flow>
Thanks !
I didn't find anything else, so I opted for an assembly descriptor...
<assembly
xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd">
<id>mule</id>
<formats>
<format>zip</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<fileSets>
<fileSet>
<directory>${project.build.directory}/classes</directory>
<outputDirectory>/</outputDirectory>
<includes>
<include>*.xml</include>
</includes>
</fileSet>
<fileSet>
<directory>${project.build.directory}</directory>
<outputDirectory>/</outputDirectory>
<includes>
<include>classes/**/*.class</include>
</includes>
</fileSet>
</fileSets>
<dependencySets>
<dependencySet>
<outputDirectory>/lib</outputDirectory>
<useProjectArtifact>false</useProjectArtifact>
<useTransitiveDependencies>true</useTransitiveDependencies>
<excludes>
<exclude>org.mule:mule-core</exclude>
<exclude>commons-cli:commons-cli</exclude>
<exclude>log4j:log4j</exclude>
<exclude>org.mule.mvel:mule-mvel2</exclude>
<exclude>org.mule.common:mule-common</exclude>
<exclude>org.mule.modules:mule-module-client</exclude>
<exclude>org.mule.modules:mule-module-spring-config</exclude>
<exclude>org.mule.modules:mule-module-annotations</exclude>
<exclude>org.mule.modules:mule-module-xml</exclude>
<exclude>org.mule.modules:mule-module-cxf</exclude>
<exclude>org.mule.modules:mule-module-spring-security</exclude>
<exclude>org.mule.transports:mule-transport-http</exclude>
<exclude>org.mule.transports:mule-transport-ssl</exclude>
<exclude>org.mule.transports:mule-transport-tcp</exclude>
<exclude>commons-codec:commons-codec</exclude>
<exclude>org.mule.modules:mule-module-spring-extras</exclude>
<exclude>org.mule.modules:mule-module-builders</exclude>
<exclude>org.mule.modules:mule-module-management</exclude>
<exclude>org.mule.modules:mule-module-scripting</exclude>
<exclude>org.mule.modules:mule-module-sxc</exclude>
<exclude>org.mule.tests:mule-tests-functional</exclude>
<exclude>org.mule:mule-core</exclude>
<exclude>org.mule.transports:mule-transport-file</exclude>
<exclude>org.mule.transports:mule-transport-jdbc</exclude>
<exclude>org.mule.transports:mule-transport-jms</exclude>
<exclude>org.mule.transports:mule-transport-servlet</exclude>
<exclude>org.mule.transports:mule-transport-vm</exclude>
</excludes>
</dependencySet>
</dependencySets>
</assembly>
My mule project is now a jar, which generate a jar file (for my webapp) and a zip file (for my runtime CE)
One important thing :
To realize the spring imports of each flow, we need to specify when mule is deployed in a web app, but the runtime expects to work. It can be done by creating a maven profile and enabling the resources filtering to determine when add "classpath:"...
I already made some research on Google and SO but could not find a solution.
I am writing a java ee 7 Web application including Omnifaces and Primefaces using Eclipse. When deploying the application to Glassfish 4, I get the following error:
javax.naming.NamingException: Lookup failed for 'java:comp/BeanManager'
The longer part of the stacktrace is
java.lang.IllegalStateException: javax.naming.NamingException: Lookup failed for 'java:comp/BeanManager' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException: Error retrieving java:comp/BeanManager [Root exception is java.lang.IllegalStateException: Cannot resolve bean manager]]
at org.omnifaces.util.JNDI.lookup(JNDI.java:87)
at org.omnifaces.config.BeanManager.init(BeanManager.java:76)
at org.omnifaces.config.BeanManager.getReference(BeanManager.java:115)
at org.omnifaces.application.OmniApplication.createConverter(OmniApplication.java:86)
at javax.faces.application.ApplicationWrapper.createConverter(ApplicationWrapper.java:403)
at org.primefaces.config.ConfigContainer.initConfig(ConfigContainer.java:69)
But I highly doubt that the problem is related to Omnifaces, it's more to state that I didn't do any messy call to cause this.
There is a beans.xml in WEB-INF, it's not completely empty.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
bean-discovery-mode="all">
<interceptors>
<class>x.y.z.security.SecurityInterceptor</class>
</interceptors>
</beans>
For the discovery-mode=all, I know it is not recommended, but this is due to an issue I found here: https://java.net/jira/browse/GLASSFISH-20667
If you need more information, facets config or the like, I am happy to post it - but as I've run out of ideas where to locate the problem I don't want to post the everything like complete POM, Glassfish, Eclipse, Maven config or all the code.
edit 2014-01-27:
Ok, after I had written my below comment (the one in comments), I got an idea. Can someone maybe check it out/confirm easily? I was able to load the application to GF after recreating a new database. Can eclipselink cause the above? I am using MS SQL Server 2012, and of course I get SQLExceptions and warnings that tables+fks already exist when redploying, but warnings should not fail my application deployment, should they?
<persistence-unit name="xyzPersistenceUnit" transaction-type="JTA">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<jta-data-source>jdbc/xyzDS</jta-data-source>
<properties>
<property name="eclipselink.ddl-generation" value="create-tables"/>
</properties>
I downloaded wicket examples 1.6.0 and built successfully in netbeans7.2. but got errors when I tried to deploy on tomcat 7:
Cannot deploy the module. The context.xml file seems to be broken. Check whether it is well-formed and valid.
The module has not been deployed.
See the server log for details.
at
org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:210)
at
org.netbeans.modules.maven.j2ee.ExecutionChecker.performDeploy(ExecutionChecker.java:178)
at
org.netbeans.modules.maven.j2ee.ExecutionChecker.executionResult(ExecutionChecker.java:130)
at
org.netbeans.modules.maven.execute.MavenCommandLineExecutor.run(MavenCommandLineExecutor.java:212)
at
org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153)
heres the contents in context.xml:
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<!-- <Loader className="org.atmosphere.util.AtmosphereClassloader"/> -->
<Loader delegate="true"/>
</Context>
I prefer to run wicket in eclipse as it negates the requirement to mess around with an external tomcat instance.
If you are comfortable with eclipse and maven i would download wicket 1.6 example archetype via maven, import into eclipse and then in the test directory you can run the run.java class to get an internal jetty server host wicket for you.
this should get you started quickly without having to wrestle with tomcat configurations too.
Not really an answer but an alternative route to the same end point
Add parameter path to context tag, same path that app will be served:
<?xml version="1.0" encoding="UTF-8"?>
<Context path="/application-path-name/">
<!-- <Loader className="org.atmosphere.util.AtmosphereClassloader"/> -->
<Loader delegate="true"/>
</Context>
Answer obtained from this question.
I have web app, based on Spring 3.0.3, that I've been developing using Eclipse 3.4. While doing so I've been running the web app in Tomcat 6.0.18 from Eclipse. That is, I have Eclipse use the Tomcat installation meaning that Tomcat will, as need, modify files etc. (at least, that's my understanding of what it's doing).
My problem is specifying the values for the contextConfigLocations in the web.xml. When running from within Eclipse this worked fine:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath:applicationContext.xml
classpath:applicationContext-security.xml
</param-value>
</context-param>
However, when I package the app into a war file (ROOT.war) and then added it to Tomcat's webapp directory and the try to start Tomcat, I get an error that neither of these applicationContext files can be found. But when I change it to below, Tomcat can find the files:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/config/applicationContext.xml
/WEB-INF/config/applicationContext-security.xml
</param-value>
</context-param>
I should note that applicationContext.xml includes other applicationContext files that also use the classpath: short hand. When running within Tomcat, I need to drop all use of classpath: in favor of relative paths to get Tomcat to see these files.
Great. Tomcat and Eclise are getting along nicely. But JUnit 4.7 is no longer happy. For whatever reason, files specified using #ContextConfiguration in a test class can't be found unless the classpath: short hand is used. Here is an example:
#ContextConfiguration(locations = {"classpath:applicationContext.xml", "classpath:applicationContext-security.xml"})
public class UserDaoTest extends AbstractTransactionalJUnit4SpringContextTests {
#Test
public void testCreateUser() {
}
So applicationContext.xml and applicationContext-security.xml are found without a problem; however, property files that are specified in applicationContext.xml are not found.
<bean id="appProperties" class="org.springframework.beans.factory.config.PropertiesFactoryBean">
<property name="singleton" value="true" />
<property name="ignoreResourceNotFound" value="true" />
<property name="locations">
<list>
<value>/WEB-INF/config/spring/base.spring-config.properties</value>
<value>/WEB-INF/config/spring/local.spring-config.properties</value>
</list>
</property>
</bean>
But if I specify the location of these files using the classpath: short hand, the property files are found. If I do this though, the files won't be found when running from a war file in Tomcat.
For now I've created a applicationContext-test.xml that is a cut-and-paste conglomeration of all of the other applicationContext files wherein I'm using the classpath: short hand. This seems hacky and error prone and I'm wondering what the issue might be across all of these technologies.
Feedback most welcome!
web.xml content should look like
<context-param>
<description>
Spring Context Configuration.
</description>
<param-name>contextConfigLocation</param-name>
<!-- spring loads all -->
<param-value>
classpath*:spring/*.xml,
classpath*:spring/persistence/*.xml,
classpath*:spring/webapp/*.xml</param-value>
</context-param>
see http://static.springsource.org/spring/docs/2.5.x/reference/resources.html#resources-app-ctx-wildcards-in-resource-paths for further reference
the junit config should follow the same convention with classpath*:
but beware spring might load .xml context files you don't want it to do