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>
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 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'm working on setup of arquillian testing. I want to deploy a WAR to JBoss using arquillian. This war is defined as a dependency in my pom.xml:
<dependency>
<groupId>my.project</groupId>
<artifactId>mywar</artifactId>
<version>1.0</version>
<type>war</type>
<scope>runtime</scope>
</dependency>
But when I try to resove this dependency using shrinkwrap, it throws a NoResolvedResultException:
PomEquippedResolveStage resolver = Maven.configureResolver().workOffline().loadPomFromFile("pom.xml");
File war = resolver.resolve("my.project:mywar:war").withoutTransitivity().asSingleFile();
It seems that somehow the resolver isn't able to deal with war files. I experminted with org.jboss.shrinkwrap.resolver.api.ResolveWithRangeSupportStage.resolveVersionRange(String) as well and it seems to interpret the ":war" in the coordinates as the version - which obviously won't work.
If I supply the version, it works:
Maven.resolver().resolve("my.project:mywar:war:1.0").withoutTransitivity().asSingleFile();
But I need to make it work without the version because this will change by the time and I don't want to adapt the version on each release.
Any ideas?
Since your artifact is not JAR, I think you have to add a question mark. Your resolver should look like: .resolve("my.project:mywar:war:?")
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.
Now I can load jars which is under the EAR/lib.
But I want to put the jars to a common path, for other application to use.
I found that jboss-deployment-structure.xml file's tag can do this.
But it doesn't work. I got the ClassNotFound exception.
I don't know why?
<deployment>
<resources>
<resource-root path="/common/test.jar" />
</resources>
</deployment>
One way of using global libraries in different applications can be reached by making them available as modules.
Therefor, extend the modules by the library you are providing as a server provider.
Example:
To make your test.jar available to all applications, create a folder with the modules name and a main subdirectory (e.g. modules/commons/test/main).
Place your library there and a module description file with the name module.xml.
Example content:
<module xmlns="urn:jboss:module:1.0" name="commons.test">
<resources>
<resource-root path="test.jar"/>
</resources>
</module>
Now the library is available to all applications.
To get access to the module, your application has to define the dependency in the manifest.
Applications MANIFEST.MF:
Dependencies: commons.test
This can be also done by maven during build time.
Check https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7 for details
Please note that you're modifying the server itself. All applications using your module are depending on it. A application with a dependency to the module commons.test wont be deployed on a server which does not have this module provided.