Problem - Stateless session bean using local interfaces, Weblogic 7.0

[Prasanna Wamanacharya]

Hi,
I am getting foll. error message when trying to access a stateless session bean using local interfaces deployed in Weblogic 7.0.
------------------------------------------------
javax.naming.LinkException: . Root exception is javax.naming.NameNotFoundException: Unable to resolve 'app/ejb/TestEjbLocal.jar#TestEJBLocal/local-home' Resolved: 'app/ejb' Unresolved:'TestEjbLocal.jar#TestEJBLocal' ; remaining
name 'TestEjbLocal.jar#TestEJBLocal/local-home'
<<no stack trace available>>
------------------------------------------------
The EJB name is showing bound properly in the JNDI tree.
I am able to access an EJB using the remote interfaces without any problem.
There is one more difficulty I am facing. From a jsp file, I am using a java class to perform lookup and call a method in the EJB.
Even after deploying the EJB through the console, is it required that the individual .class files (Home, Remote, Implementation) be present in the WEB-INF classes folder. If I remove the classes, I get an error message saying that the required classes were not found.
Thanks in advance
Prasanna.

[Sai Prasad]

I haven't tried local interfaces yet. But I can comment on accessing EJBs from webapp.
What you are experiencing is the well known CLASSPATH issue and the classloaders loading various classes. If you can deploy the EJBs in jar file, the webapp classes can use the EJB using home,remote interfaces. There is no need to have the EJB implementation classes in webapp lib folder.

[Rama Raghavan]

To access using local interface, package ejb component and web component into an ear.
Class loader hierarcy has its role, but I never understood why this restriction even though it is from within the same jvm.
Experts ?

[Aaron Mulder]

It doesn't really matter what JVM something is in, it matters what class loader it was loaded from. In a typical J2SE app, everything is loaded from the system class loader, so those are pretty much equivalent. In J2EE apps, there are usually lots of class loaders kicking around.
It's actually desirable that different apps use different class loaders. One reason is that the only way to redeploy an app is to trash it's class loader and load the app again in a new CL. If all apps used the same CL, reloading one would force all the others to reload. Also, using different CLs lets different apps use different versions of the same class, or two different classes with the same name, etc. Plus, you probably don't want a malicious class in one app to be able to paw through the classes for another app. Or server classes, for that matter, which is why server classes are often in a CL off the beaten path for apps.
One key concept is that CLs are arranged in a tree, and a class in a CL can see classes in its parent CL (closer to the root/system/bootstrap class loader), but not in any child CLs.
Now, the WebLogic structure has a fairly reasonable class loader arrangement for classes in an EAR. The EJB CL is the parent of the web app CL. This means that classes in the web app can see classes in the EJB JARs, but not vice versa. In other words, a servlet or JSP can invoke an EJB, but an EJB cannot invoke a servlet. Also, since the web app and EJBs are in different CLs, you can reload the web app without needing to reload the EJBs.
When the JSPs and EJBs aren't in an EAR, the server assumes that they represent different applications, so they are compartmentalized and calls to local interfaces won't work.
Probably more than you wanted to know.

[Chris Mathews]

Originally posted by Aaron Mulder:
Now, the WebLogic structure has a fairly reasonable class loader arrangement for classes in an EAR. The EJB CL is the parent of the web app CL. This means that classes in the web app can see classes in the EJB JARs, but not vice versa. In other words, a servlet or JSP can invoke an EJB, but an EJB cannot invoke a servlet. Also, since the web app and EJBs are in different CLs, you can reload the web app without needing to reload the EJBs.

This also causes some headaches from a deployment standpoint since many times you have objects that are passed between the EJB Layer and the Web Layer. The class definitions for these objects must be in a place that is accessible to both the EJB CL and the Web CL.
The classes can't go in the web app since the EJB CL can't see them. In this case you are left with basically three options:
1) Put all shared classes on the WebLogic CLASSPATH.
2) Put all shared classes in each ejb-jar.
3) Put all shared classes in a jar in the ear and place a manifest dependency between each ejb-jar and the shared jar.
Option 1 is probably the simplest, however it prevents dynamic reloading of the shared classes.
Option 2 is fairly easy, however it requires all ejbs to be redeployed if a single shared class changes and offers room for error if all ejb-jars are not updated.
Option 3 is the recommended solution and is required behavior in J2EE 1.3. However, not all tools support the manifest entry so it may be a pain to configure automatic builds. For these purposes I highly recommend Apache Ant.
For more information see these two articles by Tyler Jewel:
EJB 2 and J2EE Packaging
EJB 2 and J2EE Packaging, Part II

[Rama Raghavan]

Besides -
I always thought local interfaces were introduced to increase performance not requiring to unmarshall/marshall and remove network overhead.
So when accessed from within the same server (jvm), I would have thought ejbs would be locally visible to all apps deployed (as separate wars) on that server, without having to be invoked via remote interface.

[Chris Mathews]

Originally posted by Rama Raghavan:
So when accessed from within the same server (jvm), I would have thought ejbs would be locally visible to all apps deployed (as separate wars) on that server, without having to be invoked via remote interface.

Local Ejbs may be called by all applications on the same WebLogic instance. However, the classes necessary for using those Local Ejbs still need to be accessible by the application's ClassLoader.

[Rama Raghavan]

the classes necessary for using those Local Ejbs still need to be accessible by the application's ClassLoader

If I jar up just the interfaces and say place it is each of the application wars (under WEB-INF/lib) then can I invoke that ejb using local interface?

[Aaron Mulder]

Local Ejbs may be called by all applications on the same WebLogic instance.

While I'd have to do a little test to convince myself that this is true, I'm pretty sure it's at least not the intended behavior as far as the spec goes. Local interfaces are supposed to increase performance, but they're also supposed to be accessible only to other components of the same application. Again, the idea is that separate applications are separate, and for all intents and purposes might as well be running in a different server.
I would strongly recommend using the manifest class-path approach and putting all the stuff that needs to access the local beans in the same EAR, since the spec provides that feature for exactly that purpose, and WebLogic supports it (since 6.1, I think?).

[Chris Mathews]

Originally posted by Aaron Mulder:
While I'd have to do a little test to convince myself that this is true, I'm pretty sure it's at least not the intended behavior as far as the spec goes.

Actually neither the J2EE 1.3 Specification, nor the EJB 2.0 Specification specifically address this. Both just require the local ejb and client to be in the same JVM. That tells me that packaging and deployment is not an issue.
Like you, I would need to try this myself to be absolutely sure. In general, all of the local ejbs should be packaged in the ear and only accessed by other components in that ear. If an external(to the ear) war needs to access those same local ejbs than that is a red flag suggesting the external war should probably be part of the ear.
Then again... maybe I am just interpreting the specs wrong.
[ February 27, 2003: Message edited by: Chris Mathews ]

[Rama Raghavan]

Like you, I would need to try this myself to be absolutely sure.

In my experience, Local Interfaces work from war components only when packaged within the same ear.

Actually neither the J2EE 1.3 Specification, nor the EJB 2.0 Specification specifically address this. Both just require the local ejb and client to be in the same JVM.

This is exactly my point (of confusion).
If I have an ejb, Authentication bean, packaged as say auth.jar, would it be possible to invoke this as a local object from 10 web apps (wars) deployed on that single weblogic instance.
It is obvious that these 10 wars cannot become part of one single ear 'cos they are separate apps, but I want to be able to use the auth bean effecienly enough

[Aaron Mulder]

Actually neither the J2EE 1.3 Specification, nor the EJB 2.0 Specification specifically address this. Both just require the local ejb and client to be in the same JVM. That tells me that packaging and deployment is not an issue.

Yeah, looking back, it seems to be just CMR that actually requires entities to be in the same EJB JAR. I guess I'm confused about how you could get local interfaces to work properly across apps when the apps are loaded in different class loaders. I would think the interfaces and parameter/return classes would need to be included on the server classpath to make this work right. Otherwise, a "foo" from one app would need to be serialized and deserialized in order to become a "foo" from the other app. Of course, this would have other side effects, like defeating redeployment of those classes...

[Prasanna Wamanacharya]

Thank you all for helping me out. I managed to package the jsp and client bean into a war, and put it along with the ejb jar into an ear. It works for both local and remote interfaces.
It is really a pain if one is building an app. using local interfaces as everytime some change is made, the ear has to be rebuilt. I am spending some time now to learn Ant which I guess will speed up things.
Thanks again,
Prasanna.