[
http://opensource.atlassian.com/projects/hibernate/browse/EJB-219?page=co...
]
Emmanuel Bernard commented on EJB-219:
--------------------------------------
this was the initial implementation but the specification moved away from that model and
pushed the tx regtistration etc to the container rather than the provider.
I can't spend too much time in it, but this is something definitely doable. If you
want to work on that I can give you some guidance.
Alternatively you can get rid of the slow moving competitors ;-) or try and use the JBoss
Embeddable EJB3 inside your old ejb 2 container
Add an EntityManagerFactory.getCurrentEntityManager() method.
-------------------------------------------------------------
Key: EJB-219
URL:
http://opensource.atlassian.com/projects/hibernate/browse/EJB-219
Project: Hibernate Entity Manager
Type: New Feature
Components: EntityManager
Environment: Hibernate 3.2. Any/All.
Reporter: James Olsen
BACKGROUND
I'd like to code against the JPA standard, however my current EJB container vendor
(like many others) is only providing JPA support as part of their EJB3 rollout which is at
a very early stage.
JPA doesn't need a full EJB3 environment. The only required apsect that appears to
be missing in existing EJB containers is container management and injection of a correctly
scoped EntityManager. I can deal with the injection problem by having a Singleton
accessor for the EntityManagerFactory in much the same way as the well known HibernateUtil
deals with the SessionFactory. All that is left then is providing something similar to
the automatic JTA/CMT context scoping of Sessions for EntityManager instances.
SUGGESTION
I would propose that a new custom API be added to
org.hibernate.ejb.EntityManagerFactoryImpl in the form of a method called
getCurrentEntityManager(). Internally this would construct an EntityManagerImpl that was
configured to do sessionFactory.getCurrentSession() rather than
sessionFactory.openSession() (inside the getRawSession() method), thereby leveraging
Hibernates pre-existing capability to return correctly scoped units of work in a JTA/CMT
environment. Thats sounds easy, but maybe there's more to it!?
JUSTIFICATION
The advantage of having such an API is that we can write to the JPA API without waiting
for full EJB3 support in the container. The little bit of application code to obtain the
EntityManagerFactory, cast to the Hibernate impl and call this custom method can easily be
removed in the future when EntityManager injection is available.
I've looked at using Spring and Pitchfork but as great as they are, they are heavy
handed when you already have a container and my customer demands a container and also has
an aversion to non GA code (implies I'm confident the Hibernate 3.2 products will be
GA soon - which I am!).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira