What other choice do I have as JNDI lookup is still not ready with JBOSS 7 for lookup.

#1: I'm not sure what that means. Can you explain a bit?

Then the option that is left is to use the remote protocol to access the endpoints and queues.

#2: To be able to use remote protocol, you still don't have to package that jar within your application. You'll have to explain a bit more on what you are trying to do, so that we can help appropriately.

Sure.

For the question #1:

I am trying to develop war applications with JMS support. I don't want to have any MDB support for my JMS receievers. I will write simple clients for JMS receivers and senders so that I do have the complete control on JMS sessions. This is my objective. Now for the implementation part to support JMS applications, we have the choices of looking up the queues/connection factories etc using JNDI which runs in the standard port of 1099/TCP or statically configure the queues at the client side (so no lookup is required). As far as I know, JNDI support is still not there in JBOSS 7 nor do I see any place to enable it. That rules out my option to use JNDI lookups. The other option is to use the remote protocol for JBOSS using the jboss client (that is packaged with JBOSS AS) and this will be used to lookup the "/RemoteConnectionFactory" that is exported (and not the "/ConnectionFactory" as it might be restricted to use with remote client).

For the question #2:

I may be wrong in packaging the remote client with the WAR. I haven't tried to use remote JBOSS module dependency to use for remote protocol connection. Is that what you are trying to say ?

If you see the original stack trace, it shows that the jboss-beans.xml is indeed loaded from modules. If you check netty's jar, it packages jboss-beans.xml file in it.

Which original stack-trace? The one in initial post?

Yes. The one in the initial post.

Where does it show that it comes from Netty? ;-)

I just want to add one point. The log that is there in the initial post was copied from another internal application. But I have written the proof of concept applications that triggers the same error (which was attached in the initial post).

If you check the log and see the "Caused By" section, you will see the following

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

When the first appliacation is deployed, there will not be any errors. But when the second application is deployed, the above Exception is thrown. I found that it was caused by netty after debuggin the issue. If you can see the MANIFEST.MF files in those two sample applications attached, you will see that "netty" module is exported for sample applications. And this error is thrown, just after trying to load the netty module for deployment of the second app. Also you can see in the netty jar that it includes jboss-beans.xml with a beans initialization for "org.jboss.netty.internal.LoggerConfigurator".

When the first appliacation is deployed, there will not be any errors. But when the second application is deployed, the above Exception is thrown. I found that it was caused by netty after debuggin the issue. If you can see the MANIFEST.MF files in those two sample applications attached, you will see that "netty" module is exported for sample applications. And this error is thrown, just after trying to load the netty module for deployment of the second app. Also you can see in the netty jar that it includes jboss-beans.xml with a beans initialization for "org.jboss.netty.internal.LoggerConfigurator".

When the first appliacation is deployed, there will not be any errors. But when the second application is deployed, the above Exception is thrown. I found that it was caused by netty after debuggin the issue. If you can see the MANIFEST.MF files in those two sample applications attached, you will see that "netty" module is exported for sample applications. And this error is thrown, just after trying to load the netty module for deployment of the second app. Also you can see in the netty jar that it includes jboss-beans.xml with a beans initialization for "org.jboss.netty.internal.LoggerConfigurator".

I guess both sample applications use jboss-client.jar, right?

Yes. Both applications use jboss-client for remote protocol connection

02:28:17,693 WARN [org.jboss.as.messaging] (MSC service thread 1-13) JBAS011600: AIO wasn't located on this platform, it will fall back to using pure Java NIO. If your platform is Linux, install LibAIO to enable the AIO journal

02:29:08,320 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) JBAS018567: Deployment "deployment.appone.war" is using a private module ("org.antlr:main") which may be changed or removed in future versions without notice.

02:29:08,321 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) JBAS018567: Deployment "deployment.appone.war" is using a private module ("org.apache.commons.beanutils:main") which may be changed or removed in future versions without notice.

02:29:08,322 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) JBAS018567: Deployment "deployment.appone.war" is using a private module ("org.apache.commons.cli:main") which may be changed or removed in future versions without notice.

02:29:08,323 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) JBAS018567: Deployment "deployment.appone.war" is using a private module ("org.apache.commons.codec:main") which may be changed or removed in future versions without notice.

02:29:08,324 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) JBAS018567: Deployment "deployment.appone.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice.

02:29:08,325 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) JBAS018567: Deployment "deployment.appone.war" is using a private module ("org.apache.commons.lang:main") which may be changed or removed in future versions without notice.

02:29:08,327 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) JBAS018567: Deployment "deployment.appone.war" is using a private module ("net.jcip:main") which may be changed or removed in future versions without notice.

02:29:08,328 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) JBAS018567: Deployment "deployment.appone.war" is using a private module ("org.jboss.netty:main") which may be changed or removed in future versions without notice.

02:29:19,494 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) JBAS018567: Deployment "deployment.apptwo.war" is using a private module ("org.antlr:main") which may be changed or removed in future versions without notice.

02:29:19,495 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) 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.

02:29:19,496 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) 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.

02:29:19,496 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) 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.

02:29:19,497 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) 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.

02:29:19,498 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) 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.

02:29:19,498 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) JBAS018567: Deployment "deployment.apptwo.war" is using a private module ("net.jcip:main") which may be changed or removed in future versions without notice.

02:29:19,499 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) 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.

JBAS014777: Services which failed to start: service jboss.deployment.unit."apptwo.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."apptwo.war".INSTALL: Failed to process phase INSTALL of deployment "apptwo.war"

02:29:19,499 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) 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.

It's a pure coincidence that this line is just before the stack-trace.

Try deploying an app w/o jboss-client.jar, but still with dependency to Netty.

I have deploy multiple EARs in a JBoss 7.1 connecting to an external (localhost) standalone HornetQ

In the standalone.xml of JBoss,

Add netty-connector under connectors with your own socket binding

Add connection-factory under jms-connection-factories, w/ connector-ref to the one in (1) and an entry name used for JNDI

Add outbound-socket-binding with remote-destination to the HornetQ

In your application, lookup the JNDI name defined in inside connection-factory

You must be sure the netty.jar didn't appear in your WAR. Maven may "accidentally" put it inside your WAR, and I don't know why it is being initialized and hold up something s.t. the second initialization (of netty.jar in another WAR) throw exception.

Also the application in the WAR cannot use netty classes directly though there's also one HornetQ running inside the JBoss (yes, I have two, one inside JBoss to waste memory, another one standalone working hard).

I have three EARs with my own JMS Session to receive messages. There's some issue with Spring's DefaultMessageListenerContainer (hope I still spell it correctly) and our team eventually drop it and implement our own.