invoking ejb's from different weblogic servers
Chris Humphrey
Hi all,
I have a requirement on the system I am currently writing that says I must be
able to invoke an ejb (from within an ejb) running on a different server.
I have written a test application to test this out. Here is what I did:
WL Server1 running on localhost port 7001, containing ejb1
WL Server2 running on a server port 8001, containing ejb2
when ejb1 is invoked it needs to invoke ejb2 running in Server2.
I setup a Properties object with the proper credentials, create an InitialContext
and get a handle to ejb2Home, create it and want to use it.
When I first set my system up for this I got the following exception (There is
no cluster right now, but there will be one in the future):
java.lang.ClassNotFoundException: com.mdx.sb2.SB2BeanHomeImpl_WLStub:
This error could indicate that a component was deployed on a cluster member
but not other members of that cluster. Make sure that any component deployed on
a server that is part of a cluster is also deployed on all other members of that
cluster
java.lang.ClassNotFoundException: com.mdx.sb2.SB2BeanHomeImpl_WLStub: This error
could indicate that a component was deployed on a cluster member but not othe
r members of that cluster. Make sure that any component deployed on a server that
is part of a cluster is also deployed on all other members of that cluster
at weblogic.j2ee.ApplicationManager.loadClass(ApplicationManager.java:143)
at weblogic.rjvm.ClassTableEntry.getDescriptor(ClassTableEntry.java:37)
at weblogic.rjvm.InboundMsgAbbrev.getDescriptor(InboundMsgAbbrev.java:132)
at weblogic.rjvm.MsgAbbrevInputStream.readClassDescriptor(MsgAbbrevInputStream.java:171)
at weblogic.common.internal.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:90)
at weblogic.common.internal.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:114)
at weblogic.rmi.internal.ObjectIO.readObject(ObjectIO.java:47)
at weblogic.rmi.internal.BasicRemoteRef.unmarshalReturn(BasicRemoteRef.java:136)
at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:251)
at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:225)
at weblogic.jndi.internal.ServerNamingNode_WLStub.lookup(ServerNamingNode_WLStub.java:121)
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:323)
at javax.naming.InitialContext.lookup(InitialContext.java:350)
at com.mdx.sb1.SB1Bean.lookupHome(SB1Bean.java:74)
at com.mdx.sb1.SB1Bean.test(SB1Bean.java:49)
at com.mdx.sb1.SB1BeanImpl.test(SB1BeanImpl.java:110)
at com.mdx.sb1.SB1BeanEOImpl.test(SB1BeanEOImpl.java:30)
at com.mdx.sb1.SB1BeanEOImpl_WLSkel.invoke(SB1BeanEOImpl_WLSkel.java:64)
at weblogic.rmi.internal.BasicServerAdapter.invoke(BasicServerAdapter.java:373)
at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:128)
at weblogic.rmi.internal.BasicServerAdapter.invoke(BasicServerAdapter.java:237)
at weblogic.rmi.internal.BasicRequestHandler.handleRequest(BasicRequestHandler.java:118)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:17)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
I fixed this by putting the stubs in the ejb-jar file (yuk) and redeploying. I
really don't think the stubs should need to be in the jar file for the ejb (just
the home and remote classes). They aren't needed on the classpath for other clients
of the system.
the questions I have are,
Why are the classes needed for this type of client and not others?
Is there a way around this?
If there is no way around this, how can I get the proper classes into the ejbc
compiled jar file without manually stating all the stubs that are specifically
needed?
How will the clustering portions of this work when we deploy the containers into
clusters?
thanks for your help,
-chris
Dimitri Rakitine
reasons. You can enable in back like this:
in 6.x in the config.xml :
<Server
...
NetworkClassLoadingEnabled="true"
>
and in 5.1
weblogic.system.enableUnsafeClassloading=true
and 6.1 does not generate stubs anymore, so it's not an issue ;-)
Chris Humphrey <chris.h...@mdx.com> wrote:
> Hi all,
--
Dimitri