When I deploy my .war file in JBoss AS 7.1.1 and call
FacesContext.class.getPackage().getImplementationTitle()
and
FacesContext.class.getPackage().getImplementationVersion()
I get a different version then when I deploy it on tomcat.
JBoss: JSF JavaServer Faces API 2.0.1.Final
Tomcat: JSF Mojarra 2.0.6-FCS
It seems JBoss is not picking the correct JARs that I have in my WEB-INF\lib\.
This causes different behaviour in my website.
I tried to solve the problem with
<context-param>
<param-name>org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL</param-name>
<param-value>true</param-value>
</context-param>
But that didn't work. I read Alternative JSF implementation with JBoss 71 but apparently it is not solved in 7.1.1.
I added jboss-deployment-structure.xml to WEB-INF\ with the following content.
<jboss-deployment-structure>
<deployment>
<exclusions>
<module name="javax.faces.api" slot="main"/>
<module name="com.sun.jsf-impl" slot="main"/>
</exclusions>
<dependencies>
<module name="org.apache.commons.logging" />
<module name="org.apache.commons.collections" />
<module name="org.apache.log4j" />
<module name="org.dom4j" />
<module name="javax.faces.api" slot="1.2"/>
<module name="com.sun.jsf-impl" slot="1.2"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
But then my app is not deployed and I get the following errors in server.log:
14:06:14,733 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-4) Critical error during deployment: : com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! Class org.jboss.as.web.deployment.jsf.JandexAnnotationProvider is not an instance of com.sun.faces.spi.AnnotationProvider
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:357) [jsf-impl.jar:2.0.6-FCS]
How can I solve my problem?
Could there be something else that depends on the JSF API? I'm not sure why it would be different between JBoss and Tomcat, but try running mvn dependency:tree and mvn dependency:analyze with and without the JSF excluded.
JBoss AS 7.1.1 is by default with JSF 2, but is backward compatible with JSF 1.2.
I had the same issue and solved it as follow: I used the same jboss-deployment-structure.xml as you and added the following parameter in the web.xml:
<context-param>
<param-name>org.jboss.jbossfaces.JSF_CONFIG_NAME</param-name>
<param-value>Mojarra-1.2</param-value>
</context-param>
You don't need the JSF 1.2 JARs in the lib directory (and thus the org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL parameter is not needed in web.xml).
Source: http://tapas-tanmoy-bose.blogspot.ch/2014/01/how-to-run-jsf-12-application-in-jboss.html
I suspect JBoss AS 7.1.1 to ignore the excluded modules of jboss-deployment-structure.xml for JSF (but I have org.hibernate as another excluded module which is effectively excluded, proving that the jboss-deployment-structure.xml is taken into account).
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 want develop REST service with oauth2 security. I selected JBOSS Stack technology JBOSS.8(wildfly)+RestEasy.3.0.5. In RestEasy guide i founded how to enable oauth module.
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="org.jboss.resteasy.resteasy-yaml-provider" services="import"/>
<module name="org.jboss.resteasy.resteasy-jsapi" services="import"/>
<module name="org.jboss.resteasy.resteasy-jackson-provider" services="import"/>
<module name="org.jboss.resteasy.skeleton-key"/>
<module name="org.jboss.resteasy.resteasy-multipart-provider" services="import"/>
<module name="org.jboss.resteasy.resteasy-jaxrs" services="import"/>
</dependencies>
</deployment>
After start JBOSS write in logs
JBAS018759: Failed to load module: deployment.Astron-Service_Web.war:main
Caused by: org.jboss.modules.ModuleNotFoundException: org.jboss.resteasy.skeleton-key:main"}}
How to fix. Or how to easy implement security on rest service?
You have to install the module "org.jboss.resteasy.skeleton-key" in your jboss/wildfly server.
The module can be found in your downloaded resteasy project folder, in a zip named like "resteasy-jboss-modules-wfX-X.X.XX.Final.zip" for Wildfly. (There is also one for Jboss).
The github documentation of the project advice us to unzip the full folder under the module directory of our server (like wildfly-9.0.1.Final\modules).
Personnally I encountered severals new errors and have then just installed the "org\jboss\resteasy\skeleton-key" module. (maybe due to my wildfly 9.0 installation and modules in v8.0)
Links:
github project :
https://github.com/resteasy/Resteasy/tree/master/jaxrs/examples/oauth2-as7-example
module installation : http://www.mastertheboss.com/jboss-server/jboss-as-7/how-to-install-a-module-on-jboss-as-7
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.