This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes EJB and other Java EE Technologies and the fly likes the bean and the classloader Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "the bean and the classloader" Watch "the bean and the classloader" New topic
Author

the bean and the classloader

Ryan Fernandes
Ranch Hand

Joined: Dec 11, 2003
Posts: 86
Hi y'all,
Was planning to use Hibernate [hibernate.org] from within a session bean. Now Hibernate uses a lot of reflection & classloading and everyone knows what the spec. says:
The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams.

Maybe I'm reading/interpreting the spec wrongly....I'm not sure.
However, my question is, would it be safe to use Hibernate within an EJB without breaking the spec. rule ? [just because it works on some app servers doesnt mean that the code will be portable.... and we all want to write portable code ]
Cheers,
Ryan
[ April 06, 2004: Message edited by: Ryan Fernandes ]

Unthinking respect for authority is the greatest enemy of truth. -Albert Einstein, physicist, Nobel laureate (1879-1955)
eammon bannon
Ranch Hand

Joined: Mar 16, 2004
Posts: 140
Hibernate works fine with Session Beans. You probably want to access the Hibernate objects through a DAO layer, but otherwise crack on.
Kishore Dandu
Ranch Hand

Joined: Jul 10, 2001
Posts: 1934
May be I am wrong.
I have a feeling that if you want to create Hibernate compliant application you don't need to use EJBs(the intent is to get rid of EJB related complexity)
As I said, I am not good at using Hibernate. So, some other expert may give better opinion.


Kishore
SCJP, blog
eammon bannon
Ranch Hand

Joined: Mar 16, 2004
Posts: 140
You don't have to thats true Kishore; the intent is really to simplify current ORM frameworks. But if you still need say a sesion or message facade, you are perfectly free to use Hibernate with these - hibernate doesn't offer any of the container services EJB's do.
Kishore Dandu
Ranch Hand

Joined: Jul 10, 2001
Posts: 1934
But, what is the fuss about "J2EE without EJB" lately.
May be Hibernate has alternative mechanism for transaction processing etc.
I am ignorant on this subject. Please enlighten me.
Ryan Fernandes
Ranch Hand

Joined: Dec 11, 2003
Posts: 86
Thanks Eammon!
I'm looking to employ Hibernate as an alternative to those pesky entity beans.
Usually, one uses a session facade to access the entities (from a DAO layer).
Using a session bean/MDB that calls DAOs realizes this approach.
What I really want to confirm is whether my EJBs will remain portable ?
(even if the class loader gets accessed within them by the hibernate framework; as the final caller to the hibernate framework is going to be the EJB)??

Kishore, you might want to check out hibernate.org to see what hibernate is really all about.

Cheers,
Ryan
eammon bannon
Ranch Hand

Joined: Mar 16, 2004
Posts: 140

But, what is the fuss about "J2EE without EJB" lately.

Its not Hibernate that's causing that. It does offer a much better ORM solution than Entity Beans (and therefore removes the requirement to use EJBs to access the ORM layer, and indeed a container to run things in). So it is one of the tools which helps achieve J2EE without EJB, but not the reason on its own. An EJB container however offers much more than just an ORM mechanism.
I don't think Hibernate uses an alternative transaction mechanism - indeed as far as I remember, it provides convenience lookup classes for Transactions within all the big EJB containers i.e. its meant to run in conjuncion with not instead of these containers. But the primary difference is its only one layer of an application, specifically the data access layer - so if you are trying to do business transactions in this, then there is something wrong with your design.
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Yes, Hibernate can be used in the context of EJB. According to the strict letter of the law it may be breaking part of the programming restrictions in the specification but I don't see that as a big deal. Many people are successfully using Hibernate in EJB Applications and are very happy with the results... I am one of them.
Kishore, the main reason for using EJB on top of Hibernate is definitely transaction management... plus possibly security or remoting. Hibernate does not certain itself with transaction management... it just participates in transactional contexts.
An alternative to using EJB for managing transactions is to take a look at Spring. Spring offers declarative transactioning as part of its lightweight container services. Spring rocks! If there is interest I will write a JavaRanch article detailing how to use Spring in the context...
[ April 08, 2004: Message edited by: Chris Mathews ]
Ryan Fernandes
Ranch Hand

Joined: Dec 11, 2003
Posts: 86
Yes, Hibernate can be used in the context of EJB. According to the strict letter of the law it may be breaking part of the programming restrictions in the specification but I don't see that as a big deal. Many people are successfully using Hibernate in EJB Applications and are very happy with the results... I am one of them.

Thanks so much Chris. This is just what I wanted to confirm.
Cheers,
Ryan
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: the bean and the classloader
 
Similar Threads
EJB Classpath Query
Threading in ejb's
file handling through EJB
Thread in Stateless Session Bean
Programming restrictions of Bean Provider