tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: Multiple instances of OpenEJB - New strategy
Date Fri, 09 Oct 2009 05:40:07 GMT

On Oct 8, 2009, at 2:11 AM, Andy Gumbrecht wrote:

> However, I think that a better more lightweight option is to have  
> one OpenEJB embedded instance that provides access to EJBs that in  
> turn obtain EntityManagers from EntityManagerFactories bound to the  
> corresponding PU cache determined by the call context. I would  
> replace the @PersistenceUnit on EJBs with an @EJB helper to lookup  
> and provide the EMs to the EJBs.
> What I would really like to do is sew in a new named persistence  
> unit dynamically at any time 'after' start up of OpenEJB - including  
> the dynamic DataSources.
> This leads to the new question - Is it possible to directly access  
> OpenEJB (Assembler assembler =  
> SystemInstance.get().getComponent(Assembler.class);) and create or  
> define a new PU on the fly? - Using appInfo.persistenceUnits.add()  
> for example. Is that safe?

If you wanted to tinker around in the low level internal code, yes,  
you can do some pretty crazy stuff dynamically :)  Be warned however  
we reserve the right to change them without notice.

So all disclaimers aside, if you really want to be naughty, this test  
case is a good (er, I mean, bad, very bad, shame on you for even  
looking) example of how things look internally when we deploy an app  
with a persistence unit:

In your situation you'd already have an Assembler there, so skip  
everything we do in the setUp() of the test case with one exception.   
You'll still need to create a 'new ConfigurationFactory();'

The other option is that we do support multicast discovery in the  
client and server.  Not sure how that might play into your goal, but  
might open some doors if you need the client to dynamically failover  
to another server.


View raw message