RE: [picocontainer-dev] Better CAF handling

The JMX and remoting are examples of what I was explaining. The proposed
syntaxes
         MutablePicoContainer mpc = new PicoBuilder().withWithCaching
().withThreadSafety().withHiddenImplementations().withSetterInjection
().build();

and
         MutablePicoContainer mpc = new PicoBuilder().withAdapters
(caching().of().madeThreadSafe().of().hiddenImplementations().of
().setterInjection()).build();

Won't allow to plug additional CAFs in a friendly way where as
MutablePicoContainer mpc = new PicoBuilder().withAdapters (CACHING,
THREADSAFE, IMPL_HIDING, CDI).build(); could allow to plug anything else
with a simple import.

Erik

-----Original Message-----
From: Michael Rimov [mailto:[email protected]] 
Sent: May 24, 2007 13:45
To: dev-qxt/[email protected]
Subject: RE: [picocontainer-dev] Better CAF handling

> MutablePicoContainer mpc = new PicoBuilder() {{
> 	useSetterInjection(); // this is the factory !!
> 	addThreadSafety();
> 	addHiddenImplementations();
> 	addCaching();
> }}.build();
> 

Ok two questions come to mind:

How would we add custom behaviors that would tend to be beyond the scope
of
the core API?

Eg:  
	addJMXRegistration()
	addRemoting()

etc?

And the second is probably more for Paul, how can we dynamically switch
"capabilities" as we're registering objects.  Eg:

	.component(Something.class)    //Default CDI
	.component(SomethingElse.class)
	.component(Something3.class)
	.withSetterInjection()		//Switch to all new components
use
SDI
		.component(Setter1.class)
		.component(Setter2.class)
	.withConstructorInjection()  //Back to CDI
		.component(Something4.class)
		.component(Something5.class)

								-Mike





---------------------------------------------------------------------
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