Fails to deploy more than one application with JMS/hornetQ support in Jboss 7.1.0.Final

[nibin012]

Hi All,

I have tried deploying multiple WAR applications to JBOSS 7.1.0.Final with JMS/horntQ support. If I am deploying only one WAR application, then my deployment is successful. But if I have more than one WAR application, then my deployment fails with the following error.

01:35:46,616 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC00001: Failed to start service jboss.deployment.unit."security.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."security.war".INSTALL: Failed to process phase INSTALL of deployment "security.war"

        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.0.Final.jar:7.1.0.Final]

        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26]

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26]

        at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26]

Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.pojo."org.jboss.netty.internal.LoggerConfigurator".DESCRIBED is already registered

        at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:154) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

        at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:227) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

        at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:560) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

        at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

        at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2228) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

        at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

        at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2228) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

        at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:307) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

        at org.jboss.as.pojo.ParsedKernelDeploymentProcessor.describeBean(ParsedKernelDeploymentProcessor.java:94)

        at org.jboss.as.pojo.ParsedKernelDeploymentProcessor.deploy(ParsedKernelDeploymentProcessor.java:76)

        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.0.Final.jar:7.1.0.Final]

        ... 5 more

I found the issue was coz of Netty trying to register its logging factory as defined in netty.jar/META-INF/jboss-beans.xml. I am not packaging any jms/hornetQ libraries inside my WAR. In my setting for each WAR application, I have added the required Dependencies in the MANIFEST.MF file.

My application is not using any MDB's or anything. Its a fair and clean JMS client written for reciever/sender and the application tries to validate the queue's setting during deployment phase through a listener invoked by context initialized hook. As it can be seen from the logs, my first WAR deploys succesfully(not shown in the log) but from my second WAR application onwards, it fails to deploy(see the log).

Does that mean that I can have only one application inside JBOSS to use messaging ?

PS: If required I can write sample WAR applications to prove this issue. Let me know. Similar setting works with Jboss 6.0.0.Final. I am trying to migrate my applications to Jboss 7

Sample applications to demonstrate the problem

[clebert.suconic]

it seems you are packaging netty, hornetq etc at your war? what you weren't supposed to do!

[nibin012]

Hi,

I didnt package netty or hornetq libraries in my application. I only gave the dependencies in the manifest file. I have written two sample applications to demonstrate this problem which is attached to the first conversation. I have also attached the standalone-full.xml file with two queues configured for the sample application. Also the queues require credentials to access them. I have also included the jndi filename where credentials are given in each application.

Let me know if any other help I can provide regarding this issue

[nibin012]

Hi,

Can anyone help me to know what I am doing wrong in this sample applications I have uploaded. Your help would be very much appreciated.

Regards,

Nibin

[alesj]

Are you sure you don't have netty.jar in your war?

As I doubt my/our code checks for jboss-beans.xml in modules.

(i could be wrong, so i'll check ...)

You could disable "pojo" subsystem, unless you're really using some legacy POJO support.

Or you could re-package netty.jar w/o this jboss-beans.xml file.

[nibin012]

Hi Ales,

I am not packaging netty.jar in my WAR. The dependency is defined in MANIFEST.MF as explained in jboss 7 documentation. I have written the sample applications which you can try deploying to $JBOSS_HOME/standalone/deployments.

[alesj]

I'll try this .war on Monday, meanwhile disable pojo subsystem, and the file will be ignored.

[nibin012]

Sure. I will try that. Thanks Ales.

[nibin012]

I disabled pojo subsystem in standalone-full.xml configuration and my WAR applications loaded successfully. Thanks for the help.

[alesj]

@Nibin: can you attach this .war?

(I guess it gets built as part of attached SampleApps.zip?)

[alesj]

OK, built the .war myself.

I now get an error, but I do see POJOs being picked up, hence I'll investigate that.

14:48:16,000 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "apptwo.war"
14:48:16,620 INFO  [org.jboss.as.pojo] (MSC service thread 1-3) JBAS017000: Found legacy bean/pojo namespace: urn:jboss:bean-deployer:2.0 - might be missing some xml features (potential exceptions).
14:48:16,666 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-1) JBAS018567: Deployment "deployment.apptwo.war" is using a private module ("org.antlr:main") which may be changed or removed in future versions without notice.
14:48:16,667 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-1) JBAS018567: Deployment "deployment.apptwo.war" is using a private module ("org.apache.commons.beanutils:main") which may be changed or removed in future versions without notice.
14:48:16,668 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-1) JBAS018567: Deployment "deployment.apptwo.war" is using a private module ("org.apache.commons.cli:main") which may be changed or removed in future versions without notice.
14:48:16,669 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-1) JBAS018567: Deployment "deployment.apptwo.war" is using a private module ("org.apache.commons.codec:main") which may be changed or removed in future versions without notice.
14:48:16,670 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-1) JBAS018567: Deployment "deployment.apptwo.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice.
14:48:16,670 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-1) JBAS018567: Deployment "deployment.apptwo.war" is using a private module ("org.apache.commons.lang:main") which may be changed or removed in future versions without notice.
14:48:16,673 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-1) JBAS018567: Deployment "deployment.apptwo.war" is using a private module ("net.jcip:main") which may be changed or removed in future versions without notice.
14:48:16,675 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-1) JBAS018567: Deployment "deployment.apptwo.war" is using a private module ("org.jboss.netty:main") which may be changed or removed in future versions without notice.
14:48:16,774 INFO  [org.jboss.as.osgi] (MSC service thread 1-3) JBAS011941: Register module: Module "deployment.apptwo.war:main" from Service Module Loader
14:48:16,883 INFO  [org.xnio] (MSC service thread 1-2) XNIO Version 3.0.3.GA
14:48:16,886 INFO  [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.0.3.GA
14:48:16,892 INFO  [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 3.2.2.GA
14:48:17,010 ERROR [org.jboss.remoting.remote.connection] (Remoting "config-based-naming-client-endpoint" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
14:48:17,013 ERROR [com.nvarghese.jboss.testapptwo.SampleQueueManager] (MSC service thread 1-2) Failed to initialize queue settings: Failed to create remoting connection: javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed]
          at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:36) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          at org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:117) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667) [classes.jar:1.6.0_31]
          at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288) [classes.jar:1.6.0_31]
          at javax.naming.InitialContext.init(InitialContext.java:223) [classes.jar:1.6.0_31]
          at javax.naming.InitialContext.<init>(InitialContext.java:197) [classes.jar:1.6.0_31]
          at com.nvarghese.jboss.testapptwo.jms.JmsQueueManager.getContext(JmsQueueManager.java:118) [classes:]
          at com.nvarghese.jboss.testapptwo.jms.JmsQueueManager.initialize(JmsQueueManager.java:63) [classes:]
          at com.nvarghese.jboss.testapptwo.SampleQueueManager.contextInitialized(SampleQueueManager.java:59) [classes:]
          at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3392) [jbossweb-7.0.15.Final.jar:]
          at org.apache.catalina.core.StandardContext.start(StandardContext.java:3850) [jbossweb-7.0.15.Final.jar:]
          at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:90) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
          at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
          at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
          at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_31]
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_31]
          at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_31]
Caused by: java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
          at org.jboss.naming.remote.protocol.IoFutureHelper.get(IoFutureHelper.java:87) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          at org.jboss.naming.remote.client.cache.ConnectionCache.get(ConnectionCache.java:42) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          at org.jboss.naming.remote.client.InitialContextFactory.createConnection(InitialContextFactory.java:153) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          at org.jboss.naming.remote.client.InitialContextFactory.getOrCreateConnection(InitialContextFactory.java:126) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          at org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:106) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          ... 15 more
Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
          at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          at org.xnio.nio.NioHandle.run(NioHandle.java:90) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          at org.xnio.nio.WorkerThread.run(WorkerThread.java:184) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          at ...asynchronous invocation...(Unknown Source)
          at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          at org.jboss.naming.remote.client.cache.EndpointCache$EndpointWrapper.connect(EndpointCache.java:110) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          at org.jboss.naming.remote.client.cache.ConnectionCache.get(ConnectionCache.java:41) [jboss-client-7.1.0.Final.jar:7.1.0.Final]
          ... 18 more


14:48:17,079 INFO  [org.jboss.web] (MSC service thread 1-2) JBAS018210: Registering web context: /apptwo
14:48:17,114 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "apptwo.war"

[alesj]

OK, found the culprit, it's not Netty. ;-)

"/content/apptwo.war/WEB-INF/lib/jboss-client-7.1.0.Final.jar/META-INF/jboss-beans.xml"

Do  you package this jboss-beans.xml file into this jar or is this already shipped with jboss-client.jar?

This also means, my/our POJO deployers work as they should,

as they are not picking jboss-beans.xml from modules, but only from deployments.

[jaikiran]

Ales Justin wrote:

OK, found the culprit, it's not Netty. ;-)

"/content/apptwo.war/WEB-INF/lib/jboss-client-7.1.0.Final.jar/META-INF/jboss-beans.xml"

Do  you package this jboss-beans.xml file into this jar or is this already shipped with jboss-client.jar?

It appears that we ship that jboss-beans.xml in the jboss-client.jar.

Nibin, you shouldn't be packaging the jboss-client.jar within the application deployment. That jar is only meant for remote standalone clients so that they can place it in the client classpath of the application.

[nibin012]

The reason why you are getting "javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed" is because, for JMS it tries to access using the credentials given in the conf file. If you can give the correct credentials with role as guest for "ApplicationRealm" will solve it.

[nibin012]

Hi Jaikiran,

What other choice do I have as JNDI lookup is still not ready with JBOSS 7 for lookup. Also I dont want to use MDB to access my queues. Then the option that is left is to use the remote protocol to access the endpoints and queues.