aspose file tools*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes What consequences if EJB doesn't comply to programming restrictions (Mikalai Zaikin's document) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "What consequences if EJB doesn Watch "What consequences if EJB doesn New topic
Author

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

Jan van Mansum
Ranch Hand

Joined: Oct 19, 2007
Posts: 74
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.


SCJP 1.4, SCWCD 1.4
Raf Szczypiorski
Ranch Hand

Joined: Aug 21, 2008
Posts: 383
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

Joined: Oct 19, 2007
Posts: 74
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: What consequences if EJB doesn't comply to programming restrictions (Mikalai Zaikin's document)