Re: [picocontainer-dev] Builder confusion and cycles in annotation

On Jun 14, 2007, at 11:57 AM, Putrycz, Erik wrote:

> 2 points:
>
> - The builder and default container are confusing: if you use the  
> builder, you get the caching by default even when you don’t say  
> withCaching() because most contructors of picocontainer create the  
> caching adapter.

     public void testBasic() {
         MutablePicoContainer mpc = new PicoBuilder().build();
         String foo = simplifyRepresentation(mpc);
         assertEquals("PICO\n" +
                 "   
componentFactory=org.picocontainer.injectors.AnyInjectionFactory\n" +
                 "    cdiDelegate\n" +
                 "    sdiDelegate\n" +
                 "   
parent=org.picocontainer.containers.EmptyPicoContainer\n" +
                 "   
lifecycleStrategy=org.picocontainer.lifecycle.NullLifecycleStrategy\n" +
                 "   
componentMonitor=org.picocontainer.monitors.NullComponentMonitor\n" +
                 "PICO",foo);
     }

Suggests your findings are incorrect. AnyInjectionFactory (or should  
that be renamed Adaptive..) does not cache. I'd expect the test to  
look like the follwoing if you were correct in your findings.

     public void testBasic() {
         MutablePicoContainer mpc = new PicoBuilder().build();
         String foo = simplifyRepresentation(mpc);
         assertEquals("PICO\n" +
                 "   
componentFactory=org.picocontainer.behaviors.CachingBehaviorFactory\n" +
                 "     
delegate=org.picocontainer.injectors.AnyInjectionFactory\n" +
                 "      cdiDelegate\n" +
                 "      sdiDelegate\n" +
                 "   
parent=org.picocontainer.containers.EmptyPicoContainer\n" +
                 "   
lifecycleStrategy=org.picocontainer.lifecycle.NullLifecycleStrategy\n" +
                 "   
componentMonitor=org.picocontainer.monitors.NullComponentMonitor\n" +
                 "PICO",foo);
     }

> Also having a NOCACHE characteristic + settings in the builder is  
> somehow redundant. I find the componentcharacteristic system not  
> elegant at all.
There is something to be said for your suggestion of confusion around  
NOCACHE.  It is for when you're using CachingBehaviorFactory and you  
want one component to opt out of the overall caching strategy.  In  
the end the characteristics are overrides of sorts to that setup in  
the chain of ComponentFactories.
> - The current strategy of dealing with cycles is to throw an  
> exception when a cycle is found. However many cycles can be solved  
> when using only method and field injection.
Could and should are two different things. :-) I've not come across  
any situation where a client's circular reference is bona-fide.  
Indeed the client always agrees and we eek out another component that  
undoes the circular case.

However the HotSwappingBehavior (formerly  
HotSwappingComponentAdapter) did support the circular case.  I  
changed it some as its 'hot' behaviour was visible to itself via  
reflection and its component siblings which was wrong.
> What I suggest (and have done) ..
Am still interested in seeing that patch you allude to :-)
> .. is to track all the instances being injected and keep going  
> recursively until they are all done even when there are cycles. A  
> current limitation is that all relies on getComponent, so I’m not  
> sure there is a way to flush a cache in a CA after the root  
> getComponent is processed.
well recursion is happening, and it does keep going until its done.   
I'm otherwise OK with the way it works now.  More in a minute as I  
reply to Jörg's email.

- Paul