• 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

What consequences if EJB doesn't comply to programming restrictions (Mikalai Zaikin's document)

 
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi group,

I am preparing for the SCBCD 5.0 using Zaikins document. Under "Identify correct and incorrect statements or examples about EJB programming restrictions" he specifies a lot of restrictions. My question is: what is the container supposed to do about it if the EJB doesn't comply? I'll give an example. I am writing OSGi plug-ins for a framework that uses OSGi embedded in an EJB that is deployed to JBoss AS. The only way I was able to solve certain class loader problems was by changing the context classloader to the current class loader at the start of my code and setting it back before my code returns. JBoss doesn't complain about it. I don't see how it could even detect it. Anyway, apparently I violated some JEE rule, but I am not totally convinced it is bad. The only thing that slightly worries me is that it might break in some other container than JBoss.

Thanks for any help,
regards,

Jan van Mansum.
 
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You pretty much answered yourself - you violated the specs, and even though one container didn't complain, others might. And they could even throw exceptions when you try to invoke the forbidden setContextClassLoader() if they are implemented that way. Jboss is also lenient for other rules, like bean classes being final and so on. The specs don't dictate any particular behavior, but you should expect the worse :-) Of course, if it works and you are 100% sure your beans will only be deployed on jboss, you are pretty safe. But can you be 100% sure?
 
Jan van Mansum
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Raf Szczypiorski wrote:And they could even throw exceptions when you try to invoke the forbidden setContextClassLoader() if they are implemented that way.



I was going to ask you how, but after a brief look at the Thread API, I can see that all they would have to do is set some security properties or override Thead.setContextClassLoader(). That leaves me in a fix. Some of the libraries that I call from my OSGi plug-in use the context class loader to load some of the classes they use. The context class loader is the one set by JBoss. On the other hand the class I need those libraries to load are in the OSGi-provided classloader (the current classloader at that time). Anyway, that's all a bit off-topic on this forum. I am now in the clear about this point for the exam. Thanks.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic