RE: [picocontainer-dev] bug on pico start

Hi Jorg,

Thanks for your help.
My problem is more about the lifecycle and order of operations. Somehow I think that pico is missing an "init" step in the lifecycle where you can have a modular structure for registering components. I have a complex structure for pico components and 3 variants on the registered components... one for GUI, another one for db operations and another one for my tests. Guice has "modules" for instance that allow that. I was trying to do some of that in the start method but with the concurrency issues this is not working.
Ideally, I'd see a lifecycle with
- init -> registers components
- start
- stop
- dispose

Am I the only one who has these requirements?

Erik
-----Original Message-----
From: Jörg Schaible [mailto:[email protected]] 
Sent: August 6, 2007 2:30
To: dev-qxt/[email protected]
Subject: RE: [picocontainer-dev] bug on pico start

Hi Erik,

Putrycz, Erik wrote on Thursday, August 02, 2007 6:04 PM:

> Thanks Paul, I just redid the patch to be cleaner I unfortulately did
> some formatting on that previous patch.
> I'm basically doing lots of IoC violations... My code is very close
> to what is in the testcase. 
> 
> In my app I just added a bunch of configuration classes. At
> the start of
> the application, I need to initialize the configuration classes (check
> if directories exist...). I have componentized the configuration into
> modules so in the start (pico.start)) I retrieve all the
> configuration modules by doing
> pico.getComponents(ConfigurationModule.class). And that 
> barfs a concurrency exception.
> 
> I know propagating the container is outside of schoolbooks of
> IoC but it
> would be nice if pico could accommodate that as well.

Personally, I'd rather change the implementation that Pico detects the situation and throws an IllegalArgumentException when registering a PicoContainer than starting to support this. Since you did not show exactly what you do, I can only assume about your exact use case, but I believe that it can easily fixed with a proper component:

class ConfigurationManager{
	ConfigurationManager(ConfigurationModule[] cm) {
		// do whatever you have to do with the CMs.
	}
}

- Jörg

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

    http://xircles.codehaus.org/manage_email


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

    http://xircles.codehaus.org/manage_email