When attempting to create a new InitialDirContext using the com.sun.jndi.dns.DnsContextFactory on JBoss AS 7, the following exception occurs:
Caused by: javax.naming.NamingException: Failed instantiate InitialContextFactory com.sun.jndi.dns.DnsContextFactory from classloader ModuleClassLoader for Module "deployment.test-case.ear.test-web.war:main" from Service Module Loader
at org.jboss.as.naming.InitialContextFactoryBuilder.createInitialContextFactory(InitialContextFactoryBuilder.java:58)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:664) [:1.6.0_26]
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288) [:1.6.0_26]
at javax.naming.InitialContext.init(InitialContext.java:223) [:1.6.0_26]
at javax.naming.InitialContext.(InitialContext.java:197) [:1.6.0_26]
at javax.naming.directory.InitialDirContext.(InitialDirContext.java:82) [:1.6.0_26]
at com.test.messaging.internal.resource.dns.DnsClientImpl.querySrv(DnsClientImpl.java:328) [dns-lookup-jar.jar:]
...
16:36:36,000 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Error listenerStart
16:36:36,013 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Context [/test] startup failed due to previous errors
16:36:36,023 INFO [org.jboss.web] (MSC service thread 1-5) registering web context: /test
Here is the relevant code snippet:
Hashtable env = new Hashtable();
env.put("java.naming.factory.initial", "com.sun.jndi.dns.DnsContextFactory");
env.put("java.naming.authoritative", "false");
env.put("com.sun.jndi.dns.recursion", "true");
env.put("com.sun.jndi.dns.timeout.initial", timeoutProp);
env.put("com.sun.jndi.dns.timeout.retries", "1");
env.put("java.naming.provider.url", providerProp);
DirContext ctx = new InitialDirContext(env);
The code is invoked from within a ServletContextListener and therefore the exception prevents the module from starting. I've also removed the listener and have attempted to invoke the code from within a servlet, which produced the same results (javax.naming.NamingException: Failed instantiate InitialContextFactory com.sun.jndi.dns.DnsContextFactory).
I found this thread which seemed very similar to the problem that I am running into, but setting the "jboss.modules.system.pkgs" property to "com.sun.jndi.dns," as the thread mentions, had no effect.
The code works correctly on JBoss 6, WebSphere Application Server 7, and Geronimo 2.2.1 (on Tomcat 6), but is failing on JBoss 7 as described above. I'm running JBoss AS 7.0.0.Final and testing using the standalone server, using the 1.6.0_26 JRE. Any suggestions on how to resolve this problem would be greatly appreciated.
I also posted this question on the JBoss development community forum, but have not received any replies.
[UPDATE] It seems this problem is likely related to JBoss 7's new isolated, modular class loading policies. I found two workarounds/solutions to this problem, but I'm still interested in suggestions on the most appropriate, recommended approach, particularly if there is a way that we can avoid manual modifications to our applications or JBoss installations.
MANIFEST.MF
Create a com.sun.jndi.dns module, by copying $JBOSS_HOME/modules/com/sun/jndi/ldap to $JBOSS_HOME/modules/com/sun/jndi/dns and modify occurrences of "ldap" to "dns"
Add the following entry to the web module's MANIFEST.MF: Dependencies: com.sun.jndi.dns
Although this now allows the DnsContextFactory to instantiate properly, this doesn't seem to be a permanent solution since it requires modification of all JBoss installations as well as all applications that use the DnsContextFactory.
jboss-deployment-structure.xml
Add a jboss-deployment-structure.xml file to the EAR's META-INF directory, as follows:
<sub-deployment name="test-web.war">
<dependencies>
<module name="deployment.com.sun.jndi.dns" />
</dependencies>
</sub-deployment>
<module name="deployment.com.sun.jndi.dns">
<dependencies>
<module name="system" export="false">
<exports>
<include-set>
<path name="com/sun/jndi/dns"/>
</include-set>
</exports>
</module>
</dependencies>
</module>
This is slightly better than the previous "MANIFEST.MF" approach, since it only requires modification to the application, and not also the JBoss modules, but is unfortunate that all applications that use the DnsContextFactory must include this configuration.
I'm still looking for suggestions on the most appropriate, recommended approach, particularly if there is a way that we can avoid including more JBoss-specific configuration in our applications.
Thanks to some help on the JBoss forum, it's been confirmed that the workarounds I mentioned above may work, but the most appropriate solution requires a feature request from JBoss. I've logged this feature request, and in the meantime, another temporary solution is to add the "com/sun/jndi/dns" path to the sun.jdk module descriptor ($JBOSS_HOME/modules/sun/jdk/main/module.xml).
Related
I am migrating my JBoss 5 to jboss 7 using cics resource adaptor configuration for the cics.rar. the resources Adopters definition and configuration is done on standalone-full.xml file. i am facing belolw error while hitting to application which is trying to connect to cics mainframe using cics rar.
Exception Logged
by:com.ibm.connector2.cics.ECIInteraction
com.ibm.connector2.cics.CICSUserInputException: CTG9628E
InteractionSpec passed to execute() not of type ECIInteractionSpec at com.ibm.connector2.cics.ECIInteraction.execute(Unknown Source)
1.I have already checked the type passed in the execute method is of ECIInteractionSpec type only
2. Have followed the solution provided on below link but it did not work .
Jboss CICS interaction for calling Mainframe using Resource Adapter
Any suggestions much appreciated .
I think this solution might apply to your situation. Error executing CICS request while deploying app into IBM liberty Profile
The poster states, "The project got included transitive dependencies to very old versions of cicseci library. I excluded them."
The Java Connector Architecture (JCA) level implemented in the CICS TG product has changed with the newer versions of JEE application servers now supporting the higher level of the JCA specification. This may be the case with your upgrade.
I would suggest that you make sure you have obtained the cicseci.rar file from the /deployable/ directory where the CICS TG product is installed to make sure that your application is using the same version of the resource adapter as is supported by the CICS TG itself.
The solution that worked for me (in wildfly 12 and 21) is to add the jboss module which contains cics jars as global module in standalone-full-ha.xml:
<subsystem xmlns="urn:jboss:domain:ee:5.0">
<global-modules>
<module name="org.jboss.cics" slot="main"/>
</global-modules>
.
.
.
.
</subsystem>
I have a Wildfly 10 ear application (runs in the server container) which needs to be able to publish to a remote queue hosted on another wildfly server. To accomplish that I copied this jar from the wildfly\bin\client folder into the ear's lib folder. That worked fine.
But now, after official packaging, when i start Wildfly and the application, I get an error message... something about the manifest file of this jar.
What's the best way to set up the apllication so that this jar is found by the various class loaders?
it seems the jar could be copied to the ear\lib, but something needs to be done about the manifest file? what?
i assume Another option is to specify something in the standalone-full.xml that tells the wildfly class loader to include the wildfly/bin/client folder in its classpath. How do you that?
And thirdly, i assume the file can just be copy-pasted into a folder that is already in wildfly classpath.
A forth option, i assume is to add something to my ear producing pom.xml which will add this jar to the ear/lib....
What's the best way to do this?
the errors i'm getting is:
14:54:45,578 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."InSyncEar.ear".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."InSyncEar.ear".STRUCTURE: WFLYSRV0153: Failed to process phase STRUCTURE of deployment "InSyncEar.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYSRV0161: Failed to get manifest for deployment "/C:/MyComp/Purch/deployments/InSyncEar.ear/lib/jboss-client.jar"
at org.jboss.as.server.deployment.module.ManifestAttachmentProcessor.getManifest(ManifestAttachmentProcessor.java:78)
at org.jboss.as.server.deployment.module.ManifestAttachmentProcessor.deploy(ManifestAttachmentProcessor.java:65)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
... 5 more
Caused by: java.util.zip.ZipException: invalid literal/lengths set
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:122)
at org.jboss.vfs.util.PaddedManifestStream.read(PaddedManifestStream.java:39)
at java.io.InputStream.read(InputStream.java:170)
at java.util.jar.Manifest$FastInputStream.fill(Manifest.java:441)
at java.util.jar.Manifest$FastInputStream.readLine(Manifest.java:375)
at java.util.jar.Manifest$FastInputStream.readLine(Manifest.java:409)
at java.util.jar.Attributes.read(Attributes.java:376)
at java.util.jar.Manifest.read(Manifest.java:199)
at java.util.jar.Manifest.<init>(Manifest.java:69)
at org.jboss.vfs.VFSUtils.readManifest(VFSUtils.java:243)
at org.jboss.vfs.VFSUtils.getManifest(VFSUtils.java:227)
at org.jboss.as.server.deployment.module.ManifestAttachmentProcessor.getManifest(ManifestAttachmentProcessor.java
Once your JMS client is running within a WildFly application - you don't need for the the jboss-client.jar at all - WildFly modules by themselves contain all necessary dependencies for publishing to a remote queue on another WildFly instance.
In our projects the best way for remote EJB and JMS connections is the following config in the standalone-full.xml:
<subsystem xmlns="urn:jboss:domain:ee:4.0">
<global-modules>
<module name="org.jboss.remote-naming"/>
</global-modules>
...
This allows to lookup for a remote JMS connection on another server through the jms/RemoteConnectionFactory there, e.g. see this example.
Additionally you need the ActiveMQ specific dependencies (e.g. ActiveMQJMSConnectionFactory) to publish to a remote queue.
We did it by adding the corresponding module as a dependency in the jboss-deployment-structure.xml:
<dependencies>
<module name="org.apache.activemq.artemis" export="true"/>
</dependencies>
see Class Loading in WildFly for more details.
That's it.
I have to confess that I am not familiar with jboss, but I have a task to launch application that works on top of it. The application was running before restart but is not able to get launched after. The following exception is raised on attempt to run it:
12:40:08,680 INFO [TomcatDeployment] deploy, ctxPath=/
12:40:08,777 INFO [TomcatDeployment] deploy, ctxPath=/geoserver
12:40:08,971 ERROR [JBossContextConfig] XML error parsing: context.xml
org.jboss.xb.binding.JBossXBRuntimeException: Failed to create a new SAX parser
at org.jboss.xb.binding.UnmarshallerFactory$UnmarshallerFactoryImpl.newUnmarshaller(UnmarshallerFactory.java:100)
at org.jboss.web.tomcat.service.deployers.JBossContextConfig.processContextConfig(JBossContextConfig.java:557)
at org.jboss.web.tomcat.service.deployers.JBossContextConfig.init(JBossContextConfig.java:543)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:279)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.core.StandardContext.init(StandardContext.java:5436)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4148)
Are there any typical causes for this problem?
This error is usually thrown when you package XML parser jars (eg. xerces or SAXParser) in your deployment artifact (ie. WAR, EAR) files. JBoss provides its own XML parsing libraries which is available to your application as part of the parent class loader. You may also need to re-compile your application against the JBoss run time libraries. A good rule of thumb is to not duplicate jars that are already provided by the JEE container. You can work around it by implementing classloading isolation, however, I think it's best to start by removing the JEE container provided jars first.
I come from a heavy .NET/IIS background and although I have worked with Java in the past, I am fairly new to large Java web applications so please bear with me. Due to my limited background, I will walk through the steps I took from the very start trying to get this app to deploy (in case my "fix" for another issue could have broken something else).
I am having trouble deploying a Spring/Hibernate application to the WildFly application server. The application itself definitely works because it is a sample project in an open-source eCommerce framework (Broadleaf Commerce). I have also successfully got it to run on Jetty locally.
The application uses three JNDI data sources which I have configured in WildFly/JBoss; I have confirmed that the application sees them because I tried running it prior to configuring the DS's and it gave a clear error, which it no longer did after I configured them.
Afterwards, the application would throw three different errors (one per each PU) saying that it was unable to start the persistence units due to a class loading exception. This error I was able to fix by adding a jboss-deployment-structure.xml file into WEB-INF with the following contents (based on what I understand, this file is needed because this app has all of the Hibernate JARs within its WAR file already, and thus the below file tells JBoss not to supply its own Hibernate implementation):
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<exclusions>
<module name="org.hibernate"/>
<module name="org.javassist"/>
<module name="org.apache.log4j" />
</exclusions>
<dependencies>
<module name="org.jboss.ironjacamar.jdbcadapters" slot="main"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
After adding the above file, I now get this set of three (one per each PU) errors:
23:15:16,791 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) JBAS014774: Service status report
JBAS014777: Services which failed to start: service jboss.persistenceunit."admin.war#blPU".__FIRST_PHASE__: org.jboss.msc.service.StartException in service jboss.persistenceunit."admin.war#blPU".__FIRST_PHASE__: java.util.ServiceConfigurationError: org.hibernate.integrator.spi.Integrator: Provider org.hibernate.envers.event.EnversIntegrator not a subtype
service jboss.persistenceunit."admin.war#blSecurePU".__FIRST_PHASE__: org.jboss.msc.service.StartException in service jboss.persistenceunit."admin.war#blSecurePU".__FIRST_PHASE__: java.util.ServiceConfigurationError: org.hibernate.integrator.spi.Integrator: Provider org.hibernate.envers.event.EnversIntegrator not a subtype
service jboss.persistenceunit."admin.war#blCMSStorage".__FIRST_PHASE__: org.jboss.msc.service.StartException in service jboss.persistenceunit."admin.war#blCMSStorage".__FIRST_PHASE__: java.util.ServiceConfigurationError: org.hibernate.integrator.spi.Integrator: Provider org.hibernate.envers.event.EnversIntegrator not a subtype
There is a file called hibernate-envers-4.1.11.Final.jar inside the WAR archive. Also remember that this is the same WAR (except the jboss-deployment-structure.xml file) which ran successfully on Jetty.
I tried poking around but simply have no idea where to look... I tried changing the DS's in WildFly to use a JDBC4-based driver as well as a JDBC41 (probably has nothing to do with it) with no luck. I know it is probably something very simple and is related to configuration (of either WildFly or the application itself), but I am not sure where to poke around.
My completely out of the blue take on it is that WildFly is still somehow trying to load an older version of Hibernate, which the classes in the bundled 4.1.11 Envers JAR are trying to override but cannot (or vice versa).
If it is of any use - the app is trying to connect to a PostgreSQL 9.3 database and the DS's defined in WildFly work as far as clicking "Test Connection" goes.
If there is any other info I can provide which would be helpful, please let me know.
Any insights or hints would be very much appreciated.
The Wildfly server has a Hibernate 4.3 version. To use Hibernate 4.1 you have to exclude the default Hibernate and package the correct one.
Class Loading in WildFly
Example:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<exclusions>
<module name="org.hibernate" />
<module name="org.hibernate.envers" />
<module name="org.hibernate.validator" />
<module name="org.hibernate.commons-annotations" />
</exclusions>
</deployment>
</jboss-deployment-structure>
I never figured out the cause of the issue (but I am figuring it was a conflict with the JARs supplied by JBoss).
Just in case anyone is having the same issue - I ended up using Tomcat where everything worked without a hitch. I understand this isn't exactly a solution but it will work in the interim. This also possibly reinforces my initial suspicion of the JARs provided by JBoss conflicting with the bundled Hibernate JARs in the project.
I have a simple setup with a war file containing only a web.xml that specifies the javax.ws.rs.Application class to use in the servlet.
The jar that contains the implementation for javax.ws.rs.Application is also completely trivial. Both the web.xml and the implementation are based off the examples in jboss documentation
However, I get different behavior when I deploy the war + jar combination in jboss AS 7.1.1 Final versus jboss 4.0.4. Upon accessing the rest api I get the following exception in the jboss logs (snippet only):
06:33:59,540 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/wrapper]] (MSC service thread 1-2) StandardWrapper.Throwable: java.lang.RuntimeException: java.lang.ClassNotFoundException: com.projectgoth.provider.restapi.RestApiProvider from [Module "deployment.wrapper.war:main" from Service Module Loader]
at org.jboss.resteasy.spi.ResteasyDeployment.createFromInjectorFactory(ResteasyDeployment.java:271) [resteasy-jaxrs-2.3.2.Final.jar:]
at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:259) [resteasy-jaxrs-2.3.2.Final.jar:]
If however, I change the scope of the jar from provided to runtime in the war's pom.xml - the error does indeed go away from jboss as 7.1.1.
For reference, I've uploaded the code use for both the war and jar to bitbucket (where provider = implementation for the javax.ws.rs.Application, and wrapper is the war deployable)
I think this is normal. Per class loader policy, a child class can always see the parent class not the vice verse. When you put the jar scope as runtime, the JAR is loaded in the classpath up in the stream than the WAR application and hence it's visible to the WAR classes.