-
1. Communication between JBoss AS 5 and JBoss AS 6
wolfc Feb 11, 2011 8:55 AM (in response to atijms)It'll only work if you call the other server from within an isolated environment.
-
2. Communication between JBoss AS 5 and JBoss AS 6
atijms Feb 11, 2011 9:15 AM (in response to wolfc)Interesting!
It looks a little tricky, but I'll give it a try. Thanks for the pointer.
As a related question, is there any work going on within JBoss to make this a little bit more straightforward?
Even when simply using a Java SE client, I found the JBoss AS client drivers are a bit unwieldy. Idealistically there would be a single small jar called jbossas-6.0.jndi.jar, that could be used in either Java SE, another JBoss AS version or another Java EE AS.
-
3. Communication between JBoss AS 5 and JBoss AS 6
atijms Feb 11, 2011 10:02 AM (in response to wolfc)p.s. just wondering, where is the following deployer from the alunite project used for:
The blog also mentions this:
As Jaikiran correctly pointed out, the current bean proxy needs to be called within the correct context class loader. So we would also need a specialized external context which return wrappers to allow setting the thread context class loader at the right moment.
Was this specialized external context ever created? Was this really necessary? The following comment seems to suggest it works, but there is no reference to this special context: http://community.jboss.org/message/569459#569459
-
4. Re: Communication between JBoss AS 5 and JBoss AS 6
atijms Feb 11, 2011 10:41 AM (in response to atijms)I created a new dynamic web project for JBoss AS 6 and added the AluniteClassLoader to this project just by copying the .java file.
Using the following code inside a Singleton EJB bean, I get an exception however:
URL[] urls = new URL[2]; urls[0] = new URL("file:///opt/jboss/client/jbossall-client.jar"); URLClassLoader urlCl = new URLClassLoader(urls, null); ClassLoader cl = new AluniteClassLoader(urlCl, ClassLoader.getSystemClassLoader()); ClassLoader previous = Thread.currentThread().getContextClassLoader(); Thread.currentThread().setContextClassLoader(cl); try { String providerUrl = "jnp://localhost:1199"; Properties properties = new Properties(); properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory"); properties.put(Context.URL_PKG_PREFIXES, "jboss.naming:org.jnp.interfaces"); properties.put(Context.PROVIDER_URL, providerUrl); InitialContext ic = new InitialContext(properties); Object test = ic.lookup("abc"); } finally { Thread.currentThread().setContextClassLoader(previous); }
The exception is:
Caused by: java.lang.NullPointerException at sun.net.util.URLUtil.urlNoFragString(URLUtil.java:29) [:1.6.0_23] at sun.misc.URLClassPath.getLoader(URLClassPath.java:292) [:1.6.0_23] at sun.misc.URLClassPath.access$000(URLClassPath.java:60) [:1.6.0_23] at sun.misc.URLClassPath$1.next(URLClassPath.java:195) [:1.6.0_23] at sun.misc.URLClassPath$1.hasMoreElements(URLClassPath.java:206) [:1.6.0_23] at java.net.URLClassLoader$3$1.run(URLClassLoader.java:416) [:1.6.0_23] at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_23] at java.net.URLClassLoader$3.next(URLClassLoader.java:413) [:1.6.0_23] at java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:438) [:1.6.0_23] at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:27) [:1.6.0_23] at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:36) [:1.6.0_23] at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:27) [:1.6.0_23] at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:36) [:1.6.0_23] at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:27) [:1.6.0_23] at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:36) [:1.6.0_23] at com.sun.naming.internal.VersionHelper12$InputStreamEnumeration$1.run(VersionHelper12.java:197) [:1.6.0_23] at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_23] at com.sun.naming.internal.VersionHelper12$InputStreamEnumeration.getNextElement(VersionHelper12.java:194) [:1.6.0_23] at com.sun.naming.internal.VersionHelper12$InputStreamEnumeration.hasMore(VersionHelper12.java:214) [:1.6.0_23] at com.sun.naming.internal.ResourceManager.getApplicationResources(ResourceManager.java:470) [:1.6.0_23] at com.sun.naming.internal.ResourceManager.getInitialEnvironment(ResourceManager.java:159) [:1.6.0_23] at javax.naming.InitialContext.init(InitialContext.java:219) [:1.6.0_23] at javax.naming.InitialContext.<init>(InitialContext.java:197) [:1.6.0_23]
There is a JBoss AS 5.1 instance running at localhost:1199
Any idea?
-
5. Communication between JBoss AS 5 and JBoss AS 6
henk53 Feb 14, 2011 4:08 AM (in response to atijms)As a related question, is there any work going on within JBoss to make this a little bit more straightforward?
I wonder if this will ever get 'fixed'. EJB remote communication has come a long way. From being arcane and over complicated in the EJB1 and EJB2 days, to actually pretty convenient and straightforward these days as long as both ends are the exact same application server.
If JNDI lookups were somehow to be standardized, it would be a major help.
You would then however still run into problems when doing lookups for say a remote JMS queue (another important use-case for remote JNDI lookups). The thing is that there is no universal standard type that represents the remote queue, you need to have the exact type used by the remote server locally, even though it actually always comes down to this type just being a wrapper for a string or at most a string pair.