• 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:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

classloader question

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

I have one .ear file which contains a straight-forward Stateless Session Bean. I have a second .ear file that contains some JSP files. I have a ServiceLocator class(in 2nd .ear file) that is called by the JSP files in the 2nd .ear file which has the following code:



However, the call to the PortableRemoteObject.narrow method throws a
java.lang.ClassCastException. I've been reading many posts that explain the way the JBOSS classloaders work and how that it basically creates a "flat" classloader repository. I've also read that a class definition is only loaded once and the first classloader to load it wins. So, in my case I think the first .ear file, the one with the EJB and binding the object to JNDI has one classloader. The ServiceLocator is using a different classloader, which is causing this exception to occur.

So, my question is how can I get the ServiceLocator to use the same classloader that was used by the 1st .ear with the EJB?

thanks in advance

 
Ranch Hand
Posts: 365
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Assumming you are using 4.0.1 you should make the container J2EE compliant. It does not come that way initially but there are steps to make it compliant (4 in all). I believe 4.0 did come that way but cannot be sure. It's a real pain in the a$$ though.

I think it is always better to know exactly what you are getting and only a compliant container can give you that with regards to classloading.

If you insist on using the ULC then in theory you can put the thing anywhere and it should be visible....
 
reply
    Bookmark Topic Watch Topic
  • New Topic