tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henning <>
Subject Re: Hot to programmatically deploy ejb module
Date Thu, 24 Jun 2010 13:14:03 GMT
Hi David,

  thanks for that great pointer (I suppose there are more test cases
that could be interesting to look at). I would absolutely not mind
helping create a wrapper API. 

  It's hard to say what the bare minimum would be as there are so many
(useful) integration points with an EJB container. From a
deploy/undeploy perspective, it would be great to deploy by just passing
a class loader as the least common denominator. 

  Let me have a look and see how much I understand from the samples and
how far I can get.


The reason for using a custom class loader is that the actual classpath
is controlled by the environment. 

On Wed, 2010-06-23 at 15:12 -0700, David Blevins wrote:

> On Jun 21, 2010, at 3:45 AM, Henning Blohm wrote:
> > Hi all,
> > 
> >  we are playing with the idea of integration Open EJB as an EJB feature
> > into our low-life-cycle-management-efforts platform z2 Environment
> > ( To do so, we would need to programmatically
> > deploy EJB modules. I search the documentation and Javadocs but failed
> > to find an entry point to deployment.
> > 
> > So, if there is, can anybody point me to documentation on how to deploy
> > programmatically on OpenEJB?
> > 
> > Preferrably we would like to deploy from classpath, i.e. without
> > actually creating a jar. In contrast to the embedded examples however,
> > the module's class loader is not the one of the OpenEJB implementation
> > (but delegating to it). And of course, we wouldn't want to start
> > one EJB server for every module, but rather deploy several modules
> > to one server.
> > 
> > Any pointer to snippets/samples/documentation pointers useful to Open
> > EJB embedders (beyond testing) would be very welcome.
> Hi Henning!
> We do have various internal APIs for doing this kind of thing, but fair warning they
change frequently so don't make for good general purpose work.  Though, I really would like
to come up with a wrapper around some of these things.
> This is how we do things internally:
> Have a look around the various configure* methods of the ConfigurationFactory and various
create* methods of the Assembler.  Maybe we could use you as a use case for coming up with
a more generic API.  So in that regard, what would be the minimum you would need to get your
goals accomplished?
> -David

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message