You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@visi.com> on 2007/01/04 00:28:28 UTC
Dynamic Assembler?
So this kind of idea has been in my head for a while. Basically, the
idea is for an interactive assembler implementation which people
could call to add/remove containers, resources, and beans at
runtime. We'd also use it to support other services which could now
also do the same.
The classic assembler is a one-shot builder, it constructs everything
and it's job is done. What I'm imagining the Dynamic Assembler to be
is more of an API for people who want to make calls to build up and
add to the container system at runtime. It'd leverage the InfoObject
tree we have now to allow people to do things like:
addContainer(ContainerInfo info)
addEjbJar(EjbJarInfo info)
addResource(ResourceInfo info)
There would be equivalent methods for removing any of the above. We
might even have equivalent overloaded versions that might look like
this:
addContainer(String id, Class impl, String type, Properties
containerProps)
addEjbJar(org.apache.openejb.EjbJar ejbJar)
addEjbJar(URL jarLocation)
addResource(URL jdbcUrl)
Not a completely flushed out idea, just kind of brain storming and
looking for feedback.
-David
Re: Dynamic Assembler
Posted by David Blevins <da...@visi.com>.
On Jan 5, 2007, at 10:15 AM, Alan D. Cabrera wrote:
>
> On Jan 4, 2007, at 9:12 AM, Dain Sundstrom wrote:
>
>> On Jan 3, 2007, at 9:40 PM, David Blevins wrote:
>>
>>> On Jan 3, 2007, at 8:54 PM, Dain Sundstrom wrote:
>>>
>>>> BTW would there be methods to add and remove ServerServices?
>>>
>>> I guess we could do that, but that code is in a completely
>>> different package not seen by openejb-core at compile time so the
>>> actual "how" would have to be clever. Maybe we simply offer a
>>> similar interface in the openejb-server module and make the
>>> Finder approach simply one way to add ServerServices.
>>
>> That sounds cool. It will also help newbies catch on to how
>> OpenEJB has completely decoupled protocol specific code from the
>> general container code.
>
> That does sound cool.
Heads up. Working on this part now. i.e. ServerService add/remove
(at least add in the short term)
-David
Re: Dynamic Assembler?
Posted by David Blevins <da...@visi.com>.
On Jan 5, 2007, at 10:15 AM, Alan D. Cabrera wrote:
>
> On Jan 4, 2007, at 9:12 AM, Dain Sundstrom wrote:
>
>> On Jan 3, 2007, at 9:40 PM, David Blevins wrote:
>>
>>> On Jan 3, 2007, at 8:54 PM, Dain Sundstrom wrote:
>>>
>>>> BTW would there be methods to add and remove ServerServices?
>>>
>>> I guess we could do that, but that code is in a completely
>>> different package not seen by openejb-core at compile time so the
>>> actual "how" would have to be clever. Maybe we simply offer a
>>> similar interface in the openejb-server module and make the
>>> Finder approach simply one way to add ServerServices.
>>
>> That sounds cool. It will also help newbies catch on to how
>> OpenEJB has completely decoupled protocol specific code from the
>> general container code.
>
> That does sound cool. David, can you explain why this
> implementation would need to be "clever"?
Was saying we'd have to be clever if we wanted to put those methods
on the DynamicAssembler (it can't see any server classes), but if we
just create something similar in openejb-server, that might be easier.
-David
>
>
> Regards,
> Alan
>
>
Re: Dynamic Assembler?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jan 4, 2007, at 9:12 AM, Dain Sundstrom wrote:
> On Jan 3, 2007, at 9:40 PM, David Blevins wrote:
>
>> On Jan 3, 2007, at 8:54 PM, Dain Sundstrom wrote:
>>
>>> BTW would there be methods to add and remove ServerServices?
>>
>> I guess we could do that, but that code is in a completely
>> different package not seen by openejb-core at compile time so the
>> actual "how" would have to be clever. Maybe we simply offer a
>> similar interface in the openejb-server module and make the Finder
>> approach simply one way to add ServerServices.
>
> That sounds cool. It will also help newbies catch on to how
> OpenEJB has completely decoupled protocol specific code from the
> general container code.
That does sound cool. David, can you explain why this implementation
would need to be "clever"?
Regards,
Alan
Re: Dynamic Assembler?
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 1/5/07, Dain Sundstrom <da...@iq80.com> wrote:
> We could just add a class loader flag to every method and then all it
> to be null. If null we could default to the TCCL.
I'd rather prefer having two disctict methods with and without
classLoader as a input parameter. The ones without a classLoader param
would delegate to the ones that have. I think it'd be much clearer.
Being forced to do if (classLoader == null) is weird to me, but since
it's just a programming style I can live with/get used to both.
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Dynamic Assembler?
Posted by Dain Sundstrom <da...@iq80.com>.
On Jan 5, 2007, at 9:57 AM, David Blevins wrote:
> On Jan 5, 2007, at 9:28 AM, Dain Sundstrom wrote:
>
>> On Jan 4, 2007, at 8:02 PM, David Blevins wrote:
>>
>>> On Jan 4, 2007, at 11:05 AM, Dain Sundstrom wrote:
>>>
>>>> I'm starting on the Geronimo integration with OpenEJB 3 today,
>>>> and I think this Push model is exactly what I'm going to need.
>>>> If you stub out this interface soon, I'll be able to provide
>>>> feedback as I stub out the Geronimo integration.
>>>
>>> I checked in an initial version of the required classes. Let me
>>> know if this is close to what you need.
>>
>> I think I'm going to need versions of these methods that take a
>> class loader. What you have stubbed out will work well for a
>> standalone-embedded system, where OpenEJB is in charge of creating
>> the entire application. When OpenEJB is embedded into a JEE
>> server like Geronimo, the JEE container will be in charge of ear
>> deployment, and will be delegating the ejb modules to OpenEJB.
>> This means that the JEE server is responsible for creating the ear
>> class loader which contains the jars for all ejb, rar, and
>> persistence modules. Then when the ejb module is deployed into
>> Geronimo the class loader already exists. I'm thinking of
>> something like this:
>>
>> void addEjbJar(EjbJarInfo info, ClassLoader classLoader)
>> throws OpenEJBException;
>
> Ok, that's there for the methods that take a DeploymentModule,
> will add something similar for the Info object ones.
We could just add a class loader flag to every method and then all it
to be null. If null we could default to the TCCL.
-dain
Re: Dynamic Assembler?
Posted by David Blevins <da...@visi.com>.
On Jan 5, 2007, at 9:28 AM, Dain Sundstrom wrote:
> On Jan 4, 2007, at 8:02 PM, David Blevins wrote:
>
>> On Jan 4, 2007, at 11:05 AM, Dain Sundstrom wrote:
>>
>>> I'm starting on the Geronimo integration with OpenEJB 3 today,
>>> and I think this Push model is exactly what I'm going to need.
>>> If you stub out this interface soon, I'll be able to provide
>>> feedback as I stub out the Geronimo integration.
>>
>> I checked in an initial version of the required classes. Let me
>> know if this is close to what you need.
>
> I think I'm going to need versions of these methods that take a
> class loader. What you have stubbed out will work well for a
> standalone-embedded system, where OpenEJB is in charge of creating
> the entire application. When OpenEJB is embedded into a JEE server
> like Geronimo, the JEE container will be in charge of ear
> deployment, and will be delegating the ejb modules to OpenEJB.
> This means that the JEE server is responsible for creating the ear
> class loader which contains the jars for all ejb, rar, and
> persistence modules. Then when the ejb module is deployed into
> Geronimo the class loader already exists. I'm thinking of
> something like this:
>
> void addEjbJar(EjbJarInfo info, ClassLoader classLoader) throws
> OpenEJBException;
Ok, that's there for the methods that take a DeploymentModule, will
add something similar for the Info object ones.
-David
>
>
> -dain
>
Re: Dynamic Assembler?
Posted by Dain Sundstrom <da...@iq80.com>.
On Jan 4, 2007, at 8:02 PM, David Blevins wrote:
> On Jan 4, 2007, at 11:05 AM, Dain Sundstrom wrote:
>
>> I'm starting on the Geronimo integration with OpenEJB 3 today, and
>> I think this Push model is exactly what I'm going to need. If you
>> stub out this interface soon, I'll be able to provide feedback as
>> I stub out the Geronimo integration.
>
> I checked in an initial version of the required classes. Let me
> know if this is close to what you need.
I think I'm going to need versions of these methods that take a class
loader. What you have stubbed out will work well for a standalone-
embedded system, where OpenEJB is in charge of creating the entire
application. When OpenEJB is embedded into a JEE server like
Geronimo, the JEE container will be in charge of ear deployment, and
will be delegating the ejb modules to OpenEJB. This means that the
JEE server is responsible for creating the ear class loader which
contains the jars for all ejb, rar, and persistence modules. Then
when the ejb module is deployed into Geronimo the class loader
already exists. I'm thinking of something like this:
void addEjbJar(EjbJarInfo info, ClassLoader classLoader) throws
OpenEJBException;
-dain
Re: Dynamic Assembler?
Posted by David Blevins <da...@visi.com>.
On Jan 4, 2007, at 11:05 AM, Dain Sundstrom wrote:
> I'm starting on the Geronimo integration with OpenEJB 3 today, and
> I think this Push model is exactly what I'm going to need. If you
> stub out this interface soon, I'll be able to provide feedback as I
> stub out the Geronimo integration.
I checked in an initial version of the required classes. Let me know
if this is close to what you need.
-David
>
> -dain
>
> On Jan 4, 2007, at 9:12 AM, Dain Sundstrom wrote:
>
>> On Jan 3, 2007, at 9:40 PM, David Blevins wrote:
>>
>>> On Jan 3, 2007, at 8:54 PM, Dain Sundstrom wrote:
>>>
>>>> I like this. It would make *deep* embedding much easier if
>>>> there where a single object to start with that encapsulated the
>>>> details of the Assembler and ContainerSystem.
>>>
>>> Yea, if you read all of this thread where I propose the
>>> properties stuff[1] to Vincent who was doing a Cactus
>>> integration, the ultimate feeling from him was that he would
>>> prefer a more Jetty-like approach where he could simply "build"
>>> things himself.
>>>
>>> I guess I would describe this assembler as more of a "push"
>>> approach rather than a "pull" approach that we have now in the
>>> classic assembler. Push == you construct and call us, Pull ==
>>> we'll construct and call you. I.e. with a Pull you have to
>>> implement an interface that we consume to pull our data out. Not
>>> ideal for everyone.
>>
>> I like Push vs. Pull description.
>>
>>>> BTW would there be methods to add and remove ServerServices?
>>>
>>> I guess we could do that, but that code is in a completely
>>> different package not seen by openejb-core at compile time so the
>>> actual "how" would have to be clever. Maybe we simply offer a
>>> similar interface in the openejb-server module and make the
>>> Finder approach simply one way to add ServerServices.
>>
>> That sounds cool. It will also help newbies catch on to how
>> OpenEJB has completely decoupled protocol specific code from the
>> general container code.
>>
>> -dain
>
Re: Dynamic Assembler?
Posted by Dain Sundstrom <da...@iq80.com>.
I'm starting on the Geronimo integration with OpenEJB 3 today, and I
think this Push model is exactly what I'm going to need. If you stub
out this interface soon, I'll be able to provide feedback as I stub
out the Geronimo integration.
-dain
On Jan 4, 2007, at 9:12 AM, Dain Sundstrom wrote:
> On Jan 3, 2007, at 9:40 PM, David Blevins wrote:
>
>> On Jan 3, 2007, at 8:54 PM, Dain Sundstrom wrote:
>>
>>> I like this. It would make *deep* embedding much easier if there
>>> where a single object to start with that encapsulated the details
>>> of the Assembler and ContainerSystem.
>>
>> Yea, if you read all of this thread where I propose the properties
>> stuff[1] to Vincent who was doing a Cactus integration, the
>> ultimate feeling from him was that he would prefer a more Jetty-
>> like approach where he could simply "build" things himself.
>>
>> I guess I would describe this assembler as more of a "push"
>> approach rather than a "pull" approach that we have now in the
>> classic assembler. Push == you construct and call us, Pull ==
>> we'll construct and call you. I.e. with a Pull you have to
>> implement an interface that we consume to pull our data out. Not
>> ideal for everyone.
>
> I like Push vs. Pull description.
>
>>> BTW would there be methods to add and remove ServerServices?
>>
>> I guess we could do that, but that code is in a completely
>> different package not seen by openejb-core at compile time so the
>> actual "how" would have to be clever. Maybe we simply offer a
>> similar interface in the openejb-server module and make the Finder
>> approach simply one way to add ServerServices.
>
> That sounds cool. It will also help newbies catch on to how
> OpenEJB has completely decoupled protocol specific code from the
> general container code.
>
> -dain
Re: Dynamic Assembler?
Posted by Dain Sundstrom <da...@iq80.com>.
On Jan 3, 2007, at 9:40 PM, David Blevins wrote:
> On Jan 3, 2007, at 8:54 PM, Dain Sundstrom wrote:
>
>> I like this. It would make *deep* embedding much easier if there
>> where a single object to start with that encapsulated the details
>> of the Assembler and ContainerSystem.
>
> Yea, if you read all of this thread where I propose the properties
> stuff[1] to Vincent who was doing a Cactus integration, the
> ultimate feeling from him was that he would prefer a more Jetty-
> like approach where he could simply "build" things himself.
>
> I guess I would describe this assembler as more of a "push"
> approach rather than a "pull" approach that we have now in the
> classic assembler. Push == you construct and call us, Pull ==
> we'll construct and call you. I.e. with a Pull you have to
> implement an interface that we consume to pull our data out. Not
> ideal for everyone.
I like Push vs. Pull description.
>> BTW would there be methods to add and remove ServerServices?
>
> I guess we could do that, but that code is in a completely
> different package not seen by openejb-core at compile time so the
> actual "how" would have to be clever. Maybe we simply offer a
> similar interface in the openejb-server module and make the Finder
> approach simply one way to add ServerServices.
That sounds cool. It will also help newbies catch on to how OpenEJB
has completely decoupled protocol specific code from the general
container code.
-dain
Re: Dynamic Assembler?
Posted by David Blevins <da...@visi.com>.
On Jan 5, 2007, at 10:10 AM, Alan D. Cabrera wrote:
>
> On Jan 3, 2007, at 9:40 PM, David Blevins wrote:
>
>> On Jan 3, 2007, at 8:54 PM, Dain Sundstrom wrote:
>>
>>> I like this. It would make *deep* embedding much easier if there
>>> where a single object to start with that encapsulated the details
>>> of the Assembler and ContainerSystem.
>>
>> Yea, if you read all of this thread where I propose the properties
>> stuff[1] to Vincent who was doing a Cactus integration, the
>> ultimate feeling from him was that he would prefer a more Jetty-
>> like approach where he could simply "build" things himself.
>>
>> I guess I would describe this assembler as more of a "push"
>> approach rather than a "pull" approach that we have now in the
>> classic assembler. Push == you construct and call us, Pull ==
>> we'll construct and call you. I.e. with a Pull you have to
>> implement an interface that we consume to pull our data out. Not
>> ideal for everyone.
>
> I personally prefer the push approach with the OpenEJB project
> providing a default assembler.
Starting to like that too. I like the addContainer, addEjbJar, type
methods etc. What do you like about it? (curious)
-David
Re: Dynamic Assembler?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jan 3, 2007, at 9:40 PM, David Blevins wrote:
> On Jan 3, 2007, at 8:54 PM, Dain Sundstrom wrote:
>
>> I like this. It would make *deep* embedding much easier if there
>> where a single object to start with that encapsulated the details
>> of the Assembler and ContainerSystem.
>
> Yea, if you read all of this thread where I propose the properties
> stuff[1] to Vincent who was doing a Cactus integration, the
> ultimate feeling from him was that he would prefer a more Jetty-
> like approach where he could simply "build" things himself.
>
> I guess I would describe this assembler as more of a "push"
> approach rather than a "pull" approach that we have now in the
> classic assembler. Push == you construct and call us, Pull ==
> we'll construct and call you. I.e. with a Pull you have to
> implement an interface that we consume to pull our data out. Not
> ideal for everyone.
I personally prefer the push approach with the OpenEJB project
providing a default assembler.
Regards,
Alan
Re: Dynamic Assembler?
Posted by David Blevins <da...@visi.com>.
On Jan 3, 2007, at 8:54 PM, Dain Sundstrom wrote:
> I like this. It would make *deep* embedding much easier if there
> where a single object to start with that encapsulated the details
> of the Assembler and ContainerSystem.
Yea, if you read all of this thread where I propose the properties
stuff[1] to Vincent who was doing a Cactus integration, the ultimate
feeling from him was that he would prefer a more Jetty-like approach
where he could simply "build" things himself.
I guess I would describe this assembler as more of a "push" approach
rather than a "pull" approach that we have now in the classic
assembler. Push == you construct and call us, Pull == we'll
construct and call you. I.e. with a Pull you have to implement an
interface that we consume to pull our data out. Not ideal for everyone.
>
> BTW would there be methods to add and remove ServerServices?
I guess we could do that, but that code is in a completely different
package not seen by openejb-core at compile time so the actual "how"
would have to be clever. Maybe we simply offer a similar interface
in the openejb-server module and make the Finder approach simply one
way to add ServerServices.
-David
[1] http://www.mail-archive.com/dev@openejb.org/msg00171.html
>
> -dain
>
> On Jan 3, 2007, at 3:28 PM, David Blevins wrote:
>
>> So this kind of idea has been in my head for a while. Basically,
>> the idea is for an interactive assembler implementation which
>> people could call to add/remove containers, resources, and beans
>> at runtime. We'd also use it to support other services which
>> could now also do the same.
>>
>> The classic assembler is a one-shot builder, it constructs
>> everything and it's job is done. What I'm imagining the Dynamic
>> Assembler to be is more of an API for people who want to make
>> calls to build up and add to the container system at runtime.
>> It'd leverage the InfoObject tree we have now to allow people to
>> do things like:
>>
>> addContainer(ContainerInfo info)
>> addEjbJar(EjbJarInfo info)
>> addResource(ResourceInfo info)
>>
>> There would be equivalent methods for removing any of the above.
>> We might even have equivalent overloaded versions that might look
>> like this:
>>
>> addContainer(String id, Class impl, String type, Properties
>> containerProps)
>> addEjbJar(org.apache.openejb.EjbJar ejbJar)
>> addEjbJar(URL jarLocation)
>> addResource(URL jdbcUrl)
>>
>> Not a completely flushed out idea, just kind of brain storming and
>> looking for feedback.
>>
>> -David
>
Re: Dynamic Assembler?
Posted by Dain Sundstrom <da...@iq80.com>.
I like this. It would make *deep* embedding much easier if there
where a single object to start with that encapsulated the details of
the Assembler and ContainerSystem.
BTW would there be methods to add and remove ServerServices?
-dain
On Jan 3, 2007, at 3:28 PM, David Blevins wrote:
> So this kind of idea has been in my head for a while. Basically,
> the idea is for an interactive assembler implementation which
> people could call to add/remove containers, resources, and beans at
> runtime. We'd also use it to support other services which could
> now also do the same.
>
> The classic assembler is a one-shot builder, it constructs
> everything and it's job is done. What I'm imagining the Dynamic
> Assembler to be is more of an API for people who want to make calls
> to build up and add to the container system at runtime. It'd
> leverage the InfoObject tree we have now to allow people to do
> things like:
>
> addContainer(ContainerInfo info)
> addEjbJar(EjbJarInfo info)
> addResource(ResourceInfo info)
>
> There would be equivalent methods for removing any of the above.
> We might even have equivalent overloaded versions that might look
> like this:
>
> addContainer(String id, Class impl, String type, Properties
> containerProps)
> addEjbJar(org.apache.openejb.EjbJar ejbJar)
> addEjbJar(URL jarLocation)
> addResource(URL jdbcUrl)
>
> Not a completely flushed out idea, just kind of brain storming and
> looking for feedback.
>
> -David
Re: Dynamic Assembler?
Posted by David Blevins <da...@visi.com>.
On Jan 6, 2007, at 4:56 PM, David Blevins wrote:
> So I'm hacking away on the ConfigFactory around where it creates
> Connector, TransactionManager, SecurityService, etc... I just have
> to say, boy is this code ugly. I seemed to remember it being a lot
> nicer when I wrote it in SlickEdit back in 2001 :) But man...sure
> is fun to refactoring it with Intellij.
>
> I swear, refactoring your old code is like programmer crack.
>
Yay. I just hacked 141 lines out of ConfigurationFactory.java. Best
part is I didn't just put them somewhere else :)
-David
Re: Dynamic Assembler?
Posted by David Blevins <da...@visi.com>.
So I'm hacking away on the ConfigFactory around where it creates
Connector, TransactionManager, SecurityService, etc... I just have to
say, boy is this code ugly. I seemed to remember it being a lot
nicer when I wrote it in SlickEdit back in 2001 :) But man...sure is
fun to refactoring it with Intellij.
I swear, refactoring your old code is like programmer crack.
-David
On Jan 3, 2007, at 3:28 PM, David Blevins wrote:
> So this kind of idea has been in my head for a while. Basically,
> the idea is for an interactive assembler implementation which
> people could call to add/remove containers, resources, and beans at
> runtime. We'd also use it to support other services which could
> now also do the same.
>
> The classic assembler is a one-shot builder, it constructs
> everything and it's job is done. What I'm imagining the Dynamic
> Assembler to be is more of an API for people who want to make calls
> to build up and add to the container system at runtime. It'd
> leverage the InfoObject tree we have now to allow people to do
> things like:
>
> addContainer(ContainerInfo info)
> addEjbJar(EjbJarInfo info)
> addResource(ResourceInfo info)
>
> There would be equivalent methods for removing any of the above.
> We might even have equivalent overloaded versions that might look
> like this:
>
> addContainer(String id, Class impl, String type, Properties
> containerProps)
> addEjbJar(org.apache.openejb.EjbJar ejbJar)
> addEjbJar(URL jarLocation)
> addResource(URL jdbcUrl)
>
> Not a completely flushed out idea, just kind of brain storming and
> looking for feedback.
>
> -David
>
Re: Dynamic Assembler
Posted by Dain Sundstrom <da...@iq80.com>.
On Jan 11, 2007, at 11:52 PM, David Blevins wrote:
> Ok.... Take a look at the heavily reworked Assembler class:
>
> http://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/
> container/openejb-core/src/main/java/org/apache/openejb/assembler/
> classic/Assembler.java
This is sweet! The code is very readable and I think anyone would be
confident helping to support it :)
-dain
Re: Dynamic Assembler
Posted by Dain Sundstrom <da...@iq80.com>.
On Jan 16, 2007, at 7:22 AM, David Blevins wrote:
> It'd be great to have a convenience class to smush this class and
> the Assembler class together, but we can make due for now.
I'm hacking on one of those as I work on the Geronimo integration.
Right now it is in G but I'll move it to openejb when I get it working.
-dain
Re: Dynamic Assembler
Posted by David Blevins <da...@visi.com>.
On Jan 11, 2007, at 11:52 PM, David Blevins wrote:
>
> On Jan 3, 2007, at 3:28 PM, David Blevins wrote:
>> addContainer(String id, Class impl, String type, Properties
>> containerProps)
>> addEjbJar(org.apache.openejb.EjbJar ejbJar)
>> addEjbJar(URL jarLocation)
>> addResource(URL jdbcUrl)
>
> The ConfigurationFactory is the class that will have these methods,
> there not quite there yet but we should be able to do a lot of
> damage with the combinations of these two things:
> ConfigurationFactory.createService
> EjbJarInfoBuilder.buildInfo
Ok. I think we're good enough on this. Here's what I wound up with
for public methods on ConfigurationFactory.
AppInfo configureApplication(File)
AppInfo configureApplication(AppModule)
EjbJarInfo configureApplication(EjbModule)
ClientInfo configureApplication(ClientModule)
ServiceInfo configureService(Class)
ServiceInfo configureService(Class, String, Properties, String, String)
That should be good enough to at least get a little farther. It'd be
great to have a convenience class to smush this class and the
Assembler class together, but we can make due for now.
Going to get some sleep and let Dain take his shift :)
Dain, if you run into something you need before I get up, just add it
and we'll figure it out later.
-David
Re: Dynamic Assembler
Posted by David Blevins <da...@visi.com>.
On Jan 3, 2007, at 3:28 PM, David Blevins wrote:
> So this kind of idea has been in my head for a while. Basically,
> the idea is for an interactive assembler implementation which
> people could call to add/remove containers, resources, and beans at
> runtime. We'd also use it to support other services which could
> now also do the same.
>
> The classic assembler is a one-shot builder, it constructs
> everything and it's job is done. What I'm imagining the Dynamic
> Assembler to be is more of an API for people who want to make calls
> to build up and add to the container system at runtime. It'd
> leverage the InfoObject tree we have now to allow people to do
> things like:
>
> addContainer(ContainerInfo info)
> addEjbJar(EjbJarInfo info)
> addResource(ResourceInfo info)
>
> There would be equivalent methods for removing any of the above.
> We might even have equivalent overloaded versions that might look
> like this:
>
Ok.... Take a look at the heavily reworked Assembler class:
http://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/
container/openejb-core/src/main/java/org/apache/openejb/assembler/
classic/Assembler.java
It should be good to go methods wise. I basically refactored the
classic assembler till it looked like the DynamicAssembler I had
envisioned. Partway there I was hoping we might come out the other
end with one assembler and wouldn't have to maintain two or throw
away one. That turned out to be the case, our classic assembler is
the dynamic assembler. We may want to rename the package, but
logically it performs every function the old assembler did so maybe not.
> addContainer(String id, Class impl, String type, Properties
> containerProps)
> addEjbJar(org.apache.openejb.EjbJar ejbJar)
> addEjbJar(URL jarLocation)
> addResource(URL jdbcUrl)
The ConfigurationFactory is the class that will have these methods,
there not quite there yet but we should be able to do a lot of damage
with the combinations of these two things:
ConfigurationFactory.createService
EjbJarInfoBuilder.buildInfo
Off to clean up the ConfigurationFactory ....
-David
Re: Kill spring assembler (was: Re: Dynamic Assembler?)
Posted by Dain Sundstrom <da...@iq80.com>.
Absolutely. Ever since you mentioned the dynamic assembler, I have
been planning on scrapping the current version and writing a new one.
-dain
On Jan 10, 2007, at 3:19 PM, David Blevins wrote:
> Dain, you mind if I kill the Spring assembler for the moment as
> it's in my way. We could likely redo the spring assembler based on
> the dynamic assembler anyway.
>
> Thoughts?
>
> -David
>
> On Jan 3, 2007, at 3:28 PM, David Blevins wrote:
>
>> So this kind of idea has been in my head for a while. Basically,
>> the idea is for an interactive assembler implementation which
>> people could call to add/remove containers, resources, and beans
>> at runtime. We'd also use it to support other services which
>> could now also do the same.
>>
>> The classic assembler is a one-shot builder, it constructs
>> everything and it's job is done. What I'm imagining the Dynamic
>> Assembler to be is more of an API for people who want to make
>> calls to build up and add to the container system at runtime.
>> It'd leverage the InfoObject tree we have now to allow people to
>> do things like:
>>
>> addContainer(ContainerInfo info)
>> addEjbJar(EjbJarInfo info)
>> addResource(ResourceInfo info)
>>
>> There would be equivalent methods for removing any of the above.
>> We might even have equivalent overloaded versions that might look
>> like this:
>>
>> addContainer(String id, Class impl, String type, Properties
>> containerProps)
>> addEjbJar(org.apache.openejb.EjbJar ejbJar)
>> addEjbJar(URL jarLocation)
>> addResource(URL jdbcUrl)
>>
>> Not a completely flushed out idea, just kind of brain storming and
>> looking for feedback.
>>
>> -David
>>
Kill spring assembler (was: Re: Dynamic Assembler?)
Posted by David Blevins <da...@visi.com>.
Dain, you mind if I kill the Spring assembler for the moment as it's
in my way. We could likely redo the spring assembler based on the
dynamic assembler anyway.
Thoughts?
-David
On Jan 3, 2007, at 3:28 PM, David Blevins wrote:
> So this kind of idea has been in my head for a while. Basically,
> the idea is for an interactive assembler implementation which
> people could call to add/remove containers, resources, and beans at
> runtime. We'd also use it to support other services which could
> now also do the same.
>
> The classic assembler is a one-shot builder, it constructs
> everything and it's job is done. What I'm imagining the Dynamic
> Assembler to be is more of an API for people who want to make calls
> to build up and add to the container system at runtime. It'd
> leverage the InfoObject tree we have now to allow people to do
> things like:
>
> addContainer(ContainerInfo info)
> addEjbJar(EjbJarInfo info)
> addResource(ResourceInfo info)
>
> There would be equivalent methods for removing any of the above.
> We might even have equivalent overloaded versions that might look
> like this:
>
> addContainer(String id, Class impl, String type, Properties
> containerProps)
> addEjbJar(org.apache.openejb.EjbJar ejbJar)
> addEjbJar(URL jarLocation)
> addResource(URL jdbcUrl)
>
> Not a completely flushed out idea, just kind of brain storming and
> looking for feedback.
>
> -David
>