I have a problem with a Webservice deployed in JBoss EAP 6.
I have a war file, that war contains a WS, but, that war originally was developed and tested in a Weblogic 11 AS; and everything works fine BUT
my boss said that my war can deploys in other server (JBoss) that he has mounted in other computer.
Everything is normal, but in the response, the date is different, i mean, in Weblogic, it appears like this:
<birthday class="com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl">
<year>1952</year>
<month>4</month>
<day>17</day>
<timezone>-360</timezone>
<hour>0</hour>
<minute>0</minute>
<second>0</second>
<fractionalSecond>0.000</fractionalSecond>
</birthday>
So, in JBoss EAP 6, the date appears whit more fields, like this:
<birthday class="org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl">
<orig__year>1944</orig__year>
<orig__month>3</orig__month>
<orig__day>1</orig__day>
<orig__hour>0</orig__hour>
<orig__minute>0</orig__minute>
<orig__second>0</orig__second>
<orig__fracSeconds>0.000</orig__fracSeconds>
<orig__timezone>-300</orig__timezone>
<year>1944</year>
<month>3</month>
<day>1</day>
<timezone>-300</timezone>
<hour>0</hour>
<minute>0</minute>
<second>0</second>
<fractionalSecond>0.000</fractionalSecond>
</birthday>
My question is, how can i switch the implementation of the de/serializer for this data type?
It seems, Weblogic uses the JDK interal classes to make the job, but JBoss uses it's own implementation.
I read about to add a xml file (jboss-deployment-structure.xml) to the war archive, i integrate one xml, like this:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<exclusions>
<module name="org.apache.xerces" />
</exclusions>
<dependencies>
<module name="sun.jdk" >
</module>
<system>
<paths>
<path name="com/sun/org/apache/xerces/internal/jaxp/datatype"/>
</paths>
</system>
</dependencies>
</deployment>
</jboss-deployment-structure>
If i understood well, that xml avoids the use of the JBoss XML implementation (xerces) then i can use the internal classes of the JDK; but the result is the same, any ideas?
I resolve my issue in this form:
I change the default xerces implementation, in this path
{JBOSS_HOME}\modules\system\layers\base\org\apache\xerces\main
I add two files: jaxp-api-1.4.5.jar and jaxp-ri-1.4.5.
And in the module.xml i made a change for the jar declared as a resource root, like this:
<module xmlns="urn:jboss:module:1.1" name="org.apache.xerces">
<resources>
<!--<resource-root path="xercesImpl-2.9.1-redhat-4.jar"/> -->
<resource-root path="jaxp-ri-1.4.5.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
</dependencies>
</module>
Now, my xml comes with the desired XMLGregorianCalendar implementation.
Cheers.
Related
I have SpringBoot app (1.4.3.RELEASE). Recently I have upgraded Jackson (com.fasterxml.jackson.datatype, com.fasterxml.jackson.core) from 2.8.5 to 2.12.2 because of polymorphic subtype deduction feature. Everything works just fine on my local development environment during unit tests and also when I'm running app from IDE.
The problem occurs when I push my changes to build and deploy it on development environment, where app is deployed on Wildfly 21.0.2. (as a WAR archive). Calling ObjectMapper#readValue throws java.lang.EnumConstantNotPresentException (detailed stack below).
There are no enums used in objects which I'm deserializing and I have already checked through Wildfly management console, that there is correct version of Jackson on deployed app. Now I am a bit clueless. Any ideas?
com.fasterxml.jackson.annotation.JsonTypeInfo$Id.DEDUCTION
at com.fasterxml.jackson.databind.introspect.JacksonAnnotationIntrospector._findTypeResolver(JacksonAnnotationIntrospector.java:1424)
at com.fasterxml.jackson.databind.introspect.JacksonAnnotationIntrospector.findTypeResolver(JacksonAnnotationIntrospector.java:522)
at com.fasterxml.jackson.databind.introspect.AnnotationIntrospectorPair.findTypeResolver(AnnotationIntrospectorPair.java:225)
at com.fasterxml.jackson.databind.deser.BasicDeserializerFactory.findTypeDeserializer(BasicDeserializerFactory.java:1584)
at com.fasterxml.jackson.databind.deser.BasicDeserializerFactory.findPropertyTypeDeserializer(BasicDeserializerFactory.java:1748)
at com.fasterxml.jackson.databind.deser.BasicDeserializerFactory.resolveMemberAndTypeAnnotations(BasicDeserializerFactory.java:2116)
at com.fasterxml.jackson.databind.deser.BasicDeserializerFactory.constructCreatorProperty(BasicDeserializerFactory.java:1000)
at com.fasterxml.jackson.databind.deser.BasicDeserializerFactory._addExplicitPropertyCreator(BasicDeserializerFactory.java:634)
at com.fasterxml.jackson.databind.deser.BasicDeserializerFactory._addDeserializerConstructors(BasicDeserializerFactory.java:407)
at com.fasterxml.jackson.databind.deser.BasicDeserializerFactory._constructDefaultValueInstantiator(BasicDeserializerFactory.java:283)
at com.fasterxml.jackson.databind.deser.BasicDeserializerFactory.findValueInstantiator(BasicDeserializerFactory.java:224)
at com.fasterxml.jackson.databind.deser.BeanDeserializerFactory.buildBeanDeserializer(BeanDeserializerFactory.java:220)
at com.fasterxml.jackson.databind.deser.BeanDeserializerFactory.createBeanDeserializer(BeanDeserializerFactory.java:143)
at com.fasterxml.jackson.databind.deser.DeserializerCache._createDeserializer2(DeserializerCache.java:414)
at com.fasterxml.jackson.databind.deser.DeserializerCache._createDeserializer(DeserializerCache.java:349)
at com.fasterxml.jackson.databind.deser.DeserializerCache._createAndCache2(DeserializerCache.java:264)
at com.fasterxml.jackson.databind.deser.DeserializerCache._createAndCacheValueDeserializer(DeserializerCache.java:244)
at com.fasterxml.jackson.databind.deser.DeserializerCache.findValueDeserializer(DeserializerCache.java:142)
at com.fasterxml.jackson.databind.DeserializationContext.findRootValueDeserializer(DeserializationContext.java:479)
at com.fasterxml.jackson.databind.ObjectMapper._findRootDeserializer(ObjectMapper.java:4405)
at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:4214)
at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3214)
at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3197)
Well, the problem was solved by explicit exclusion of Jackson related libraries in jboss-deployment-structure.xml file (as shown on code below). Without these exlusions Wildfly was forcing its own Jackson lib located in /wildfly/modules/system/layers/base/ path (e.g. wildfly/modules/system/layers/base/com/fasterxml/jackson/core/jackson-core) which is 2.10.5 for Wildfly 21.0.2. Wildfy is doing this regardless of specifing custom version in maven pom.xml. Also I wasn't able to find any mention about this "embedded" Jackson version in Wildfly through management console, so it was a bit pain to realize where is the problem. Maybe this will save someone else some time.
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.3">
<deployment>
<exclusions>
<module name="com.fasterxml.jackson.core.jackson-core" />
<module name="com.fasterxml.jackson.core.jackson-databind" />
<module name="com.fasterxml.jackson.datatype.jackson-datatype-jdk8" />
<module name="com.fasterxml.jackson.datatype.jackson-datatype-jsr310" />
<module name="com.fasterxml.jackson.jaxrs.jackson-jaxrs-json-provider" />
<module name="org.jboss.resteasy.resteasy-jackson2-provider" />
</exclusions>
<dependencies>
<module name="jdk.unsupported"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
I didn't think I would end up here but after a lot of Google and StackOverflow searches here I'm.
This is my exact problem except that I can't afford to make code changes.
The WAR I'm trying to deploy includes a JMS library (i.e. javax.jms, which I cannot exclude form the WAR.) which is already loaded by Jboss EAP 7 by default. The path to jar is something like this jboss/modules/system/layers/base/javax/jms/api/ain/jboss-jms-api_2.0_spec-1.0.0.Final-redhat-1.jar. Because of this two different versions of the same classes loading I'm getting ClassCastException.
org.apache.activemq-ra.ActiveMQConnectionFactory cannot to be cast to javax.jms.ConnectionFactory
So, I want Jboss to NOT load javax.jms so that my application can use the JAR included with the WAR.
So, I was wondering if there was any way to exclude the module globally (for all WAR deployments).
Excluding it per deployment would work too. And I do realize it can be acheivd using jboss-deployment-structure.xml but I can't get it to work.
Here is what I tried:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure
xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<exclude-subsystems>
<subsystem name="javax" />
<subsystem name="javax.jms" />
</exclude-subsystems>
</deployment>
</jboss-deployment-structure>
and
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure
xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<exclusions>
<module name="javax" />
<module name="javax.jms" />
<module name="javax.jms.api" />
</exclusions>
</deployment>
</jboss-deployment-structure>
I placed the file in WEB-INF directory. It didn't work. It still loaded the JMS class from modules folder of Jboss EAP. So, how do I correctly do this?
The correct jboss-deployment-structure.xml is here:
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<exclude-subsystems>
<subsystem name="messaging-activemq"></subsystem>
</exclude-subsystems>
<exclusions>
<module name="javax.jms.api"></module>
</exclusions>
</deployment>
</jboss-deployment-structure>
This way you exclude both messaging subsystem and the JMS api.
You should remove the JMS API JAR from your deployment. You can still keep the JMS implementation JAR in your deployment but that should probably end up in a RAR, preferably outside your deployment.
This link has some things you could try.
Notably:
I think the problem is that activemq-all-5.4.2.jar contains javax.jms.*. Your deployment already gets this implicitly from the javaee.api module (see more information about implicity module dependencies here). I don't think it is appropriate for an application module/jar to package Java EE interfaces. You can try simply deleting the javax directory from activemq-all-5.4.2.jar or using a different set of ActiveMQ jars in your module to limit it to only what you need.
and/or altering your module.xml for ActiveMQ
<module xmlns="urn:jboss:module:1.0" name="activemq">
<resources>
<resource-root path="activemq-all-5.4.2.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
</dependencies>
</module>
There appears to be a method to embed ActiveMQ in Jboss as well, if you're interested. I won't pull out information from that article, as it doesn't answer the original question.
I am getting this error:
java.lang.ClassCastException: org.apache.jcp.xml.dsig.internal.dom.DOMReference cannot be cast to org.jcp.xml.dsig.internal.dom.DOMReference
Maybe the problem is on the jboss-deployment-structure.xml of the servlet:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
<deployment>
<dependencies>
<module name="javax.api"/>
<module name="org.apache.santuario.xmlsec"/>
<module name="org.apache.xerces" />
<system export="true">
<paths>
<path name="com/sun/org/apache/xerces/internal/dom"/>
</paths>
</system>
</dependencies>
</deployment>
</jboss-deployment-structure>
Do you have any hint of whats going on?
Thanks in advance.
Your problem is different xmlsec library version.
org.apache.jcp.xml.dsig.internal.dom.DOMReference located in xmlsec-1.5.1.jar (org.apache.santuario.xmlsec module in JBoss)
org.jcp.xml.dsig.internal.dom.DOMReference located in xmlsec-1.4.3.jar (dependency in your pom.xml)
Jboss 7 uses isolated modules https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7 it is complicated and i really don't know how it works inside.
But if simplify, when jboss start, it loads xmlsec-1.5.1, when start your application, it loads xmlsec-1.4.3. As result you have class cast exception, when pass DOMReference object between jboss and webapp classloders.
You can resolve your issue in different ways:
remove dependency of org.apache.santuario.xmlsec module in jboss-deployment-structure.xml. Application will use his own defined xmlsec-1.4.3 library
locate dependency xmlsec in pom.xml, set version to 1.5.1, and set scope to provided. Application will use JBoss module with xmlsec-1.5.1
locate dependency xmlsec in pom.xml and exclude it completly, if your code complies without xmlsec dependency. Application will use JBoss module with xmlsec-1.5.1
mvn:dependency:tree command helps here.
I've been having problems with jboss/logback and I made a jboss-deployment-structure.xml and it looks like this
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<ear-subdeployments-isolated>false</ear-subdeployments-isolated>
<deployment>
<!-- Exclusions allow you to prevent the server from automatically adding
some dependencies -->
<exclusions>
<module name="org.apache.commons.logging" />
<module name="org.slf4j" />
<module name="org.slf4j.ext" />
<module name="org.slf4j.impl" />
<module name="org.apache.log4j" />
</exclusions>
</deployment>
</jboss-deployment-structure>
this is in the META-INF folder of the EAR, but now I've been thinking... the EAR also has a lib folder that has:
slf4j-api.jar,
logback-classic.jar,
logback-core.jar, and
log4j-over-slf4j.jar
as well as the other two other ejb projects wrapped up in it during deployment time.
my question is, do I have to specify the jars and other other ejb projects as sub-deployments in the jboss-deployment-structure.xml??
also, the jboss-deployment-structure.xml has been basically ignored everytime I deploy the ear and start the server, i know this because the server still is accessing the exclusions i have declared, is the xml in the right spot in the meta-inf of the ear?
thank you for the help
Yes I added the jars as subdeployments and fixed errors
I'm currently stuck in the middle of a JBoss migration project from version 4.2.2GA to Wildfly 8.0.0.Final. The project uses the Oracle OCI driver for database access and Oracle AQ with it. Now, I'm starting Wildfly with the environment variable 'LD_LIBRARY_PATH' set to the location where the OCI native implementations reside and everything works fine, except AQ. This is the error I get when the AQ API is used: oracle.jms.AQjmsSession.ociinit([JIIZSII)J: java.lang.UnsatisfiedLinkError: oracle.jms.AQjmsSession.ociinit([JIIZSII)J
This is my module:
path: ${WILDFLY_HOME}/modules/oracle/aq/api/main
contents: aqapi.jar, module.xml
module.xml:
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="oracle.aq.api">
<resources>
<resource-root path="aqapi.jar" />
</resources>
<dependencies>
<module name="javax.api" />
<module name="javax.jms.api" />
<module name="oracle.jdbc" />
</dependencies>
</module>
So the question now is, what is the reason Wildfly does not propagate the 'LD_LIBRARY_PATH' to the module classloader?
For older JBoss versions I found this issue: https://issues.jboss.org/browse/SOA-3570 which propagates to put the aqapi.jar into the server lib folder as we are doing so for JBoss 4. But how can I solve this issue for Wildfly? Any Ideas?
Thanks!
After a long journey through the shallows of the internet and many tries a colleague of mine finally found a solution.
The solution was to combine both modules to one jdbc/aq module looking so:
path: ${WILDFLY_HOME}/modules/oracle/jdbcaq/main
contents: ojdbc5.jar, aqapi.jar, orai18n.jar, module.xml
module.xml:
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="oracle.jdbcaq">
<resources>
<resource-root path="aqapi.jar" />
<resource-root path="ojdbc5.jar"/>
<resource-root path="orai18n.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="javax.jms.api" />
<module name="javax.transaction.api"/>
</dependencies>
</module>
I think this is somehow related to the module classloaders of wildfly. Maybe the communication between both modules (jdbc and aq) requires the native implementations to be loaded by the same classloader which causes this error when using two modules instead of a single one.
Instead of setting LD_LIBRARY_PATH, a JBoss/WildFly module can also automatically look for native libraries in a module: https://docs.jboss.org/author/display/MODULES/Native+Libraries
So you can load your shared libraries in ${WILDFLY_HOME}/modules/oracle/jdbcaq/main/lib/linux-x86_64/ either by copying .so files or thanks a symbolic link.