RE: [picocontainer-dev] A way forward for annotations in Pico codebase

I totally agree about the two sides.
Concerning the generics, I don't mind working against pico 2 svn if that
can provide a way to support the generics. 

As a note,
   pico.registerComponentInstance(PicoContainer.class, pico); 

doesn't totally work cf http://jira.codehaus.org/browse/PICO-292. I had
solved this problem but Joerg said it was this was not a valid use case
(and causes security problems?) so I never bothered sending a patch. I
don't mind looking at it again if that could go somewhere.

It also seems to me that the current code in the svn works pretty much
the way you are suggesting (thanks to Mauri's nice refactoring). The
annotation @Inject is processed by the InjectingComponentAdapter.
Basically this could be used on its own with the Inject class in a
DefaultPicoContainer.

The bug you are talking in injectDependencies, is it about circular
dependencies? If yes, I'm not sure how to deal with it. To detect them,
it would be necessary to know the whole object graph in this method?

I know that other containers such as hivemind do allow circular
dependencies and do proxy everything. 

Erik
-----Original Message-----
From: Paul Hammant [mailto:[email protected]] 
Sent: May 1, 2007 9:51
To: dev-qxt/[email protected]
Subject: [picocontainer-dev] A way forward for annotations in Pico
codebase

Erik,

We see two sides to your code (1) the @nnotations stuff (2) the  
generics stuff.

Can we set you a challenge?

Rework the annotations work to fit the following goals -

   * work with an unextended DefaultPicoContainer
   * implemented as a ComponentAdapterFactory and ComponentAdapter  
(which can extend/reuse existing classes)
   * will introduce @inject

Leave off the following for now - we'll debate them later -

   * @singleton
   * @implementedBy

Also leave drop the automatic capability for a component to depend on  
the container that registers it.  For now can you live with something  
like -

   pico.registerComponentInstance(PicoContainer.class, pico);
   pico.registerComponentInstance(NeedsTheContainerThatMadeIt.class);

Lastly, we'll address all generics and other Java5 aspects shortly -  
so please ignore that too.

We like this approach because its more evolutionary :-)

We think also, there might be a subtle bug in 'injectDependencies' in  
InjectingComponentAdapter.  In complex cases PicoContainer works out  
the order of instantiation first (directive graph of component deps)  
then executes that plan.  If it finds circular deps if barfs early.   
Yours we think might fail for complex dependency situations - though  
we have yet to write a test case that proves it.

- Paul

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