WLS 6.1 Webapp using EJB from WLS 9.0

I have a WLS 6.1.7 based webapp that currently accesses an EJB deployed to WLS 8.1.5. I just tried upgrading the 8.1 server to 9.0.0. I was able to deploy the EJB just fine but the 6.1.7 based webapp is giving me the following error:
javax.naming.CommunicationException. Root exception is
weblogic.socket.UnrecoverableConnectException: [Login failed: 'Incompatible version:Incompatible versions - this server: '9.0.0' client: '6.1.7.0']
at weblogic.socket.Login.checkLoginSuccess(Login.java:77)
at weblogic.rjvm.t3.T3JVMConnection.connect(T3JVMConnection.java:273)
at weblogic.rjvm.t3.T3JVMConnection.createConnection(T3JVMConnection.java:325)
at weblogic.rjvm.Protocol.createConnection(Protocol.java:206)
at weblogic.rjvm.ConnectionManager.findOrCreateConnection(ConnectionManager.java:1121)
at weblogic.rjvm.ConnectionManager.bootstrap(ConnectionManager.java:373)
at weblogic.rjvm.ConnectionManager.bootstrap(ConnectionManager.java:274)
at weblogic.rjvm.RJVMManager.findOrCreateRemoteInternal(RJVMManager.java:222)
at weblogic.rjvm.RJVMManager.findOrCreate(RJVMManager.java:189)
at weblogic.rjvm.RJVMFinder.findOrCreateRemoteServer(RJVMFinder.java:186)
at weblogic.rjvm.RJVMFinder.findOrCreate(RJVMFinder.java:157)
at weblogic.rjvm.ServerURL.findOrCreateRJVM(ServerURL.java:207)
at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java:309)
at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java:213)
at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactory.java:149)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:660)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:241)
at javax.naming.InitialContext.init(InitialContext.java:217)
at javax.naming.InitialContext.<init>(InitialContext.java:193)
The Initial Context is being created with the following properties:
java.naming.provider.url=t3://localhost:7001
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
java.naming.security.principal=system
java.naming.security.credentials=xxxx
Is there a way to get WLS 6.1 to talk to WLS 9.0?
Thanks,
Rick

I believe the constraint is communicating within 2 releases. ie 6.0 can talk to 7.0 and 8.1, but 9.0 is 3 releases away.
That being said, you can double-check this with [email protected]
-- Rob
WLS Blog http://dev2dev.bea.com/blog/rwoollen/

Similar Messages

Error using EJB from webapp.

Hi
Im trying to move a j2ee application from BEA to SunOne A 7.0.
Im getting an error when using/creating a EJB.
But i can use any method on another EJB. I havent set any authority rules at all and the xml file looks the same for both EJBs.
This application works fine on the BEA container.
The error is:
javax.ejb.EJBException: nested exception is: javax.ejb.EJBException: nested exception is: javax.ejb.CreateException: Could not create stateless EJB: java.security.AccessControlException: access denied (java.util.PropertyPermission * read,write)
javax.ejb.EJBException: nested exception is: javax.ejb.CreateException: Could not create stateless EJB: java.security.AccessControlException: access denied (java.util.PropertyPermission * read,write)
javax.ejb.CreateException: Could not create stateless EJB: java.security.AccessControlException: access denied (java.util.PropertyPermission * read,write)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:528)
at com.sun.ejb.containers.StatelessSessionContainer.access$000(StatelessSessionContainer.java:68)
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:734)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject(NonBlockingPool.java:176)
at com.sun.ejb.containers.StatelessSessionContainer.getContext(StatelessSessionContainer.java:457)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:452)
at se.ltjkpg.itc.intra.ejb.session.db.DBinterfaceBean_EJBObjectImpl.select(DBinterfaceBean_EJBObjectImpl.java:108)
at se.ltjkpg.itc.intra.ejb.session.db._DBinterfaceBean_EJBObjectImpl_Tie._invoke(Unknown Source)
at com.sun.corba.ee.internal.POA.GenericPOAServerSC.dispatchToServant(GenericPOAServerSC.java:569)
at com.sun.corba.ee.internal.POA.GenericPOAServerSC.internalDispatch(GenericPOAServerSC.java:211)
at com.sun.corba.ee.internal.POA.GenericPOAServerSC.dispatch(GenericPOAServerSC.java:113)
at com.sun.corba.ee.internal.iiop.ORB.process(ORB.java:275)
at com.sun.corba.ee.internal.iiop.RequestProcessor.process(RequestProcessor.java:83)
at com.iplanet.ias.corba.ee.internal.iiop.ServicableWrapper.service(ServicableWrapper.java:25)
at com.iplanet.ias.util.threadpool.FastThreadPool$ThreadPoolThread.run(FastThreadPool.java:283)
at java.lang.Thread.run(Thread.java:536)
javax.ejb.EJBException: nested exception is: javax.ejb.CreateException: Could not create stateless EJB: java.security.AccessControlException: access denied (java.util.PropertyPermission * read,write)
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:736)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject(NonBlockingPool.java:176)
at com.sun.ejb.containers.StatelessSessionContainer.getContext(StatelessSessionContainer.java:457)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:452)
at se.ltjkpg.itc.intra.ejb.session.db.DBinterfaceBean_EJBObjectImpl.select(DBinterfaceBean_EJBObjectImpl.java:108)
at se.ltjkpg.itc.intra.ejb.session.db._DBinterfaceBean_EJBObjectImpl_Tie._invoke(Unknown Source)
at com.sun.corba.ee.internal.POA.GenericPOAServerSC.dispatchToServant(GenericPOAServerSC.java:569)
at com.sun.corba.ee.internal.POA.GenericPOAServerSC.internalDispatch(GenericPOAServerSC.java:211)
at com.sun.corba.ee.internal.POA.GenericPOAServerSC.dispatch(GenericPOAServerSC.java:113)
at com.sun.corba.ee.internal.iiop.ORB.process(ORB.java:275)
at com.sun.corba.ee.internal.iiop.RequestProcessor.process(RequestProcessor.java:83)
at com.iplanet.ias.corba.ee.internal.iiop.ServicableWrapper.service(ServicableWrapper.java:25)
at com.iplanet.ias.util.threadpool.FastThreadPool$ThreadPoolThread.run(FastThreadPool.java:283)
at java.lang.Thread.run(Thread.java:536)
javax.ejb.EJBException: nested exception is: javax.ejb.EJBException: nested exception is: javax.ejb.CreateException: Could not create stateless EJB: java.security.AccessControlException: access denied (java.util.PropertyPermission * read,write)
at com.sun.ejb.containers.StatelessSessionContainer.getContext(StatelessSessionContainer.java:461)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:452)
at se.ltjkpg.itc.intra.ejb.session.db.DBinterfaceBean_EJBObjectImpl.select(DBinterfaceBea

Grant the property permission in config/server.policy file of your app server instance
for eg:
grant {
permission java.util.PropertyPermission "os.version", "read";
HTH
Satish

ClassCastException using EJB from a service

Hi all,
I developed a DeployService and currently I'm getting a ClassCastException while accessing the a EJB.
I put the lookup within a delegate which is also be used from a webDynpro application. With the WebDynpro App everything work properly, but if I call the delegate from the service a SAPClassCastException I thrown, when I cast the object to the home interface.
The coding is as follows:
               Properties props = new Properties();
               props.put(Context.PROVIDER_URL,"localhost:50004");
               props.put(Context.INITIAL_CONTEXT_FACTORY,
               "com.sap.engine.services.jndi.InitialContextFactoryImpl");
               context = new InitialContext(props);
               Object obj = context.lookup(jndiName);
               EJBHome ejb = EJBHomeFactory.getInstance().lookup(jndiName, ComponentHome.class);
               ComponentHome componentHome = (ComponentHome)ejb;
Thanks a lot for the help.
Falk

Hi Falk,
Hey just tell me that what is the EJBHome and ComponentHome and EJBHomeFactory in your coding.....
You can try the following code for the same.
Object obj =(Object) jndicontext.lookup("<Your JNDI name>");
TestEJBHome home = (TestEJBHome) javax.rmi.PortableRemoteObject.narrow(
               obj,
               TestEJBHome.class);
TestEJB hello = home.create();
Here, TestEJBHome is your Home interface of the EJB and TestEJB is your remote interface. Now you can use hello object to call your business methods of EJB.
Regards,
Bhavik

Using EJB from another connection pool in WLPI

Hi All,
I've deployed an entity bean (CMP) which used the connection pool other than the
one used by WLPI. When I execute the business operation I've defined for this
bean, the following exception is encountered:
"Couldn't get connection: java.sql.SQLException: Connection has already been created
in this tx context for pool named wlpiPool. Illegal attempt to create connection
from another pool: oraclePool"
Is there any other alternative for me to use the entity bean in WLPI?
Thanks,
Fred

Instead of using mulitiple connection pool,we are using single connection pool.
Our one application, accessing remote db also, for that we are using simple jdbc
connection. No pool.
We also tried OracleXAdriver. In that case, at the time of startup we are getting
weird error.
Thanks
JIgnesh Patel
"Fred" <[email protected]> wrote:
>
I simply turned all my CMP to BMP and get the connection from another
connection
pool. But that was not what I want. Is there any method that allows a
CMP to use
connection pool other than the wlpiPool pool in WLPI?
Thanks
"jignesh" <[email protected]> wrote:
Hi Fred,
We are also getting same error. How did you resolve this error ?
I'd appreciate,if you can post resolution of this error.
Thanks
Jignesh Patel
"Fred" <[email protected]> wrote:
Hi All,
I've deployed an entity bean (CMP) which used the connection pool other
than the
one used by WLPI. When I execute the business operation I've defined
for this
bean, the following exception is encountered:
"Couldn't get connection: java.sql.SQLException: Connection has already
been created
in this tx context for pool named wlpiPool. Illegal attempt to create
connection
from another pool: oraclePool"
Is there any other alternative for me to use the entity bean in WLPI?
Thanks,
Fred

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])

How can use EJB local call in WLS 7.0 without EAR

I have web application as jsp files.
and I made .jar for some EJBs
and I used local call for calling EJB from jsps in WLS 6.1
but in WLS 7.0 .. occured error calling EJB as Local call
while JNDI lookup.
So I packed all applications as EAR and deployed then all works good.
but in developing I want to use JSPs as jsp files.
There is no way to use Local call to EJB in WLS 7.0 without packing EAR ? (like
WLS 6.1)

The way JNDI lookups were implemented in 6.1 allowed to deploy individual ejb-jars
and access their local interfaces via JNDI lookups from other ejb-jars during
development. In production all ejb-jars will be packaged into an ear.
This is extremely helpful on large projects. E.g. my current project has over
120 CMP entity beans and over 40 session beans. Even on 2GHz class machine with
1Gb memory and JDK 1.4 (to enable full-speed debugging) it takes almost a minute
to deploy the ear (no matter whether it is exploded or not). It takes minutes
with 1.3 and debugging turned on.
6.1 implementation allowed to "pre-deploy" relatively static ejb-jars and still
access their local interfaces (by putting them on WL system classpath and deploying
as individual ejb-jars, so classes are accessible to local clients; it requires
WL restart when they are changed, but they don't change often). So during development
only changed jars (typically session facade) need to be redeployed on changes,
which takes only seconds. We didn't have problem with JNDI lookup performance
since we use the EJBHomeFactory pattern.
The behind-the-scene JNDI optimization "improvement" introduced in 7.0 makes it
no longer possible to use this technique, since even though classloading still
works in the same way, no objects are bound to JNDI tree and thus could not be
access from another ejb-jar. This significantly impacts developer productivity
(in our large project). It's not only about minutes lost (which btw makes hours
over time), it just disrupts developer's train of thought to have such long round
trip times. In fact this is the reason we are not going to migrate to WL 7.0.
Is it possible to provide an option to turn this "optimization" off and actually
bind JNDI objects?
Thank you,
Sergey
"Dimitri I. Rakitine" <[email protected]> wrote:
Park <[email protected]> wrote:
Thanks Rakitine.
I wonder if I use EAR while developing could I apply changes to EARwhithout packing
again.Sure - you can simply deploy your app as an 'exploded' EAR during development.
There is no probelm delivering time but in developing time ..
If I can not use that kind of way how can I make modification ?
Plz. let me know.
And I have one more question.
When I use EAR I met some problem.
I packed all JSP into one .war file.
fot that I had to inclde requred classes into .war because jsps usethese classes.
then I packed EAR file with WAR and some EJB jar files.
After then I deployed EAR file to WLS.
But If remove classes from classpth while EJB deploying Error occured.Because
EJBs reference these classes.
I thoght if I packed classes into .WAR .. there is no problem.
But Error occured.
I have to include classes into classpth for that ? or
Any mistakes in my way.No, you do not have to add anything to the system classpath. In fact,
you should
make sure that none of your application classes are in the system classpath.
thank you.
"Dimitri I. Rakitine" <[email protected]> wrote:
Yup, that appears to be the difference between 6.1 and 7.0 - in
6.1 success of a local invocation depended only on the Classloaders
arrangement, so everything worked when you added your classes to the
system classpath. In 7.0 looks like it also depends on the application
context - that's why you cannot do a JNDI lookup from another deployment
unit.
Is there any reason why you do not want to use EAR's ???
Park <[email protected]> wrote:
in WLS 6.1 ..
I have EJB as jar files. (deployed each to WLS)
and I added EJB interface class to classpath.
and I made WebApplication as Directory (not war file).
in that webappication jsp call EJB as Local interface.
These environment .. local call workes well in WLS 6.1.
but in 7.1 not works .. (JNDI look up error)
of course Remote call works well. and If I make EAR .. works well.
Rob Woollen <[email protected]> wrote:
You can have an exploded EAR and have it work.
Can you give some more detail on how you are deploying in 6.1. Is
it
an
exploded EAR, or do you have the ejb interfaces in the classpath?
This behavior should not have changed between 6.1 and 7.0.
-- Rob
park wrote:
I have web application as jsp files.
and I made .jar for some EJBs
and I used local call for calling EJB from jsps in WLS 6.1
but in WLS 7.0 .. occured error calling EJB as Local call
while JNDI lookup.
So I packed all applications as EAR and deployed then all works
good.
but in developing I want to use JSPs as jsp files.
There is no way to use Local call to EJB in WLS 7.0 without packingEAR ? (like
WLS 6.1)
Dimitri
Dimitri

Stateless Session EJB hangs using URLConnection but WLS doesn't clean up

Hi
We have a stateless session EJB running under WLS 5.1 with service
pack 10 on Solaris.
The bean calls a remote HTTP server using the java.net.URLConnection
class and forwards the response to the EJB client. The bean is largely
working fine but some threads hang waiting on the HTTP response. Debug
statements, which are written immediately after the response has been
read and the connection has been closed, do not appear in our log for
the hung threads. The WebLogic Console displays these threads as "in
use" and a "netstat -an" displays the tcp connections as ESTABLISHED.
However, the access logs of the remote Apache server show the HTTP
connections of the threads in question completed successfully with
HTTP code 200. The Apache server is using keep-alive connections.
Some EJB threads are still waiting for something it seems.
Has anyody else experienced this when using URLConnection from
stateless session EJBs under WLS?
The second problem is why doesn't WLS time these threads out after
trans-timeout-seconds (we're using the default of 300 seconds)? The
WLS log shows no error messages relating to this problem.
I'm grateful for any info offered.
Thanks in advance
Steve

If you suspect that WLS protocol handler is at fault (and quite often it is),
one thing to try is (if you use Sun's JVM) to use Sun's HTTP protocol handler
instead of WLS (the most common symptom is when code which makes HTTP requests
works fine outside of WebLogic and you have problems getting it to work inside
WebLogic) :
replace
URL url = new URL("http://...");
HttpURLConnection conn = (HttpURLConnection)url.openConnection();
with
URL url = new URL(null, "http://...", new sun.net.www.protocol.http.Handler());
HttpURLConnection conn = (HttpURLConnection)url.openConnection();
You will have to edit weblogic.policy to allow your code to specify protocol
handler.
Also note that transaction timeout is only checked on method boundaries, or
when your code attempts to do something with the database - it is not going to
interrupt thread which is waiting for HTTP response.
Steve Lock <[email protected]> wrote:
Hi
Thanks for the info. The remote HTTP server's access log shows that
the requests were successfully processed. Doesn't this mean that the
connection is then closed? I know the web server is using keep-alive
connections but I thought this was transparent to the client...?
Also why doesn't WLS remove the hung threads?
Steve
"Ignacio G. Dupont" <[email protected]> wrote in message news:<[email protected]>...
We have had a problem like yours with Weblogic 6.1 SP2 on Linux
The problem is sun's implementation of the HTTP connections doesn't have a
timeout, so if the other peer doesn't close the connection your threads will
be "locked" on the connection.
We have found searching the web that the Jakarta project has a package
called Jakarta commons that implements HTTP connections with an
setSoTimeout(int timeout) method so you can open the connections with your
desired timeout. You have to download the code from the CVS as the released
version doesn't support the timedout sockets yet.
When support for the JDK 1.4 version will be announced by Bea you could use
one of its new features that will allow you to pass arguments to the JVM to
specify the maximum socket connection stablising timeout and the max
inactivity on the socket too.
Hope it helps you.
Dimitri

Upgrading from WLS 8.1 to Oracle WLS 10.3

Hi,
I'm planning to upgrade a client's system consisting of multiple applications running on WLS 8.1 to Oracle WLS 10.3.
Is this an officially supported upgrade path? What would be the best way to do the upgrade?
Are there any tools for automatically importing or converting the old configuration or domains?
Or is it better to create new installations from scratch and manually configure them?
Is there any documentation for this upgrade path?
In practice we would need to run both application servers in parallel for a while.
Can I expect the different server versions to interoperate with each other?
The applications mostly communicate using EJB (v2.0) calls but JMS and Web Services are used as well.
I've tested the EJB calls and they seem to work but what about JMS?

Thanks.
Can WLS JMS v8.1 be used as a messaging provider for WLS v10.3 and 8.1 instances
(using it directly or through the Messaging Bridge)?
Is this described in the documentation somewhere?
I also found the following documents that address version compatibility:
http://download.oracle.com/docs/cd/E13222_01/wls/docs103/compatibility/compatibility.html
http://download.oracle.com/docs/cd/E13222_01/wls/docs103/upgrade/compat.html

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

Using a foreign WLS JMS queue (no bridge)

          Hi,
          We have a configuration from which we communicate from WLS 7 to a foreign MQ via
          JMS. This works well and we have loaded the foreign MQ jms objects into WLS JNDI
          using a statup class (as the whitepaper available describes) and we look them
          up successfully.
          However, we now have a siutation where we briefly need to switch our application
          to point to a WLS JMS queue on another remote WLS server. Is there an easy way
          to load foreign (maybe remote would be a better word in this case) WLS JMS QCF's
          and destinations into my local WLS JNDI so that I can treat them the same way
          as my MQ objects?
          I can't seem to find any information on how to do this as all information seems
          to point towards the messaging bridge (we can't use this as the bridge changes
          the message JMSMessageID and screws our correlation mechanism up).
          I know we could just look the foreign objects up by using the JNDI environment
          of the remote WLS machine but this would mean changing code and this I can't to
          do (as all our code uses the local default WLS JNDI).
          Any ideas would be gratefully received.
          Cheers,
          Jay.


WLS JMS and MQ JMS handle their JNDI objects a little differently, so I can
          see how this can be confusing. An MQ JMS "ConnectionFactory" or
          "Destination" object is like a little configuration file that tells you
          where the queue manager or queue is, so you can serialize it and look it up
          later and use it to find the queue manager.
          A WLS JMS ConnectionFactory or Destination object is a reference to an
          object on a running server. So, you connect to the server and look them up,
          and then you can use it for messaging. You don't have to store these objects
          in a separate place, like MQ makes you do. But it means that the WLS JNDI
          objects have to be looked up from a running server, and if the server
          restarts, you have to look them up again.
          Doing what you're asking is definitely trickier in 7.0. One thing you could
          do is, again using a servlet or an EJB, connect to the remote JMS cluster
          and look up the objects at the time you want to make the switch. (If the
          remote cluster is down, you'll have to retry from time to time.) If the
          remote cluster is down, you won't be able to look up those objects, but then
          again, if it were down you wouldn't be able to send messages there anyway.
          Using 8.1 would be less complicated, but this method should also work.
          greg
          "Jay Green" <[email protected]> wrote in message
          news:[email protected]...
          >
          > Thanks Greg. When I was searching the BEA website I read about the
          facility in
          > 8.1. Unfortunatley, as you point out, it doesn't help me much with WLS
          7.0.
          >
          > My first thought was to copy my exisiting MQ startup class but I couldn't
          work
          > out how to do this for the remote WLS jms objects as the standard jms
          classes
          > (for QCF etc) don't have methods that allow me to define the foreign WLS
          jms
          > host IP address etc. I checked the WLS 7 API and the jms package didn't
          seem
          > to offer anything to help me do this (as IBM do for MQ). Any ideas?
          >
          > Apologies if I'm being a bit slow here!
          >
          > "Greg Brail" <[email protected]> wrote:
          > >WLS 8.1 includes a feature called "Foreign JMS Providers" that lets you
          > >configure (using the console or config.xml) a link between a JMS JNDI
          > >object
          > >in your WLS servers' tree, and a JNDI object in another provider -- which
          > >could be WLS JMS, or a foreign vendor.
          > >
          > >Using this feature, your application could just look up the local JNDI
          > >objects in the local WLS tree, and then the server in turn performs the
          > >lookup from the actual JNDI provider using the parameters you put in
          > >the
          > >console (or config.xml). So, when you make a change in the console, new
          > >JNDI
          > >lookups will go to the new place.
          > >
          > >Unfortunately, this doesn't help you with 7.0. You could always
          > >programmitically update the local JNDI tree the way you're doing in your
          > >startup class, but instead do it from a servlet or an EJB.
          > >
          > > greg
          > >
          > >"Jay Green" <[email protected]> wrote in message
          > >news:[email protected]...
          > >>
          > >> Hi,
          > >>
          > >> We have a configuration from which we communicate from WLS 7 to a
          foreign
          > >MQ via
          > >> JMS. This works well and we have loaded the foreign MQ jms objects
          > >into
          > >WLS JNDI
          > >> using a statup class (as the whitepaper available describes) and we
          > >look
          > >them
          > >> up successfully.
          > >>
          > >> However, we now have a siutation where we briefly need to switch our
          > >application
          > >> to point to a WLS JMS queue on another remote WLS server. Is there
          > >an easy
          > >way
          > >> to load foreign (maybe remote would be a better word in this case)
          > >WLS JMS
          > >QCF's
          > >> and destinations into my local WLS JNDI so that I can treat them the
          > >same
          > >way
          > >> as my MQ objects?
          > >> I can't seem to find any information on how to do this as all
          information
          > >seems
          > >> to point towards the messaging bridge (we can't use this as the bridge
          > >changes
          > >> the message JMSMessageID and screws our correlation mechanism up).
          > >>
          > >> I know we could just look the foreign objects up by using the JNDI
          > >environment
          > >> of the remote WLS machine but this would mean changing code and this
          > >I
          > >can't to
          > >> do (as all our code uses the local default WLS JNDI).
          > >>
          > >> Any ideas would be gratefully received.
          > >>
          > >> Cheers,
          > >>
          > >> Jay.
          > >
          > >
          >

Calling db2 stored procedures from wls 8.1 sp2

Hi,
We noticed strange behaviour when moving customers applications from wls 6.1 to 8.1 sp2. We have a use case where we call db2 stored procedure two times (same prcedure) to make inserts to a database. The first time when procedure is called, everything goes smoothly but at the second time db2 claims that statement is not prepared and gives us sql error sql0518n.
We do see this error only if we use wls prepared statement cache and without cache (size=0) everything seems to work. We also did some db2 level tracing and noticed that statement is not prepared when using wls cache and db2 cannot execute statement which is not prepared....
Why I'm asking this? because this is the first time I had disable wls cache. We have used it and even optimized software performance using prepared statement cache in several projects before this.
Procedure call is done from web container lavel and no EJBs is used. We have tested the use case using autommit option and also committed firts transaction manually and closed connection.
We are using DB2 8.2 fp7 as a database and IBM level 2 JDBC driver without XA support. Honor global transactions support is on at a datasource.
Is this normal behaviour? Db2 problem or maybe WLS problem?
Regards,
Mika

I am getting the same exception about an assertion failed at weblogic.t3.srvr.T3Srvr.checkServerLock. Any ideas?

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.

How to add external jars when deploying webapp via worksop for wls 9.2

While attempting to deploy my web application using Workshop for WLS 9.2, WLS complains it is unavailable to resolve references to a 3rd party JAR(tomhawk.jar) which is being referenced by the JSPs. I have added the JAR via the J2EE module dependancy tab in workshop but that does not seem to be helping the deployment.
If i build the web application outside workshop and include the tomhawk.jar in the WEB-INF/lib folder of the deployed WAR file, the app works fine.
I have attempted to copy the tomhawk.jar into the <domain>/lib folder and restart the weblogic server. But this does not seem to help resolve the references.
Any clues on how i could achieve iterative deployments via workshop for WLS 9.2 pickup references to external JARs being referenced by the JSPs.
Thanks
Ramdas

Raj,
Thanks for your suggestion. The link that you sent out was useful. I was actually able to get the webapp to resolve its references to the 3rd party classes by adding the tomhawk.jar as an external jar via the "build path" property for the web project. I tested this by running the app in the WLS instance hosted by workshop and looks like the JAR from the build path gets somehow referenced during run time too. Not sure how this works?
Thanks
Ramdas

Enterprise application conversion problem from WLS 10.3.0 to WLS 10.3.2

Hi all,
I'm posting this just to document a problem I had when converting an Enterprise Application from WLS 10.3.0 across to WLS 10.3.2 environment.
Upon deployment of the application I was getting this error:
Caused By: weblogic.descriptor.BeanAlreadyExistsException: Bean already exists: "weblogic.j2ee.descriptor.wl.ApplicationParamBeanImpl@b720894d(/ApplicationParams[webapp.encoding.default])"
     at weblogic.descriptor.internal.ReferenceManager.registerBean(ReferenceManager.java:227)
     at weblogic.j2ee.descriptor.wl.WeblogicApplicationBeanImpl.setApplicationParams(WeblogicApplicationBeanImpl.java:560)
     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:597)
     at com.bea.staxb.runtime.internal.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:48)
     at com.bea.staxb.runtime.internal.RuntimeBindingType$BeanRuntimeProperty.setValue(RuntimeBindingType.java:536)
     at com.bea.staxb.runtime.internal.AttributeRuntimeBindingType$QNameRuntimeProperty.fillCollection(AttributeRuntimeBindingType.java:381)
     at com.bea.staxb.runtime.internal.MultiIntermediary.getFinalValue(MultiIntermediary.java:52)
     at com.bea.staxb.runtime.internal.AttributeRuntimeBindingType.getFinalObjectFromIntermediary(AttributeRuntimeBindingType.java:140)
     at com.bea.staxb.runtime.internal.UnmarshalResult.unmarshalBindingType(UnmarshalResult.java:200)
     at com.bea.staxb.runtime.internal.UnmarshalResult.unmarshalDocument(UnmarshalResult.java:169)
     at com.bea.staxb.runtime.internal.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:65)
     at weblogic.descriptor.internal.MarshallerFactory$1.createDescriptor(MarshallerFactory.java:150)
     at weblogic.descriptor.BasicDescriptorManager.createDescriptor(BasicDescriptorManager.java:323)
     at weblogic.application.descriptor.AbstractDescriptorLoader2.getDescriptorBeanFromReader(AbstractDescriptorLoader2.java:788)
     at weblogic.application.descriptor.AbstractDescriptorLoader2.createDescriptorBean(AbstractDescriptorLoader2.java:409)
     at weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescriptorBeanWithoutPlan(AbstractDescriptorLoader2.java:759)
     at weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescriptorBean(AbstractDescriptorLoader2.java:768)
     at weblogic.application.ApplicationDescriptor.getWeblogicApplicationDescriptor(ApplicationDescriptor.java:329)
     at weblogic.application.internal.EarDeploymentFactory.findOrCreateComponentMBeans(EarDeploymentFactory.java:181)
     at weblogic.application.internal.MBeanFactoryImpl.findOrCreateComponentMBeans(MBeanFactoryImpl.java:48)
     at weblogic.application.internal.MBeanFactoryImpl.createComponentMBeans(MBeanFactoryImpl.java:110)
     at weblogic.application.internal.MBeanFactoryImpl.initializeMBeans(MBeanFactoryImpl.java:76)
     at weblogic.management.deploy.internal.MBeanConverter.createApplicationMBean(MBeanConverter.java:88)
     at weblogic.management.deploy.internal.MBeanConverter.createApplicationForAppDeployment(MBeanConverter.java:66)
     at weblogic.management.deploy.internal.MBeanConverter.setupNew81MBean(MBeanConverter.java:314)
     at weblogic.deploy.internal.targetserver.operations.ActivateOperation.compatibilityProcessor(ActivateOperation.java:81)
     at weblogic.deploy.internal.targetserver.operations.AbstractOperation.setupPrepare(AbstractOperation.java:295)
     at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:97)
     at weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:217)
     at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:747)
     at weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1216)
     at weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:250)
     at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:159)
     at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:157)
     at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:12)
     at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:45)
     at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516)
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
It turns out this was an issue with the META-INF/weblogic-application.xml having duplicate entries for the "webapp.encoding.default" parameter.
This obviously got duplicated when my app was re-imported into the Eclipse OPEP environment for WLS 10.3.2
<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-application xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-application" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/javaee_5.xsd http://xmlns.oracle.com/weblogic/weblogic-application http://xmlns.oracle.com/weblogic/weblogic-application/1.0/weblogic-application.xsd">


<wls:application-param>
<wls:param-name>webapp.encoding.default</wls:param-name>
<wls:param-value>UTF-8</wls:param-value>
</wls:application-param>
<wls:application-param>
<wls:param-name>webapp.encoding.default</wls:param-name>
<wls:param-value>UTF-8</wls:param-value>
</wls:application-param>
</wls:weblogic-application>
Removing the duplicate entry resolved this problem.
I hope this helps anyone else that experiences this issue.
Regards,
Paul

Below link might be helpful.
http://kr.forums.oracle.com/forums/thread.jspa?threadID=1049509&tstart=0
Regards,
Anandraj
http://weblogic-wonders.com/

JMS Bridge from WLS to OAS not working; automatic redirection to JMS Port

We have setup a JMS Bridge inbetween Weblogic Server 10.3.0 and Oracle App Server 10.1.3. In our test environment it is working fine. But, in LIVE, we are facing a problem. Firewall is there inbetween OAS and WLS.
1. OAS Admin port 6003, is blocked by firewall. So, from outside environment we can't connect to this port.
2. OAS Port 12401 (RMI Port) is not-blocked
3. OAS Port 12601 (JMS Port) is blocked by firewall
4. We created credential "JMS_USER" while configuring QueueConnFactory at OAS end and used it while setting up WLS JMS Bridge
We are using ormi://172.24.255.59:12401/default as Provider URL from Weblogic while creating JMS Bridge.
Problem
========
While connecting from WLS we are getting the following error from WLS end:
javax.jms.JMSException: Unable to create a connection to "apgst366/172.24.255.59:12,601" as user "JMS_USER".
     at com.evermind.server.jms.JMSUtils.make(JMSUtils.java:1050)
     at com.evermind.server.jms.JMSUtils.toJMSException(JMSUtils.java:1130)
     at com.evermind.server.jms.EvermindConnection.<init>(EvermindConnection.java:132)
     at com.evermind.server.jms.EvermindQueueConnection.<init>(EvermindQueueConnection.java:71)
Question
=========
1) We are requesting for 12401; then why the JMS Port 12601 is being referred?
2) Is there any automatic redirection from OAS end?
3) Will unblocking the 12601 port by Firewall help?
Please help me, as this has become a burning issue for us.
Thanks in advance.

Can anybody please help me?

WLS 6.1 Webapp using EJB from WLS 9.0

Similar Messages

Maybe you are looking for