Hi, I was trying to run the AdviceBean Application from Head First EJB on weblogic server. I used Jbuilder to create the EJBs and deployed it on weblogic. I then wrote the client and tried to run it. I am getting the noinitialcontextException. javax.naming.NoInitialContextException: Need to specify class name in environmen t or system property, or as an applet parameter, or in an application resource f ile: java.naming.factory.initial at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:6 43) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:246 ) at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.jav a:283) at javax.naming.InitialContext.lookup(InitialContext.java:350) at AdviceClient.go(AdviceClient.java:20) at AdviceClient.main(AdviceClient.java:10) I was looking for ways to resolve this . Also I was trying to create a client.jar in weblogic the way HF showed using suns deploy tool. If anyone can help me out, it would be great. Thanks in advance, Chet
Howdy -- the issue with clients is that they are *not* necessarily portable because the InitialContext() properties will be different for each app server. Unless... you use the no-arg constructor and supply the propererties through a jndi properties file that has the right stuff in it. I don't know web logic enough to know what you need to include in your properties. Remember, the InitialContext has to connect you to the JNDI naming server where your Container has bound the home object. So, the InitialContext has to know at least two things: 1) Which "driver" class is needed for that particular JNDI service 2) Where the service is! (URL, etc.) How you do this is different for each server, so I suggest that you ask around or look in the docs to see what's the easiest way to do this for your server, and what you need to say there. You can do it several ways: 1) Change the client code to put the correct JNDI properties into a Hashtable, and pass that to the overloaded InitialContext constructor that takes the Hashtable. OR 2) Put the properties into a JNDI properties file, which can be in many different locations. OR 3) Use command-line properties to override anything that might be in a JNDI properties file, and specify what you need there. Again, you'll have to find out exactly what is needed for your web logic server. But maybe *somebody* here will know? Otherwise, you might try the regular (non-cert) EJB forum. I know that people there are definitely using Web logic, in fact I think there are sometimes people from BEA in there! Good luck, Kathy
Cowgirl and Author
posted 16 years ago
Oh yeah, I forgot about your client jar question. Your server is *somehow* preparing a client jar for you -- or at the least, you can find out *where* it puts the classes you need. Remember, the client jar needs the stub classes! That's the main thing that has to go into the client jar. The client MUST have access to the j2ee.jar, of course, (where javax.ejb is, etc.) AND your interfaces, and the stub classes. So if you haven't even compiled the client yet, you can put the interface and the stub classes into a jar, and that's the client jar. cheers, kathy
Hi, the following code might help you connect to JNDI WL:
posted 16 years ago
Thanks Kathy and Dani, I got past that error by setting Properties props = new java.util.Properties(); props.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory"); props.put(Context.PROVIDER_URL, "t3://localhost:7001");
But after that I get a new error, Exception in thread "main" java.lang.NoClassDefFoundError: javax/security/auth/c allback/CallbackHandler at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:120) at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialCont extFactory.java:131) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:6 65) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:246 ) at javax.naming.InitialContext.init(InitialContext.java:222) at javax.naming.InitialContext.<init>(InitialContext.java:198) at TheClient.getWLInitialContext(TheClient.java:58) at TheClient.go(TheClient.java:19) at TheClient.main(TheClient.java:11) and i am stuck again.
Originally posted by Kathy Sierra: Oh yeah, I forgot about your client jar question. Your server is *somehow* preparing a client jar for you -- or at the least, you can find out *where* it puts the classes you need. Remember, the client jar needs the stub classes! That's the main thing that has to go into the client jar. The client MUST have access to the j2ee.jar, of course, (where javax.ejb is, etc.) AND your interfaces, and the stub classes. So if you haven't even compiled the client yet, you can put the interface and the stub classes into a jar, and that's the client jar. cheers, kathy
As far as I know (in fact I do have a sample working application that I keep tweaking for learning purposes), stubs are not needed in the client's jar. At least when your app server is WebLogic. I have a web application that I run in Tomcat. It uses the EJBs in WebLogic and I have only two jars in my WEB-INF\lib : wlclient.jar (which is Weblogic stuff) and a client.jar that only has EJB interfaces. No stubs. I believe that the stubs are automatically marshalled by weblogic over to the client when i do lookup.
posted 16 years ago
Hi, Did you put the jar that contains the weblogic.jndi.WLInitialContextFactory class in the classpath? You must do it. I don't remember right now the name of the jar, but you can find it in the WL directory. Dani Mazzuca
posted 16 years ago
Hi Thanks for the replies. Finally got it working. it was a problem with the classpaths and version of J2EE. it was using the beta version of j2ee which had problems with weblogic 8.1. i was getting an unsupported error. so i uninstalled everything and started fresh. with j2ee 1.3. and it works fine now. The file needed to be added to the classpath is weblogic.jar Thanks, Chet
I once met a man from Nantucket. He had a tiny ad
Devious Experiments for a Truly Passive Greenhouse!