This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I'm working with this IBM java application called Extended Search (ES), which not many people appear to be using. I know that not many people will have used it, but my problem is more to do with JNDI and JREs - becoming desperate now as I have a deadline looming!
Anyway, I have to write a class that is loaded by Extended Search which does a JNDI lookup to an EJB running on a WAS server on the same machine.
ES runs on what looks like a cut-down version of the IBM JRE. Despite ES itself being an EJB client, my class, within the context of ES, does not have access to naming.jar and all the other libraries I need to set the intial context and make the JNDI call.
If I run my class outside of ES from eclipse, I can easily make the call. I have done versions that work with either the Sun JRE or the IBM JRE that comes with Eclipse.
In ES, I have attempted to copy in the jars I need as follows: - ecutils.jar - ibmorb.jar - j2ee.jar - lmproxy.jar - naming.jar - namingclient.jar - ras.jar - sas.jar - wsexception.jar - wssec.jar
I resolved all of the noclassdeffound errors I was getting on trying to make the JNDI lookup, but now it appears to be calling a method from an object in the ES cutdown JRE which does not exist:
An error occurred: com.ibm.CORBA.iiop.ORB: method createObjectURL(Ljava/lang/String Lcom/ibm/CORBA/iiop/ObjectURL; not found java.lang.NoSuchMethodError: com.ibm.CORBA.iiop.ORB: method createObjectURL(Ljava/lang/String Lcom/ibm/CORBA/iiop/ObjectURL; not found at com.ibm.ws.naming.util.WsnInitCtxFactory.parseIiopUrl(WsnInitCtxFactory.java:1731) at com.ibm.ws.naming.util.WsnInitCtxFactory.parseBootstrapURL(WsnInitCtxFactory.java:1475) at com.ibm.ws.naming.util.WsnInitCtxFactory.getInitialContextInternal(WsnInitCtxFactory.java:371) at com.ibm.ws.naming.util.WsnInitCtx.getContext(WsnInitCtx.java:102) at com.ibm.ws.naming.util.WsnInitCtx.getContextIfNull(WsnInitCtx.java:408) at com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:131) at javax.naming.InitialContext.lookup(InitialContext.java:360) at com.ibm.bts.es.srv.links.CHIPESLink.search(CHIPESLink.java:162)
This problem is driving me nuts. I find it hard to believe that its so difficult to make a call from one bloody IBM product to another, just because JNDI seems to require the entire WAS library dir to work.
Does anyone have any suggestions of how I can get round this? I have limited control over ES - and it won't even start up if I add the WAS lib dir to its classpath.
Well I would guess IBM should give you some support, failing that obvious point, what happens when you run ES in a standard JRE?
Drinking more tea is the key...
Joined: Jan 15, 2004
Thanks for your response - well, I haven't tried that yet - browsing the directory there seems to be a load of c libraries in the JRE which don't exist on the normal IBM jre. It seems to be really hacked about with, which just about sums up this particular ibm product.
I was wondering whether theres any way I can sidestep using the WAS service provider altogether - just downloaded the latest JNDI classes and providers from Sun, maybe theres a way I can get that working in the ES jre.
Joined: Jan 15, 2004
Ok, tried the new Sun JNDI jars (jndi.jar, cosnaming.jar) running in a standalone java class using the IBM JRE and it works.
However, as soon as I take it into Extended Search I get this error:
java.lang.NoSuchMethodError: org.omg.CosNaming._NamingContextStub: method _releaseReply(Lorg/omg/CORBA/portable/InputStream V not found at org.omg.CosNaming._NamingContextStub.resolve(_NamingContextStub.java:269) at com.sun.jndi.cosnaming.CNCtx.callResolve(CNCtx.java:488) at com.sun.jndi.cosnaming.CNCtx.lookup(CNCtx.java:540) at com.sun.jndi.cosnaming.CNCtx.lookup(CNCtx.java:518) at javax.naming.InitialContext.lookup(InitialContext.java:360) at com.ibm.bts.es.srv.links.CHIPESLink.search(CHIPESLink.java:161)
I'm giving up now and logging a call with IBM, god knows what they've done to the ES JRE but it doesn't behave like other JREs do.
Joined: Jun 30, 2004
Yeah that ES tool sounds a bit pony if it needs a botched JRE to work...
Hopefully the vast skill that the IBM callcentre have will solve your problem