SOAP (EJBs) clustering (WLS 7.0)

Hi all,
I had posted this before, too. But I did not get any working feedback. Has anyone
ever tried clustering SOAP impls (EJB) in WLS? Does WLS support this?
I am able to deploy simple EJBs across clustered WLS instances.
I am unsuccessful in doing the same for a web service (SOAP) using EJBs. The application
gets deployed but successive requests do not round robin among available services.
I think somehow I need to do some cluster tweaks to the receiving WLS servlet
that peeks into the SOAP message and forwards it to the right service.
Could someone please help me out?
I would be most grateful.
Thanks a lot. Guha

A traditional EJB stub (which communicates over T3 or IIOP) has
intelligence built in to it to perform round robin load balancing. The
same tricks don't apply for SOAP/HTTP. If you want to get that
behavior, then you need to do the same thing used for load balancing
servlet requests: all members of the cluster should resolve to the same
DNS name, and use DNS round robining to distribute the load. Or use a
load balancer like Resonate. For more information, see:
http://e-docs.bea.com/wls/docs70/cluster/index.html.
-Don
Suteertha wrote:
Hi all,
I had posted this before, too. But I did not get any working feedback. Has anyone
ever tried clustering SOAP impls (EJB) in WLS? Does WLS support this?
I am able to deploy simple EJBs across clustered WLS instances.
I am unsuccessful in doing the same for a web service (SOAP) using EJBs. The application
gets deployed but successive requests do not round robin among available services.
I think somehow I need to do some cluster tweaks to the receiving WLS servlet
that peeks into the SOAP message and forwards it to the right service.
Could someone please help me out?
I would be most grateful.
Thanks a lot. Guha

Similar Messages

Urgent help requested : How to cluster SOAP (via EJB) in WLS 7.0 SP 01?

Hi all,
I am able to deploy simple EJBs across clustered WLS instances.
I am unsuccessful in doing the same for a web service (SOAP) using EJBs. The application
gets deployed but successive requests do not round robin among available services.
I think somehow I need to do some cluster tweaks to the receiving WLS servlet
that peeks into the SOAP message and forwards it to the right service.
Could someone please help me out?
I would be most grateful.
Thanks a lot.
Guha

          A couple of entries in webservices.xml file and making the proxy from the web server
          reach out to the cluster instead of trying to make the https client do so.

Getting Tomcat 4.1 to call EJBs in WLS 8.1

I know this is not necessarily a new topic, but we're upgrading our Tomcat
4.1 -> WLS 5.1 to a Tomcat 4.1 -> WLS 8.1 configuration.
Firstly, has ANYONE got Tomcat 4.1.x to work with a post 5.1 container at
all? Ever?
We are using the T3 protocol to talk to our beans, and the goal, of course,
is that our Tomcat based client code will ideally not have to change.
Our beans are all EJB 1.1, and I have them loaded into a running WLS 8.1
container. They appear to work.
The way I tested to see if I could talk to WLS was by using a simple client
that I had that gets an InitialContext, and then grabs a bean.
I now have a simple JSP that essentially does the same thing. I've bundled
this jsp into a properly formatted WAR file.
Within this WAR file in the WEB-INF/classes directory are the Session bean
Home and the Session Bean Remote interface classes.
Within the WEB-INF/lib directory is the
c:\bea\weblogic81\server\lib\weblogic.jar, slightly modified.
After the first attempt to load this, Tomcat would complain because the
weblogic.jar contains the javax.servlet package, so I exploded the
weblogic.jar file, renamed javax/servlet to javax/servlet.x, and then
rejarred the file. This file was placed into the WEB-INF/lib directory.
This is otherwise a default Tomcat 4.1.18 binary package.
Here's the WAR file contents:
./META-INF/MANIFEST.MF
./WEB-INF/classes/com/pfizer/ecms/as/CustomizationSession.class
./WEB-INF/classes/com/pfizer/ecms/as/CustomizationSessionHome.class
./WEB-INF/lib/wlsx.jar <-- Edited weblogic.jar
./WEB-INF/web.xml
./test.jsp
This is the contents of the test.jsp:
<%@ page language="java" %>
<%@ page import="javax.naming.*" %>
<%@ page import="com.pfizer.ecms.as.*" %>
<%
try{
System.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
System.setProperty(Context.PROVIDER_URL, "t3://localhost:7001");
InitialContext ctx = new InitialContext();
CustomizationSessionHome csth = (CustomizationSessionHome)
ctx.lookup("CustomizationSession");
CustomizationSession cst = csth.create();
catch (Throwable t) {
System.out.println(">>>t = " + t);
t.printStackTrace(System.out);
%>
<HTML>
<BODY>
This is the jsp.
</BODY>
</HTML>
Similar code to this has been working for us for 3 years so far.
When I try and load the JSP, it dumps a stack trace. Here's the relevant
bits up to the Tomcat container:
t = java.lang.NoClassDefFoundError: weblogic/rmi/extensions/server/Stubjava.lang.NoClassDefFoundError: weblogic/rmi/extensions/server/Stub
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at
weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLo
ader.java:431)
at
weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.
java:169)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:217)
at
weblogic.utils.classfile.utils.CodeGenerator.generateClass(CodeGenerator.jav
a:71)
at weblogic.rmi.internal.StubGenerator.getStubClass(StubGenerator.java:672)
at weblogic.rmi.internal.StubGenerator.generateStub(StubGenerator.java:712)
at weblogic.rmi.internal.StubGenerator.generateStub(StubGenerator.java:699)
at weblogic.rmi.extensions.StubFactory.getStub(StubFactory.java:76)
at
weblogic.jndi.WLInitialContextFactoryDelegate.newRootNamingNodeStub(WLInitia
lContextFactoryDelegate.java:486)
at
weblogic.jndi.WLInitialContextFactoryDelegate.newRemoteContext(WLInitialCont
extFactoryDelegate.java:449)
at
weblogic.jndi.WLInitialContextFactoryDelegate.newContext(WLInitialContextFac
toryDelegate.java:345)
at
weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialCon
textFactoryDelegate.java:308)
at
weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialCon
textFactoryDelegate.java:234)
at
weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFact
ory.java:135)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:243)
at javax.naming.InitialContext.init(InitialContext.java:219)
at javax.naming.InitialContext.<init>(InitialContext.java:175)
at org.apache.jsp.test_jsp._jspService(test_jsp.java:51)
What is interesting about this is that the system could "see"
weblogic.utils.classloaders.GenericClassLoader, but THAT class could not
find weblogic.rmi.extension.server.Stub, even though they are, ideally, at
the same level within the Tomcat imposed hierarchy of classloaders.
Unfortunately, we don't quite know where in that hierarchy each class is
placed.
Now, the culprit may well be java.security.SecureClassLoader (or, actually,
the java.lang.ClassLoader.defineClass0), which is very high up in the
hierarchy trying to load a the result of the StubGenerator, only to find
that an associated class, weblogic.rmi.extensions.server.Stub, was "not
found" because it only existed deep in the Tomcat hierarchy.
One way that I tried to get around this was to start taking selective bits
of of weblogic.jar and put them on the system CLASSPATH used by Tomcat when
it starts up.
This gets us farther along, in that more classes seem to load without
getting the ClassDefNotFound error, but it finally leads us into this
exception:
The error is, with a small bit of stack dump:
weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Environment not
found on thread ]
at
weblogic.jndi.internal.NamingNodeReplicaHandler.<init>(NamingNodeReplicaHand
ler.java:150)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcces
sorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstruc
torAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at java.lang.Class.newInstance0(Class.java:306)
at java.lang.Class.newInstance(Class.java:259)
at
weblogic.common.internal.ChunkedObjectInputStream.readObject(ChunkedObjectIn
putStream.java:90)
snip
The relevant starting point is toward the middle of the stack trace:
at
weblogic.rjvm.BasicOutboundRequest.sendReceive(BasicOutboundRequest.java:106
at weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:125)
at
com.pfizer.ecms.as.DataImporterSession_aiw0oz_HomeImpl_810_WLStub.create(Unk
nown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.pfizer.ecms.com.AppServer.createInstance(AppServer.java:163)
at com.pfizer.ecms.com.AppServer.getDataImporterSession(AppServer.java:231)
at
com.pfizer.ecms.ws.ECMSActionServlet.testBeans(ECMSActionServlet.java:1662)
at
com.pfizer.ecms.ws.ECMSActionServlet.initOther(ECMSActionServlet.java:62)
at org.apache.struts.action.ActionServlet.init(ActionServlet.java:472)
Now, according to the Weblogic documentation, the AssertionError exception
"is impossible". Well, that's my job they say, doing the impossible.
Minimally, it's a meaningless message to me and pretty much stops me cold.
I have seen other discussions about Tomcat and how it's not J2EE, etc, and
perhaps my expectations that this will work are too high. My concern with
that is simply that in our case, Tomcat is a Fat Client no different from
"any other Java application". We just use Tomcat to talk to beans rather
than a custom client. The difficulty, it seems, is in the complexities of
the Tomcat class loaders interoperating with the expectations of Weblogics
classes et al.
I've got a small application that does exactly what Tomcat wants to do, so
"weblogic works", except of course, in Tomcat.
So, in the end, I'm curious if others have some data on getting these two
system cooperating. If anyone has any other ideas on how to use Tomcat as a
client of Weblogic 8 that utilizes techniques besides replacing Tomcat
(which is not an option at the moment) I'd like to hear those as well. I
have been fighting this for days, and tried several things, but nothing
"obvious" seems to help.
Weblogic 8 has a "thin client" jar, but it's only useful for RMI rather than
T3, plus it's still not clear how we'd go about rewriting the interfaces to
support that versus the standard EJB interfaces already created for the
beans.
Any assistance greatly appreciated.
Regards,
Will Hartung
([email protected])

Of course I feel obliged to first recommend that you run your webapps
and EJBs in WLS. There's significant performance advantages and it
greatly simpifies your life since you don't have to deal with another
remote failure case.
That being said, I believe it should be possible especially with 8.1 to
make Tomcat a WLS client.
Answers inline.
Will Hartung wrote:
I know this is not necessarily a new topic, but we're upgrading our Tomcat
4.1 -> WLS 5.1 to a Tomcat 4.1 -> WLS 8.1 configuration.
Firstly, has ANYONE got Tomcat 4.1.x to work with a post 5.1 container at
all? Ever?
We are using the T3 protocol to talk to our beans, and the goal, of course,
is that our Tomcat based client code will ideally not have to change.
Our beans are all EJB 1.1, and I have them loaded into a running WLS 8.1
container. They appear to work.
The way I tested to see if I could talk to WLS was by using a simple client
that I had that gets an InitialContext, and then grabs a bean.
I now have a simple JSP that essentially does the same thing. I've bundled
this jsp into a properly formatted WAR file.
Within this WAR file in the WEB-INF/classes directory are the Session bean
Home and the Session Bean Remote interface classes.
Within the WEB-INF/lib directory is the
c:\bea\weblogic81\server\lib\weblogic.jar, slightly modified.My suggestion is to ditch the weblogic.jar and the joys of trying to
modify it. I'd instead check out 8.1's thin client support:
http://e-docs.bea.com/wls/docs81/rmi_iiop/rmiiiop2.html#1071450
>
After the first attempt to load this, Tomcat would complain because the
weblogic.jar contains the javax.servlet package, so I exploded the
weblogic.jar file, renamed javax/servlet to javax/servlet.x, and then
rejarred the file. This file was placed into the WEB-INF/lib directory.
This is otherwise a default Tomcat 4.1.18 binary package.
Here's the WAR file contents:
./META-INF/MANIFEST.MF
./WEB-INF/classes/com/pfizer/ecms/as/CustomizationSession.class
./WEB-INF/classes/com/pfizer/ecms/as/CustomizationSessionHome.class
./WEB-INF/lib/wlsx.jar <-- Edited weblogic.jar
./WEB-INF/web.xml
./test.jsp
This is the contents of the test.jsp:
<%@ page language="java" %>
<%@ page import="javax.naming.*" %>
<%@ page import="com.pfizer.ecms.as.*" %>
<%
try{
System.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
System.setProperty(Context.PROVIDER_URL, "t3://localhost:7001");
InitialContext ctx = new InitialContext();
CustomizationSessionHome csth = (CustomizationSessionHome)
ctx.lookup("CustomizationSession");
CustomizationSession cst = csth.create();
catch (Throwable t) {
System.out.println(">>>t = " + t);
t.printStackTrace(System.out);
%>
<HTML>
<BODY>
This is the jsp.
</BODY>
</HTML>
Similar code to this has been working for us for 3 years so far.
When I try and load the JSP, it dumps a stack trace. Here's the relevant
bits up to the Tomcat container:
t = java.lang.NoClassDefFoundError: weblogic/rmi/extensions/server/Stubjava.lang.NoClassDefFoundError: weblogic/rmi/extensions/server/Stub
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at
weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLo
ader.java:431)
at
weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.
java:169)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:217)
at
weblogic.utils.classfile.utils.CodeGenerator.generateClass(CodeGenerator.jav
a:71)
at weblogic.rmi.internal.StubGenerator.getStubClass(StubGenerator.java:672)
at weblogic.rmi.internal.StubGenerator.generateStub(StubGenerator.java:712)
at weblogic.rmi.internal.StubGenerator.generateStub(StubGenerator.java:699)
at weblogic.rmi.extensions.StubFactory.getStub(StubFactory.java:76)
at
weblogic.jndi.WLInitialContextFactoryDelegate.newRootNamingNodeStub(WLInitia
lContextFactoryDelegate.java:486)
at
weblogic.jndi.WLInitialContextFactoryDelegate.newRemoteContext(WLInitialCont
extFactoryDelegate.java:449)
at
weblogic.jndi.WLInitialContextFactoryDelegate.newContext(WLInitialContextFac
toryDelegate.java:345)
at
weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialCon
textFactoryDelegate.java:308)
at
weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialCon
textFactoryDelegate.java:234)
at
weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFact
ory.java:135)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:243)
at javax.naming.InitialContext.init(InitialContext.java:219)
at javax.naming.InitialContext.<init>(InitialContext.java:175)
at org.apache.jsp.test_jsp._jspService(test_jsp.java:51)
What is interesting about this is that the system could "see"
weblogic.utils.classloaders.GenericClassLoader, but THAT class could not
find weblogic.rmi.extension.server.Stub, even though they are, ideally, at
the same level within the Tomcat imposed hierarchy of classloaders.
Unfortunately, we don't quite know where in that hierarchy each class is
placed.
Now, the culprit may well be java.security.SecureClassLoader (or, actually,
the java.lang.ClassLoader.defineClass0), which is very high up in the
hierarchy trying to load a the result of the StubGenerator, only to find
that an associated class, weblogic.rmi.extensions.server.Stub, was "not
found" because it only existed deep in the Tomcat hierarchy.
One way that I tried to get around this was to start taking selective bits
of of weblogic.jar and put them on the system CLASSPATH used by Tomcat when
it starts up.
This gets us farther along, in that more classes seem to load without
getting the ClassDefNotFound error, but it finally leads us into this
exception:
The error is, with a small bit of stack dump:
weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Environment not
found on thread ]
at
weblogic.jndi.internal.NamingNodeReplicaHandler.<init>(NamingNodeReplicaHand
ler.java:150)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcces
sorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstruc
torAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at java.lang.Class.newInstance0(Class.java:306)
at java.lang.Class.newInstance(Class.java:259)
at
weblogic.common.internal.ChunkedObjectInputStream.readObject(ChunkedObjectIn
putStream.java:90)
snip
The relevant starting point is toward the middle of the stack trace:
at
weblogic.rjvm.BasicOutboundRequest.sendReceive(BasicOutboundRequest.java:106
at weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:125)
at
com.pfizer.ecms.as.DataImporterSession_aiw0oz_HomeImpl_810_WLStub.create(Unk
nown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.pfizer.ecms.com.AppServer.createInstance(AppServer.java:163)
at com.pfizer.ecms.com.AppServer.getDataImporterSession(AppServer.java:231)
at
com.pfizer.ecms.ws.ECMSActionServlet.testBeans(ECMSActionServlet.java:1662)
at
com.pfizer.ecms.ws.ECMSActionServlet.initOther(ECMSActionServlet.java:62)
at org.apache.struts.action.ActionServlet.init(ActionServlet.java:472)
Now, according to the Weblogic documentation, the AssertionError exception
"is impossible". Well, that's my job they say, doing the impossible.
Minimally, it's a meaningless message to me and pretty much stops me cold.
Right, it's not really meant to be meaningful because customers "should"
never see these assertions.
I have seen other discussions about Tomcat and how it's not J2EE, etc, and
perhaps my expectations that this will work are too high. My concern with
that is simply that in our case, Tomcat is a Fat Client no different from
"any other Java application". We just use Tomcat to talk to beans rather
than a custom client. The difficulty, it seems, is in the complexities of
the Tomcat class loaders interoperating with the expectations of Weblogics
classes et al.
I've got a small application that does exactly what Tomcat wants to do, so
"weblogic works", except of course, in Tomcat.
So, in the end, I'm curious if others have some data on getting these two
system cooperating. If anyone has any other ideas on how to use Tomcat as a
client of Weblogic 8 that utilizes techniques besides replacing Tomcat
(which is not an option at the moment) I'd like to hear those as well. I
have been fighting this for days, and tried several things, but nothing
"obvious" seems to help.
Weblogic 8 has a "thin client" jar, but it's only useful for RMI rather than
T3, plus it's still not clear how we'd go about rewriting the interfaces to
support that versus the standard EJB interfaces already created for the
beans.I'm not sure I follow you here. You always write to RMI interfaces.
The question is what protocol (eg T3, JRMP, IIOP) will actually run RMI.
By default WLS uses its own protocol (t3), but most customer apps
should run without change over IIOP.
I'd really recommend going the thin client route. Otherwise I fear
you'll end up with a heavily modified weblogic.jar and headaches when
you try to install a service pack etc.
-- Rob
>
Any assistance greatly appreciated.
Regards,
Will Hartung
([email protected])

EJB in WLS - CORBA and EJB on WLE

I have a client who is looking to attach a C++ client to their WLE
system, and, since
they now have WLS and WLE thanks to v. 5.1, they want to start moving
EJBs to the
WLS platform. The issue is this.
What if any are the issues regarding communicating between CORBA objects
on WLE
TO EJBs on WLS? I noticed that the illustrations always show the
communication coming
from the WLS side to the WLE side, but this client will be connected
directly to the WLE
platform, and wanting to access services on WLS.
Any issues, directions to documentation, or other advice regarding this
issue?
Thanks in advance,
Maffy
[maffy.vcf]

can anyone give code example for accessing WLS-EJB from WLE corba client.
louc wrote:
Interesting how things can be interpreted. What we need is direct input
from engineering on this.
In studying the only direct source of information we have... (the docs...
and ass-u-me'ing that the docs are correct) it appears that we can have a
CORBA object in WLE access a EJB in WLS through RMI/IIOP as long as the
parameter passing is kept to primitive data types. Any attempt to use the
'Object-by-Value' feature of CORBA 2.3 will result in a error because WLE
5.1 does not support passing 'Object-by-Value' at this time.
So to answer Maffy's question... yes a WLE CORBA client can access a WLS EJB
service through RMI over IIOP.
-- Lou Caraballo
Sr. Systems Engineer
BEA Systems Inc., Denver Telco Group
719-332-0818 (cell)
720-528-6073 (denver)
Robert Patrick <[email protected]> wrote in message
news:[email protected]...
The issue is that WLE does not yet support the RMI/IIOP standard (since itdoes not yet support
Objects by Value) not that the RMI/IIOP support in WLS 5.1 (as of SP3)does not support
bi-directional communication.
Papaya Head wrote:
so, you are saying bi-directional communication is not supported... can
you tell me what
rmi/iiop is for?
Thanks.
Maffy Finnerty wrote:
Okay, found a work around thanks to Deepak Sharma (THANK YOU,
DEEPAK!!) in the BEA
East office.
What my customer is going to have to do for now - until, as Will Lyonspointed out, the
bi-directional
communication is supported - is to build a Java "client" process onWLE that communicates
with the
RMI/EJB/Servlet process on WLS.
Deepak suggested that the best way, since they are a CORBA shop tryingto move to Java,
would be to have the C++ client talking to a CORBA/C++ object on WLEthat calls
a CORBA/Java object on WLE that acts as a client to WLS and accessesthe services of the
Java object on that server.
Another option would be to have the CORBA/C++ object on WLE use theJNI API to call a Java
object
on WLE that acts as a client to WLS and accesses the Java servicerunning there. There may
be better
performance from CORBA/C++ to CORBA/Java, though, so that was Deepak'sfirst choice.
Maffy
Papaya Head wrote:
you can also find an example in the WLS5.1 docs that includes a code
segment from C++
client of the RMI-IIOP hello example.
Will Lyons wrote:
The example application with C++ CORBA objects calling EJBs on a
Java Server refers
to C++ CORBA objects on the WLE T-Engine calling EJBs on the WLET-Engine. That
interoperability capability is supported, but it is not possibleto call the J-Engine
from the T-Engine in WLE 5.1. The primary usage model assumed inWLE 5.1 is calling
the WLE T-Engine from the J-Engine (or from WLS).
Will
Papaya Head wrote:
my understanding of your question is: you want some feature that
allows CORBA
objects to talk to EJB objects on WLS.
WLS5.1 has a new feature: RMI/IIOP, it's probably the featureyou want.
before WLS5.1, CORBA components couldn't talk to EJB componentsdirectly, but you
could make it happen by building a bridge from CORBA objects toEJB components on
WLS. that's probably what the references you read are talkingabout...
Maffy Finnerty wrote:
We haven't even gotten that far yet, re: transactions. Right
now the issue is
having an
in-house client (C++) connected to WLE but accessing services(EJBs) on WLS.
No talk
of transactions has occurred, yet.
However, I just found some conflicting information. I found areference to
building the
simpapp application to connect C++ objects on a CORBA serverto EJBs on a Java
Server,
which, if I'm reading it correctly, translates to WLE to WLS.However, I also
found a
reference to bidirectional interoperability that said that,for now, the
T-Engine could not
(WLE) could NOT invoke services on the J-Engine (WLS) but thatservices on the
T-Engine
(WLE) could BE invoked from requesters on the J-Engine (WLS).So, color me
confused.
maffy
Papaya Head wrote:
the first question that comes to my mind is:
can transaction run across components on WLE and components
on WLS? I don't
think it can...
Maffy Finnerty wrote:
I have a client who is looking to attach a C++ client to
their WLE
system, and, since
they now have WLS and WLE thanks to v. 5.1, they want tostart moving
EJBs to the
WLS platform. The issue is this.
What if any are the issues regarding communicating betweenCORBA objects
on WLE
TO EJBs on WLS? I noticed that the illustrations alwaysshow the
communication coming
from the WLS side to the WLE side, but this client will beconnected
directly to the WLE
platform, and wanting to access services on WLS.
Any issues, directions to documentation, or other adviceregarding this
issue?
Thanks in advance,
Maffy

Looking up JMS destinations with clustered WLS

          From scanning the postings, it appears that in a clustered WLS environment, the
          JMS servers are not clustered. As a result, the JMS destinations must be unique
          across all of the WLS in the cluster. In addition, there is no failover available
          when a JMS server goes down.
          With that stated, what I want to know is:
          When establishing a JMS connection with a JMS server in a WLS cluster, do I need
          to know the JNDI URL for each specific JMS server that is managing the destination(s)
          I wish to pub/sub?
          Or, is there a 'global' JNDI tree that I can reference and the clustered WLS behind
          the scenes will route me to the appropriate JMS server?
          If resolving the URL is a manual process, I will need to keep track of which destinations
          reside on which JMS servers. This adds an additional maintenance point that I
          would like to avoid if possible.
          Thanks,
          Bob.


One can use Connection Factory to establish connection to particular
          destination (queue/topic). connection factories are clustered. so, one don't
          need to have knowledge of particular WLS.
          "Neal Yin" <[email protected]> wrote in message
          news:[email protected]...
          > Although there is only one JMS server instance, you can lookup it from
          > anywhere in a cluster.
          > In another words, JNDI tree is global in a WLS cluster. Just give cluster
          > DNS name in your
          > URL, you will be fine.
          >
          > -Neal
          >
          >
          > "Bob Peroutka" <[email protected]> wrote in message
          > news:[email protected]...
          > >
          > > From scanning the postings, it appears that in a clustered WLS
          > environment, the
          > > JMS servers are not clustered. As a result, the JMS destinations must
          be
          > unique
          > > across all of the WLS in the cluster. In addition, there is no failover
          > available
          > > when a JMS server goes down.
          > >
          > > With that stated, what I want to know is:
          > >
          > > When establishing a JMS connection with a JMS server in a WLS cluster,
          do
          > I need
          > > to know the JNDI URL for each specific JMS server that is managing the
          > destination(s)
          > > I wish to pub/sub?
          > >
          > > Or, is there a 'global' JNDI tree that I can reference and the clustered
          > WLS behind
          > > the scenes will route me to the appropriate JMS server?
          > >
          > > If resolving the URL is a manual process, I will need to keep track of
          > which destinations
          > > reside on which JMS servers. This adds an additional maintenance point
          > that I
          > > would like to avoid if possible.
          > >
          > > Thanks,
          > >
          > > Bob.
          > >
          > >
          > >
          >
          >

Trying to build a web application with stateful ejb clustering

Hi to everyone,
I'd like to know if someone gets to work a stateful ejb clustering. The stateful ejbs are called from a servlet so i'm not using RMI.
The ejb clustering sample works! but It is using RMI and this is not use for me.
My application already works but not in a cluster. Is this possible? I supose yes AND HOW???
Thanks in advanced.

Might look at: https://jsfportletbridge.dev.java.net to get started.

Clustering WLS 6.1

          Hi All,
          I'm trying to clustering WLS 6.1. I have 2 Web servers, 2 Application servers,
          and 1 Admin servers. One of the web server is in the same machine with the admin
          server. And the other servers are in separate machine.
          I want to make 2 clusters, one is the cluster for the web server, and the other
          is for the app server.
          I already set the clustering in the admin server. What I would like to know, do
          I need to set the clustering configuration in each server??
          Thanx in advanced.
          Regards,
          Mellfiena.S


Mellfiena.S wrote:
          > Hi All,
          >
          > I'm trying to clustering WLS 6.1. I have 2 Web servers, 2 Application servers,
          > and 1 Admin servers. One of the web server is in the same machine with the admin
          > server. And the other servers are in separate machine.
          > I want to make 2 clusters, one is the cluster for the web server, and the other
          > is for the app server.
          > I already set the clustering in the admin server. What I would like to know, do
          > I need to set the clustering configuration in each server??
          >
          > Thanx in advanced.
          >
          > Regards,
          >
          > Mellfiena.S
          I am not sure what you mean by I already set the clustering in the admin
          server.
          1. You have to create two clusters.
          2. Then you make each web server part of cluster 1 and each application
          server part of cluster 2.
          Hope this makes sense.
          Cheers,
          -- Prasad

SOAP / Web Service clustering WLS 7.0.2

          Hi there,
          I'm looking for information on if and how WLS 7.0.2 is capable of
          clustering Web Services. We created the Web Service like following:
          - Created a stateless session bean first
          - Created the web service with a servicegen ant task
          I browsed through edocs.bea.com but
          up to now with no success.
          Any help is greatly appreciated.
          Best regards,
          Fabio


          "Fabio Barone" <[email protected]> wrote:
          >
          >Hi there,
          >
          >I'm looking for information on if and how WLS 7.0.2 is capable of
          >clustering Web Services. We created the Web Service like following:
          >- Created a stateless session bean first
          >- Created the web service with a servicegen ant task
          >
          >We need the clustering service for high availability, not
          >for load balancing or session fail-over.
          >
          >Our IT dept. offered a hardware solution with CISCO load-balancers
          >first (our preferred solution for high availability).
          >However, the guys here are not able to configure the hardware properly,
          >that's why we're looking for alternatives with the WLS cluster.
          >
          >I browsed through edocs.bea.com but
          >up to now with no success.
          >
          >Any help is greatly appreciated.
          >
          >Best regards,
          >Fabio
          Fabio, your other alternative is through a group of Web servers configured identically
          using Weblogic proxy plugins. WLS can also act as a load-balancing proxy to interface
          with a Cluster. Search bea docs for Load-balancing Proxy.....
          Good Luck

Apache-soap Problem with WLS 5.1sp9

I have problem with WLS 5.1sp9.
My environment is the following :
jaf-1.0.1
javamail-1.2
soap-2.2
xerces-1.4.4
and I want to call EJB.
So, I write some EJB and deploy it.
And rpcrouter work!!
Success to deploy the Service.
But I run into problem with calling this ejb.
This error is the following.
SOAP-ENV:Server.BadTargetObjectURI
Unable to resolve target object: BC2_BoardSync
please, help me.
here's my example..
ps.
sorry for my poor English..T_T
[ws5.10.zip]
[vb.zip]

I have problem with WLS 5.1sp9.
My environment is the following :
jaf-1.0.1
javamail-1.2
soap-2.2
xerces-1.4.4
and I want to call EJB.
So, I write some EJB and deploy it.
And rpcrouter work!!
Success to deploy the Service.
But I run into problem with calling this ejb.
This error is the following.
SOAP-ENV:Server.BadTargetObjectURI
Unable to resolve target object: BC2_BoardSync
please, help me.
here's my example..
ps.
sorry for my poor English..T_T
[ws5.10.zip]
[vb.zip]

Testing EJB using WLS admin console

Hi,
After having deployed the EJB, we looked at the JNDI tree it looks fine. But when
we try to test the EJB using Testing tab of the weblogic admin console we get
the following message
"The EJB IOESTARIDAdmin has not been tested succesfully. "
When this EJB was deployed we got confirmation from WLS that the EJB got deployed
successfully. Can anyone tell us what is the problem?
Regards,

Hi Anand
what version of the server were you using? If this is not working it could
be a bug. I can try and file an issue let me know the version please.
sree
"Anand Jayaraman" <[email protected]> wrote in message
news:40bc4052$1@mktnews1...
>
Hi,
I found the problem. When Clustering is enabled on Weblogic Server, we getthis
problem. In a non clustered environment it works. May be because in aclustered
environment JNDI lookup varies a bit.
Regards,
Anand Jayaraman
"Anand" <[email protected]> wrote:
Hi,
After having deployed the EJB, we looked at the JNDI tree it looks fine.
But when
we try to test the EJB using Testing tab of the weblogic admin console
we get
the following message
"The EJB IOESTARIDAdmin has not been tested succesfully. "
When this EJB was deployed we got confirmation from WLS that the EJB
got deployed
successfully. Can anyone tell us what is the problem?
Regards,

Unable to deploy a cmp 2.0 ejb to wls 8.1

windows Xp professional
IBM DB2
JBuilder 9.0
i build a ejb jar with jb9.0 wizard, then deploy it to wls.
but ...
D:\servers\bea\jdk141_03\bin\javaw -classpath
D:\servers\bea\weblogic81\server\lib\weblogic_sp.jar;D:\servers\bea\weblogic81\server\lib\weblogic.jar;D:\servers\bea\weblogic81\server\lib\webservices.jar;
weblogic.Deployer -user jerez -adminurl http://kame_house:7001
-password kinchin4587 -activate -name water -upload -source
D:/workspace/jbproject/water/water.jar -targets jerez
Initiated Task: [4] [Deployer:149026]Deploy application water on jerez.
Task 4 failed: [Deployer:149026]Deploy application water on jerez.
Deployment failed on Server jerez
weblogic.management.DeploymentException:
Exception:weblogic.management.ApplicationException: activate failed for
water
     Module: water     Error: Exception activating module:
EJBModule(water,status=PREPARED)
Unable to deploy EJB: Angle from water.jar:
java.lang.AbstractMethodError:
weblogic.jdbc.wrapper.DatabaseMetaData_COM_ibm_db2_jdbc_app_DB2DatabaseMetaData.supportsBatchUpdates()Z
     at
weblogic.ejb20.cmp.rdbms.RDBMSPersistenceManager.verifyBatchUpdatesSupported(RDBMSPersistenceManager.java:2081)
     at
weblogic.ejb20.cmp.rdbms.RDBMSPersistenceManager.setup(RDBMSPersistenceManager.java:200)
     at
weblogic.ejb20.manager.BaseEntityManager.setupPM(BaseEntityManager.java:217)
     at
weblogic.ejb20.manager.BaseEntityManager.setup(BaseEntityManager.java:184)
     at weblogic.ejb20.manager.DBManager.setup(DBManager.java:164)
     at
weblogic.ejb20.deployer.ClientDrivenBeanInfoImpl.activate(ClientDrivenBeanInfoImpl.java:1004)
     at weblogic.ejb20.deployer.EJBDeployer.activate(EJBDeployer.java:1322)
     at weblogic.ejb20.deployer.EJBModule.activate(EJBModule.java:610)
     at
weblogic.j2ee.J2EEApplicationContainer.activateModule(J2EEApplicationContainer.java:3012)
     at
weblogic.j2ee.J2EEApplicationContainer.activate(J2EEApplicationContainer.java:2076)
     at
weblogic.j2ee.J2EEApplicationContainer.activate(J2EEApplicationContainer.java:2057)
     at
weblogic.management.deploy.slave.SlaveDeployer$ComponentActivateTask.activateContainer(SlaveDeployer.java:2624)
     at
weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.doCommit(SlaveDeployer.java:2547)
     at
weblogic.management.deploy.slave.SlaveDeployer$Task.commit(SlaveDeployer.java:2349)
     at
weblogic.management.deploy.slave.SlaveDeployer$Task.checkAutoCommit(SlaveDeployer.java:2431)
     at
weblogic.management.deploy.slave.SlaveDeployer$Task.prepare(SlaveDeployer.java:2343)
     at
weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.prepare(SlaveDeployer.java:2511)
     at
weblogic.management.deploy.slave.SlaveDeployer.processPrepareTask(SlaveDeployer.java:833)
     at
weblogic.management.deploy.slave.SlaveDeployer.prepareDelta(SlaveDeployer.java:542)
     at
weblogic.management.deploy.slave.SlaveDeployer.prepareUpdate(SlaveDeployer.java:500)
     at
weblogic.drs.internal.SlaveCallbackHandler$1.execute(SlaveCallbackHandler.java:25)
     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)

Hi,
How did you uninstall the graphics drvier? From Devices manager or Programs and Features?
Please open Control Panel\All Control Panel Items\Programs and Features
And then, search for "NVIDIA Graphics Driver" and then select the "Change/Remove" button to begin the uninstall process.
Next, once the uninstall has completed, reboot Windows so that the other NVIDIA components can be removed as well.
If the issue still persists, since this driver that you recently installed caused problems with your PC, you can restore Windows back to an earlier point in time.
http://windows.microsoft.com/en-us/windows-8/restore-refresh-reset-pc
Regards,
Kelvin Xu
TechNet Community Support

Error in accessing Processes in a Clustered WLS Environment

Hi all,
We are running a clustered deployment of OBPM in WLS. The cluster is behaving properly execpt published and deployed projects are displaying the following error when accessing the workspace:
The Process '/FooRequestProcess#Default-1.0' is not available.
The Process '/FooCenterRequestProcess#Default-1.0' is not available. Caused by: Process '/FooRequestProcess#Default-1.0' not available. Caused by: Cannot reach engine 'bpmQAengine' at URL: ''. Caused by: While trying to lookup 'engines.bpmQAengine' didn't find subcontext 'engines'. Resolved ''
Now, there was an issue with the JDBC Data Source in WLS which has since been fixed otherwise neither the engine or workspace would have come up. I have rebuilt and redeployed the engine, and I have undeployed and unplished the project then republished and redeployed it yet I still see this error.
The XA definitions are correct. Does anyone have a clue as to the cause of this?
TIA,
IGS

Hi,
Am getting the same error
The Process '/ExpenseReport#Default-1.0' is not available.
The Process '/ExpenseReport#Default-1.0' is not available. Caused by: Process '/ExpenseReport#Default-1.0' not available. Caused by: Cannot reach engine 'Engine3' at URL: ''. Caused by: While trying to lookup 'engines.Engine3' didn't find subcontext 'engines'. Resolved ''
When i tried checking --reload from directory am getting the following error
Error Caused by: JMX connection for J2EE_WEBLOGIC could not be established. URL: service:jmx:t3://cdi-server1.apac.apl.com:8101/jndi/weblogic.management.mbeanservers.runtime. Caused by: User: weblogic, failed to be authenticated.
Am not sure of this error... Please advice how to recitfy.. I have given the host and port correctly (pointed to one of the managed server)
The most interesting part is I have configured cluster in distributed environment. I have deployed the project to a cluster with two managed servers. one managed server is configured to another physical server..
When i try the workspace with server1:9001\workspace am able to see the deployed processes without any errors/exceptions
but when i try the workspace with server2:9002\workspace am getting process unavailable error..
server1:9001 -- managed server1 of the cluster to which the process is deployed
server2:9002 - managed server2 of the cluster to which the process is deployed
Kindly help
Thanks,
Charan
Edited by: charan27 on May 26, 2010 5:24 AM

Which connection I should use in the ejb clustered environment

We use EJB in jboss cluster environment. We have one oracle database.
our existed system use TXConnection(transactional connection) for the data insert, update and delete. Using the Connection for the data retriving.
I think TXConnection fits to use for the distributed database. So we should change our DAO layer to use only Connection.
Is that true?
Need help.
Thanks.
Jack Tie

Huh? Connection is an interface. You will have to use
any implementation anyway.It is not so simple. This is a legit question because he has asking if a specific implementation is required.
It would have been better posted in the JDBC forum. I don't know what the answer is for certain but I would lean towards yes it is required because of the clustered nature.

Call EJB in WLS 7.0SP2 from WLS 5.1 SP13

Hello,
I am trying to call an EJB deployed on WLS 7.0SP2 from a WLS 5.1 SP13.
There are issues from 19 Dec 2002 in "weblogic.developer.interest.rmi-iiop" newsgroup
that are supossed to established a summary on this interoperability. The solution
seems to be the same as the interoperability between WLS 6.1SP2 and WLS5.1SP12
with I have been working for several months. I have followed the steps (EJB generated
with "weblogic.ejbc -iiop" in WLS 7.0 and client classes generated with "weblogic.ejbc
-iiop -clienteJar" in WLS5.1) but the only result I obtain is the following exception.
Has anybody really invoked EJBs between this two WLS versions with IIOP?.
javax.naming.NamingException: Unhandled error in lookup. Root exception is java.lang.NullPointerException
at javax.naming.NameImpl.<init>(NameImpl.java:250) at javax.naming.CompositeName.<init>(CompositeName.java:223)
at weblogic.iiop.IIOPInvocationHandlerImpl.getClusteredStub(IIOPInvocationHandlerImpl.java:150)
at weblogic.iiop.IIOPInvocationHandlerImpl.resolveObject(IIOPInvocationHandlerImpl.java:114)
at weblogic.iiop.IIOPReplacer.resolveObject(IIOPReplacer.java:375) at weblogic.iiop.AbstractMsgInput.readRemote(AbstractMsgInput.java:185)
at weblogic.iiop.AbstractMsgInput.readObject(AbstractMsgInput.java:156) at weblogic.cos.naming.NamingContext_WLStub.resolve(NamingContext_WLStub.java:122)
at weblogic.jndi.cosnaming.IIOPInitialContextServer.lookup(IIOPInitialContextServer.java:109)
at javax.naming.InitialContext.lookup(InitialContext.java:345) at jsp_servlet._jsp.__test._jspService(__test.java:108)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:27) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:120)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:138)
at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:946)
at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:910)
at weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:277)
at weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:403)
at weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:285)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:130)
Thanks for any help,
Rosa

Hello,
I am trying to call an EJB deployed on WLS 7.0SP2 from a WLS 5.1 SP13.
There are issues from 19 Dec 2002 in "weblogic.developer.interest.rmi-iiop" newsgroup
that are supossed to established a summary on this interoperability. The solution
seems to be the same as the interoperability between WLS 6.1SP2 and WLS5.1SP12
with I have been working for several months. I have followed the steps (EJB generated
with "weblogic.ejbc -iiop" in WLS 7.0 and client classes generated with "weblogic.ejbc
-iiop -clienteJar" in WLS5.1) but the only result I obtain is the following exception.
Has anybody really invoked EJBs between this two WLS versions with IIOP?.
javax.naming.NamingException: Unhandled error in lookup. Root exception is java.lang.NullPointerException
at javax.naming.NameImpl.<init>(NameImpl.java:250) at javax.naming.CompositeName.<init>(CompositeName.java:223)
at weblogic.iiop.IIOPInvocationHandlerImpl.getClusteredStub(IIOPInvocationHandlerImpl.java:150)
at weblogic.iiop.IIOPInvocationHandlerImpl.resolveObject(IIOPInvocationHandlerImpl.java:114)
at weblogic.iiop.IIOPReplacer.resolveObject(IIOPReplacer.java:375) at weblogic.iiop.AbstractMsgInput.readRemote(AbstractMsgInput.java:185)
at weblogic.iiop.AbstractMsgInput.readObject(AbstractMsgInput.java:156) at weblogic.cos.naming.NamingContext_WLStub.resolve(NamingContext_WLStub.java:122)
at weblogic.jndi.cosnaming.IIOPInitialContextServer.lookup(IIOPInitialContextServer.java:109)
at javax.naming.InitialContext.lookup(InitialContext.java:345) at jsp_servlet._jsp.__test._jspService(__test.java:108)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:27) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:120)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:138)
at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:946)
at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:910)
at weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:277)
at weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:403)
at weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:285)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:130)
Thanks for any help,
Rosa

Pros/Cons of separating servlet/EJB clusters

          What and the pros and cons of establishing a cluster for the servlet layer and
          a separate cluster for the EJB layer?
          The rational behind this decision would be to take advantage of a shared infrastructure
          where multiple EJB components could be deployed in a cluster where they are accessed
          from multiple servlet/clusters.
          The obvious con is the fact that all calls between the servlet layer and the EJB
          layer will be remote calls however, there should be a greater level of availability
          and scalability.
          What are the other issues behind this deployment strategy?


I don't recall any other problems with this topology other than the one
          that you already mentioned. Infact i have seen several customer using
          this topology. i.e. having WebTier Cluste and EJB tier cluster.
          Kumar
          JD wrote:
          > What and the pros and cons of establishing a cluster for the servlet layer and
          > a separate cluster for the EJB layer?
          >
          > The rational behind this decision would be to take advantage of a shared infrastructure
          > where multiple EJB components could be deployed in a cluster where they are accessed
          > from multiple servlet/clusters.
          >
          > The obvious con is the fact that all calls between the servlet layer and the EJB
          > layer will be remote calls however, there should be a greater level of availability
          > and scalability.
          >
          > What are the other issues behind this deployment strategy?
          >

SOAP (EJBs) clustering (WLS 7.0)

Similar Messages

Maybe you are looking for