We have an enterprise application that uses the Joda DateTime library. The application is deployed into a JBoss 7.2.0 Alpha1 Container. Some classes in our domain model have #Past annotations on fields of type DateTime. In order to validate these constraints we'd like to use the constraint validators provided by hibernate-validator. Therefore we added a dependency 'org.hibernate.validator' to the MANIFEST.MF of our ear file. We are using version 2.0 of the Joda library. Therefore we have packaged the joda-time-2.0.jar file in our ear. We are not using the version 1.6.2 that is available as a module of JBoss 7
When validating an object with a DateTime field following exception is thrown:
10:51:41,140 ERROR [org.acme.GlobalExceptionHandler] (EJB default - 10) Exception caught by global exception handler: javax.validation.UnexpectedTypeException: No validator could be found for type: org.joda.time.DateTime
at org.hibernate.validator.engine.ConstraintTree.verifyResolveWasUnique(ConstraintTree.java:383) [hibernate-validator-4.2.0.Final.jar:4.2.0.Final]
at org.hibernate.validator.engine.ConstraintTree.findMatchingValidatorClass(ConstraintTree.java:364) [hibernate-validator-4.2.0.Final.jar:4.2.0.Final]
at org.hibernate.validator.engine.ConstraintTree.getInitializedValidator(ConstraintTree.java:313) [hibernate-validator-4.2.0.Final.jar:4.2.0.Final]
at org.hibernate.validator.engine.ConstraintTree.validateConstraints(ConstraintTree.java:144) [hibernate-validator-4.2.0.Final.jar:4.2.0.Final]
at org.hibernate.validator.engine.ConstraintTree.validateConstraints(ConstraintTree.java:117) [hibernate-validator-4.2.0.Final.jar:4.2.0.Final]
at org.hibernate.validator.metadata.MetaConstraint.validateConstraint(MetaConstraint.java:84) [hibernate-validator-4.2.0.Final.jar:4.2.0.Final]
at org.hibernate.validator.engine.ValidatorImpl.validateConstraint(ValidatorImpl.java:452) [hibernate-validator-4.2.0.Final.jar:4.2.0.Final]
After some debugging we detected that the call to 'TypeUtils.isAssignable( validatorType, type )' in 'ConstraintTree.findSuitableValidatorTypes' fails since the available validator types are taken from the Joda library that has been shipped with JBoss instead of the Joda library that is packaged in our ear file.
I guess we are doing something wrong regarding classloading. Can anybody give me a hint?
Have you tried adding a jboss-deployment-structure.xml to your ear file? This way you should be able to exclude the Joda time module:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<exclusions>
<module name="org.joda.time"/>
</exclusions>
</deployment>
</jboss-deployment-structure>
See also https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7
Following Hardy's idea I solved my problem creating a jboss-deployment-structure.xml in my application's WEB-INF folder containing this:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<exclusions>
<module name="org.hibernate.validator" />
</exclusions>
</deployment>
</jboss-deployment-structure>
In stead of excluding org.joda.time I excluded org.hibernate.validator. I hope this works for you too.
Related
I created library using helidon-messaging, helidon-messaging-kafka. Also I created an example Java SE app using that library and all works fine. But when I try to use that library in Java EE (Weblogic) legacy application I have got an exception while that application starts:
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Config with qualifiers #Default
at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] #Inject io.helidon.messaging.connectors.kafka.KafkaConnector(Config)
at io.helidon.messaging.connectors.kafka.KafkaConnector.<init>(KafkaConnector.java:0)
Is it possible some how to switch off CDI stuff there?
Did you try to exclude the connector package from bean scanning?
Something like this should help:
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd"
version="2.0"
bean-discovery-mode="annotated">
<scan>
<exclude name="io.helidon.messaging.connectors.kafka.**" />
</scan>
</beans>
More info can be found here
I'm using Wildfly 11 with Java 8. Previously I was building a WAR file, which required the dom4j JAR file. Rather than including it in the WAR's WEB-INF/lib directory, I linked to the Wildfly modules JAR by adding an entry in the WEB-INF/jboss-deployment-structure.xml. Now I want to package this WAR as part of an EAR. So I created a jboss-deploymebnt-structure.xml file at teh root of the EAR, with these lines
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<sub-deployment name="myapp.war">
<dependencies>
...
<module name="org.dom4j" />
Now when I deploy the EAR, the WAR is failing to deploy with errors like
service jboss.undertow.deployment.default-server.default-host./myapp: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./orgsclient: java.lang.RuntimeException: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [META-INF/spring/infrastructure.xml]: Invocation of init method failed; nested exception is java.lang.NoClassDefFoundError: org/dom4j/io/STAXEventReader
What else do I need to do to tell the EAR file that the WAR is using the Wildly module dom4j as opposed to one I'm packaging with the EAR itself?
Check if your jboss-deploymebnt-structure.xml is correctly placed in META-INF subfolder (beside with application.xml) of your built ear package. If you're using maven ear plugin you should put the xml file in:
ear/src/main/application/META-INF/jboss-deploymebnt-structure.xml
Please note the application folder is default resource folder for ear plugin.
If you still have a problem with NoClassDefFound, try to redeclare the dependency as 'ear global' and set it as exported
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="org.dom4j" slot="main" export="true"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
If you still have a problem then declare the module as a global module in wildlfy config (under the ee subsystem). Then you can get rid off the the jboss deployment descriptor at all.
<subsystem xmlns="urn:jboss:domain:ee:4.0">
<global-modules>
<module name="org.dom4j">
</global-modules>
...
I have an application running on wildfly 10 that needs a newer version of jackson. Simply updating the maven dependency does not to work. Wildflys own version seems to interfere...
Somebody has a hint?
You can add a newer version of Jackson to your war and use that, but the JAX-RS subsystem of the container (Resteasy) will still use it's own jackson module to (de)serialize you HTTP request/response bodies.
You could add a module with the newer version, but you could run into dependency problems with other modules (see this pull request which already was accepted, so it should be in the next release, but I don't know of any planned Wildfly release dates).
Or you could package your own version of Jackson and register those MessageBodyReaders/Writers to be used by JAX-RS. This should do the job.
#Provider
public class CustomJacksonJsonProvider extends JacksonJsonProvider {}
You may also have to exclude the built-in Jackson by adding a jboss-deployment-structure.xml:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<exclusions>
<module name="org.jboss.resteasy.resteasy-jackson-provider" />
</exclusions>
</deployment>
</jboss-deployment-structure>
I'm running JBoss 7.1.1 and I can see that one of the libraries I need to use is already included in JBoss (I see it in /jboss-as-7.1.1/modules/org/codehaus/jackson/jackson-core-asl/main/jackson-core-asl-1.9.2.jar). How can I access it from my web app if it's not in web-inf/lib? Do I need to declare it in one of the xml files?
Check out Class Loading in AS7 you either need a jboss-deployment-structure.xml
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="org.codehaus.jackson.jackson-core-asl" />
</dependencies>
</deployment>
</jboss-deployment-structure>
or a header in your MANIFEST.MF
Dependencies: org.codehaus.jackson.jackson-core-asl
I have a couple of EARs deployed in JBoss 7 AS.
App1.ear serves as a library to other EARs.
App2.ear has following deployment XML,
<jboss-deployment-structure>
<ear-subdeployments-isolated>false</ear-subdeployments-isolated>
<deployment>
<dependencies>
<module name="deployment.app1.ear" export="true" />
</dependencies>
</deployment>
<sub-deployment name="app2_ejb1.jar">
<dependencies>
<!-- Is it required ??? -->
<module name="deployment.app1.ear" />
</dependencies>
</sub-deployment>
</jboss-deployment-structure>
JBoss throws following exception while deploying the applications.
Failed to load module: deployment.app2.ear.app2_ejb1.jar:main
Caused by: org.jboss.modules.ModuleLoadException: Could not load module deployment.app1.ear:main as corresponding module spec service deployment.app1.ear:main was not found.
If childEAR depends on parentEAR and if the dependencies are specified accordingly in the XML, I would expect subdeployments of childEAR to wait untill parentEAR is successfully & completely deployed.
Does my understanding contradicts the JBoss 7 classloading architecture ?
Can someone provide a solution ?