I met with some problem with WebLogic 9.2 last week.
I am using WebLogic 9.2 sp1 + AquaLogic 2.6 last time. I have created EJB (2.1 right from WLW) with some methods that throws Exceptions. I have tried to create transport typed business service (BS) for my EJB. When I looked into WSDL for that BS I did not find soap faults description for my methods. I sent request to BEA and got response with clarification and patch Id for resolve that problem :)
I installed that patch with Smart Update and it seemed was all okay then. I found SOAP fault block in my WSDL. But.
I tried to fulfil simple code on the patched serverside:
Hashtable h = new Hashtable();
h.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL, "t3://localhost:7002");
h.put(Context.SECURITY_PRINCIPAL, "weblogic");
h.put(Context.SECURITY_CREDENTIALS, "weblogic");
InitialContext inc = new InitialContext(h);
Pay attention that I looked up Initial Context in web application running on the "9.2 SP1 WebLogic Server with patched ALSB" to "8.1 "WebLogic Server"!
I have got Exception:
java.lang.AssertionError: java.lang.ClassNotFoundException: weblogic.jndi.internal.ServerNamingNode_920_WLStubat weblogic.jndi.WLInitialContextFactoryDelegate.newRootNamingNodeStub(WLInitialContextFactoryDelegate.java:587)at weblogic.jndi.WLInitialContextFactoryDelegate.newRemoteContext(WLInitialContextFactoryDelegate.java:559)
....
I had question: "Why Class Loader tries to find ServerNamingNode_920_WLStubat instead of ServerNamingNode_921_WLStubat". I started investigate that problem couple of days ago. I know reason now. But I have spent about a week for that problem :(
First of all I found line in my %WLS_HOME%\common\bin\commEnv.cmd
set PATCH_CLASSPATH=%WLS_HOME%\profiles\default\sys_manifest_classpath\weblogic_patch.jar
Pay attention that PATCH_CLASSPATH got the first place in domain claspath!
That was Jar was installed with patch. By going through chain from that Jar (by manifest Class-Path:... ) I found another Jar. It contains manifest file:
Manifest-Version: 1.0
Created-By: 1.5.0_03 (Sun Microsystems Inc.)
Implementation-Title: AquaLogic Service Bus 2.6 Patch for CR311833
Implementation-Version: 9.2
Implementation-Vendor: BEA Systems
Next I decompiled some chain of weblogic.jar classes (first was WLInitialContextFactoryDelegate) with JAD and have strange result:
------------------------------------------
WLInitialContextFactoryDelegate:
private NamingNode newRootNamingNodeStub(RemoteReference remotereference, int i)
{
...
Class class1 = Class.forName(RootNamingNode.STUB_NAME);
...
}
------------------------------------------
RootNamingNode:
STUB_NAME = ServerHelper.getStubClassName((weblogic.jndi.internal.ServerNamingNode.class).getName());
------------------------------------------
ServerHelper:
public static String getStubClassName(String s)
{
return s + WLS_STUB_VERSION;
}
....
public static final String WLS_STUB_VERSION = "_" + PeerInfo.getPeerInfo().getMajor() + PeerInfo.getPeerInfo().getMinor() + PeerInfo.getPeerInfo().getServicePack() + "_WLStub";
------------------------------------------
PeerInfo:
public static PeerInfo getPeerInfo()
{
return singleton;
}
...
VersionInfo versioninfo = VersionInfo.theOne();
singleton = new PeerInfo(versioninfo.getMajor(), versioninfo.getMinor(), versioninfo.getServicePack(), versioninfo.getRollingPatch(), versioninfo.hasTemporaryPatch(), versioninfo.getPackages());
------------------------------------------
VersionInfo:
public static VersionInfo theOne()
{
return Maker.THE_ONE;
}
I am using WebLogic 9.2 sp1 + AquaLogic 2.6 last time. I have created EJB (2.1 right from WLW) with some methods that throws Exceptions. I have tried to create transport typed business service (BS) for my EJB. When I looked into WSDL for that BS I did not find soap faults description for my methods. I sent request to BEA and got response with clarification and patch Id for resolve that problem :)
I installed that patch with Smart Update and it seemed was all okay then. I found SOAP fault block in my WSDL. But.
I tried to fulfil simple code on the patched serverside:
Hashtable
h.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL, "t3://localhost:7002");
h.put(Context.SECURITY_PRINCIPAL, "weblogic");
h.put(Context.SECURITY_CREDENTIALS, "weblogic");
InitialContext inc = new InitialContext(h);
Pay attention that I looked up Initial Context in web application running on the "9.2 SP1 WebLogic Server with patched ALSB" to "8.1 "WebLogic Server"!
I have got Exception:
java.lang.AssertionError: java.lang.ClassNotFoundException: weblogic.jndi.internal.ServerNamingNode_920_WLStubat weblogic.jndi.WLInitialContextFactoryDelegate.newRootNamingNodeStub(WLInitialContextFactoryDelegate.java:587)at weblogic.jndi.WLInitialContextFactoryDelegate.newRemoteContext(WLInitialContextFactoryDelegate.java:559)
....
I had question: "Why Class Loader tries to find ServerNamingNode_920_WLStubat instead of ServerNamingNode_921_WLStubat". I started investigate that problem couple of days ago. I know reason now. But I have spent about a week for that problem :(
First of all I found line in my %WLS_HOME%\common\bin\commEnv.cmd
set PATCH_CLASSPATH=%WLS_HOME%\profiles\default\sys_manifest_classpath\weblogic_patch.jar
Pay attention that PATCH_CLASSPATH got the first place in domain claspath!
That was Jar was installed with patch. By going through chain from that Jar (by manifest Class-Path:... ) I found another Jar. It contains manifest file:
Manifest-Version: 1.0
Created-By: 1.5.0_03 (Sun Microsystems Inc.)
Implementation-Title: AquaLogic Service Bus 2.6 Patch for CR311833
Implementation-Version: 9.2
Implementation-Vendor: BEA Systems
Next I decompiled some chain of weblogic.jar classes (first was WLInitialContextFactoryDelegate) with JAD and have strange result:
------------------------------------------
WLInitialContextFactoryDelegate:
private NamingNode newRootNamingNodeStub(RemoteReference remotereference, int i)
{
...
Class class1 = Class.forName(RootNamingNode.STUB_NAME);
...
}
------------------------------------------
RootNamingNode:
STUB_NAME = ServerHelper.getStubClassName((weblogic.jndi.internal.ServerNamingNode.class).getName());
------------------------------------------
ServerHelper:
public static String getStubClassName(String s)
{
return s + WLS_STUB_VERSION;
}
....
public static final String WLS_STUB_VERSION = "_" + PeerInfo.getPeerInfo().getMajor() + PeerInfo.getPeerInfo().getMinor() + PeerInfo.getPeerInfo().getServicePack() + "_WLStub";
------------------------------------------
PeerInfo:
public static PeerInfo getPeerInfo()
{
return singleton;
}
...
VersionInfo versioninfo = VersionInfo.theOne();
singleton = new PeerInfo(versioninfo.getMajor(), versioninfo.getMinor(), versioninfo.getServicePack(), versioninfo.getRollingPatch(), versioninfo.hasTemporaryPatch(), versioninfo.getPackages());
------------------------------------------
VersionInfo:
public static VersionInfo theOne()
{
return Maker.THE_ONE;
}
...
public final int getServicePack()
{
return servicePack;
}
...
public VersionInfo(boolean flag) throws VersioningError
{
...
packages = getLocalWLPackages();
...
implVendor = packages[0].getImplementationVendor();
implTitle = packages[0].getImplementationTitle();
implVersion = packages[0].getImplementationVersion();
major = packages[0].getMajor();
minor = packages[0].getMinor();
servicePack = packages[0].getServicePack();
...
}
------------------------------------------
Maker:
static final VersionInfo THE_ONE = VersionInfo.access$000() ? new VersionInfo(true) : new VersionInfo(9, 2, 1, 0);
------------------------------------------
There are another constructors in the VersionInfo class but it is clear that for some reason in case of my web application constructor VersionInfo(true) was invoked in runtime.
So as you can see WebLogic gets its version information from ... manifest of the Jar file that placed first in the CLASSPATH!!!! As you remember first Jar file is my patche's Jar with:
Implementation-Version: 9.2
It does not contain version of SP. So WebLogic after patch of AquaLogic does not know about its SP version!
Now I can change order of my Jar in the server CLASSPATH or ... change line:
Implementation-Version: 9.2
to
Implementation-Version: 9.2.1
{
return servicePack;
}
...
public VersionInfo(boolean flag) throws VersioningError
{
...
packages = getLocalWLPackages();
...
implVendor = packages[0].getImplementationVendor();
implTitle = packages[0].getImplementationTitle();
implVersion = packages[0].getImplementationVersion();
major = packages[0].getMajor();
minor = packages[0].getMinor();
servicePack = packages[0].getServicePack();
...
}
------------------------------------------
Maker:
static final VersionInfo THE_ONE = VersionInfo.access$000() ? new VersionInfo(true) : new VersionInfo(9, 2, 1, 0);
------------------------------------------
There are another constructors in the VersionInfo class but it is clear that for some reason in case of my web application constructor VersionInfo(true) was invoked in runtime.
So as you can see WebLogic gets its version information from ... manifest of the Jar file that placed first in the CLASSPATH!!!! As you remember first Jar file is my patche's Jar with:
Implementation-Version: 9.2
It does not contain version of SP. So WebLogic after patch of AquaLogic does not know about its SP version!
Now I can change order of my Jar in the server CLASSPATH or ... change line:
Implementation-Version: 9.2
to
Implementation-Version: 9.2.1
Both cases are work. I have tested.
The engineer form BEA support said me about those code:
"Well yes, that's true, but you see that the problem is coming from the patch that you install the first time, I guess if the patch was the correct one of the WLS installation , every thing will work fine, but since the patch was not well installed let say, it's logic that nothing will work, for me."
Nevertheless I have one question: why BEA WebLogic AS that able to do anything (almost anything) and costs so much money retrieve version info about itself by using logic:
...
packages = getLocalWLPackages(); //All WebLogic AquaLogic packages in CP
servicePack = packages[0].getServicePack(); //First off all
...
It seems like Titanic 9.2 is the ship until it have gotten some screws from submarine. Just it happens the same time it considered whole itself as submarine :). There is no reason to explain result of that misunderstanding. LOL.
No comments:
Post a Comment