Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
Jan van Mansum
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
  • 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.
 
Raf Szczypiorski
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
  • 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
  • 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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic