[picocontainer-dev] Latest Pico Commit.... changed behavior on AbstractContainerBuilder

[Michael Rimov]

Hi guys,

Pico 2 behavior: AbstractContainerBuilder would automatically start all
containers that it created.
New Pico 3 behavior I just checked in: Starting behavior has been
refactored out into a decorating AutoStartingContainerBuilder. So you get
Pico 2 behavior with:
ContainerBuilder builder = new AutoStartingContainerBuilder(new
GroovyContainer(.....));

I needed it for me because I kept running into situations where
parent.makeChildContainer() would cause all sorts of conniptions when both
the parent and child were deployed through the container builders; and my
"don't change any behavior" fix through the constructor args was __U G L
Y__.

Let me know if there are better options that you can see.


-Mike


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Paul Hammant]

Is there a away that this could be a strategy on DPC ?

DPC.setChildContainerStarter(new DontAutoStartChildContrainers())
DPC.setChildContainerStarter(new AutoStartChildContrainers()) // default

- Paul

Post by Michael Rimov
Hi guys,
Pico 2 behavior: AbstractContainerBuilder would automatically start all
containers that it created.
New Pico 3 behavior I just checked in: Starting behavior has been
refactored out into a decorating AutoStartingContainerBuilder. So you get
ContainerBuilder builder = new AutoStartingContainerBuilder(new
GroovyContainer(.....));
I needed it for me because I kept running into situations where
parent.makeChildContainer() would cause all sorts of conniptions when both
the parent and child were deployed through the container builders; and my
"don't change any behavior" fix through the constructor args was __U G L
Y__.
Let me know if there are better options that you can see.
-Mike
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

[Michael Rimov]

Absolutely!



The only problem I've found is that the strategy interface will also need to
bleed into ScriptedContainerBuilderFactory so that there's a default
behavior in containers constructed.



That said, it would still wouldn't be too ugly, and it would save people
when they migrate from Pico 2 - Pico 3. I'll make the changes.



Thanks!


-Mike



From: Paul Hammant [mailto:paul-POq8DFUn+***@public.gmane.org]
Sent: Tuesday, November 30, 2010 8:55 AM
To: dev-qxt/k92ZUMzOYGyH7mwfjrEhcVWVsK+***@public.gmane.org
Subject: Re: [picocontainer-dev] Latest Pico Commit.... changed behavior on
AbstractContainerBuilder



Is there a away that this could be a strategy on DPC ?



DPC.setChildContainerStarter(new DontAutoStartChildContrainers())

DPC.setChildContainerStarter(new AutoStartChildContrainers()) // default



- Paul

On Tue, Nov 30, 2010 at 7:40 AM, Michael Rimov <rimovm-***@public.gmane.org>
wrote:

Hi guys,

Pico 2 behavior: AbstractContainerBuilder would automatically start all
containers that it created.
New Pico 3 behavior I just checked in: Starting behavior has been
refactored out into a decorating AutoStartingContainerBuilder. So you get
Pico 2 behavior with:
ContainerBuilder builder = new AutoStartingContainerBuilder(new
GroovyContainer(.....));

I needed it for me because I kept running into situations where
parent.makeChildContainer() would cause all sorts of conniptions when both
the parent and child were deployed through the container builders; and my
"don't change any behavior" fix through the constructor args was __U G L
Y__.

Let me know if there are better options that you can see.


-Mike


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email