Re: [picocontainer-dev] Better CAF handling

Yeah, I'm with Erik.

I have a change nearly ready to commit that would allow :

     public void testWithCafsListChainThingy() {
         MutablePicoContainer mpc = new PicoBuilder 
().withComponentAdapterFactories(CACHING(), IMPL_HIDING(), SDI 
()).build();
         String foo = simplifyRepresentation(mpc);
         assertEquals("PICO\n" +
                 "   
componentAdapterFactory=org.picocontainer.adapters.CachingComponentAdapt 
erFactory\n" +
                 "     
delegate=org.picocontainer.adapters.ImplementationHidingComponentAdapter 
Factory\n" +
                 "       
delegate=org.picocontainer.adapters.SetterInjectionComponentAdapterFacto 
ry\n" +
                 "   
parent=org.picocontainer.alternatives.EmptyPicoContainer\n" +
                 "   
lifecycleStrategy=org.picocontainer.lifecycle.NullLifecycleStrategy\n" +
                 "   
componentMonitor=org.picocontainer.monitors.NullComponentMonitor\n" +
                 "PICO",foo);
     }

PicoBuilder has the following added:

     public static ComponentAdapterFactory IMPL_HIDING() {
         return new ImplementationHidingComponentAdapterFactory();
     }

     public static ComponentAdapterFactory CACHING() {
         return new CachingComponentAdapterFactory();
     }

Which would be statically imported.  You'll note that DecoratingCAFs  
no longer take their delegate in their ctor.  The do hold that state,  
but its now setDelegate(..) - which could be renamed.  These methods  
are static AND stateless (thus not horrific to IoC agenda).  Its open  
of course, they need not be defined in PicoBuilder.

         mpc = new PicoBuilder().adapters(JMX(), CACHING(),  
IMPL_HIDING(), SDI()).build();
         mpc = new PicoBuilder().withAdapters(new  
JmxComponentAdapterFactory(), CACHING(), IMPL_HIDING(), SDI()).build();

I have eveything done and passing everywhere, but XmlContainerBuilder  
is doing a nested CAF thing in one test that is driving me nuts.  I  
am not sure how its working presently, before my commit, this I am  
not sure where/how to do a setDelegate(..) on it to make it all go  
green.

- Paul

On May 24, 2007, at 1:18 PM, Putrycz, Erik wrote:

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


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

    http://xircles.codehaus.org/manage_email