• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • paul wheaton
  • Ron McLeod
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:

Classpath problems

 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
after quite some time reading the forums and IBM's Websphere handbooks am I still confused about classloading in WAS 4.0 AE or probably with classloading of J2EE applications ...
We have the following problem after packing an EAR file with AAT for WAS 4.0.
A servlet from a war module has access to our EJB modules and classes from utiliy.jar and everything works fine. But the problem is that helper classes that are stored in the jar called utility.jar don't have access to these EJBs. This utility jar is also stored in the same ear file as the EJB modules and the war file.
Where do I specify that the classes from utility.jar have also access to the EJB classes from the EJB modules?
I'm assuming that this is maybe a manifest issue, but I just can't figure out where to specify the manifest entry of the utility.jar in AAT.
The only way I get the application running is when I put all the EJB jars from the EJB modules also on the classpath of the appserver, but that's really not what I wanna do, as I'm pretty sure that there must be a way to get the application configured within the ear file.
Am I right?

Any help is really appreciated.
Thanks in advance,
Michel
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,
according to my experience, there is no way to specify manifest entries inside AAT. The only way to add "Class-Path" entries in the manifest is to do it with a text editor.
I once had a similar problem to yours, and this solved it.
- Ville Peurala
 
Michael Laufer
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
do you remember what changes you've made with your texteditor?
Regards,
Michel
 
Ville A Peurala
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,
in the MANIFEST.MF of your utility jar add the following entry:
"Class-Path: <the directory where your EJB classes are, relative to the root of the EAR file>"
This is a straightforward way to make the utility classes "see" your EJB:s. But a better design would be to export the EJB home and remote interfaces to a separate jar file, place it in the EAR file's root directory and point the classpath of the utility jar to this new jar.
- Ville Peurala
 
Michael Laufer
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ville,
thanks for your help.
Short question, why do I have to only "export" the interfaces to an external jar.
I thought that I probably need also the deployed code for these EJBs within such a jar ant not only the interfaces.
Thanks in advance,
Michel
 
Ville A Peurala
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
it depends on what your utility classes do with the EJB:s. Normally all clients access EJB:s only through home and remote interfaces (and possibly local interfaces in EJB 2.0 spec), so nobody ever refers directly to the EJB implementation classes. The actual classes are accessed only by the EJB container.
But if your utility classes do some odd things with the EJB implementation classes, then you do need also them in the classpath. That would be a very uncommon situation, though.
It seems that my example classpath entry was chopped in my last message. It should have been "Class-Path:" and after that write the path from the root of your ear to your ejb classes.
Example: You have a class named com.somecompany.ejb.SimpleEjbBean. Its directory path is /someear.ear/someejbmodule/com/somecompany/ejb/SimpleEjbBean.class. So you should put "Class-Path: someejbmodule/" in the manifest, because paths begin in the ear's root level.
But I still recommend the jar-based solution which I explained in the beginning of this post. In fact, I think that it is wisest if the client classes never have the actual EJB implementation classes in their classpath.
T: Ville
 
reply
    Bookmark Topic Watch Topic
  • New Topic