Re: [picocontainer-dev] Bug or feature?

Konstantin Priblouda wrote:

> 
> --- Paul Hammant <[email protected]> wrote:
> 
>>        T getComponentInstance(PicoContainer
>> container) throws
>> PicoCompositionException;
>> 
>> .... only requires a container instance to be passed
>> in at
>> getComponent time.  Which ref is passed in ?  parent
>> or child ?
> 
> That's differs in current trunk code base...
> 
> When you use container.getComponent(key) it looks up
> the adapter and then passes  itself ( leaf )
> 
> When you use containt.getInstance(CA) it finds
> container hosting this CA and passes it.
> 
> Weird what?

It's even more weird. I pointed that out some years ago to Paul. Nobody
stops you from requesting a CA from the Pico and use it with an arbitrary
container to resolve the deps. ;-)

... it's been quite exactly 3 years ago:

============== %< ==============
On Donnerstag, 28. Oktober 2004, you wrote:
Hi Paul,

independent of the recent discussion of the list, we have an unsymmetric 
behaviour in the dependency resolution. Look the test case:

    public void testCircumventRevertResolution() {
        MutablePicoContainer parent = new DefaultPicoContainer();
        parent.registerComponentImplementation(DependsOnTouchable.class);
        MutablePicoContainer child = new DefaultPicoContainer(parent);
        child.registerComponentImplementation(SimpleTouchable.class);
        try {
            child.getComponentInstanceOfType(DependsOnTouchable.class);
            fail("UnsatisfiableDependenciesException expected");
        } catch(UnsatisfiableDependenciesException e) {
            // good
        }
        ComponentAdapter adapter = 
child.getComponentAdapterOfType(DependsOnTouchable.class);
        assertNotNull(adapter.getComponentInstance(child));
    }

Using the pure adapter, we are able to resolve the dependency. Well, we can 
still argue, that a component, that uses a Pico as dependency is not a 
component, but I was somewhat surprised to detect this possibility.
============== %< ==============
Paul Hammant wrote on Friday, October 29, 2004 2:47 PM:

Jörg,

Yup needs fixing....

- Paul
============== %< ==============
On Freitag, 29. Oktober 2004, you wrote:

I am not sure about this. If you operate on CAs, you've definitely left the
component level and you're in the app builder role. 
 
The problem itself is introduced by MX_PROPOSAL, since this change removed
the ownership of the Container from the CA. If we really want to fix it, we
can either revert big parts of MX_PROPSAL or don't deliver CAs from the
container introducing something you described on the list and scratched in
the end. Both solutions would result in a major effort again (and I would
not wait with the announced beta release for this).

[snip]
============== %< ==============

;-)

>> It might be nice for the one that the
>> getComponent(..) is being
>> invoked on to exclusively be passed around for all
>> resolves - though
>> that requires a lot of thought before we change
>> things.
> 
> 
> I would prefer that CA is always resolved against own
> container... This can be achieved by:
>  - keeping reference to container in CA ( say, while
> registering )
> 
>  - walking down the root  everywhere where user can
> pass container to ca.
> 
> Anyay, do users have any need to use CA besides
> registering components in a weird way?

Deja vu :D

However, why does a CA has the need for a container reference and the key?
IMHO a CA/CF should expose its dependency sets (e.g. Class[][]
CF.getDependencyTypes()) and the container can try to fulfill one of it to
create an instance. In this case there would not even be a need to pass the
pico around.

> BTW, another question arises during refactoring:
> 
> is it wise to cache result of adapter resolution in
> parameters?

No, I would not do that. You can already cache the component itself and then
a parameter cache is superfluous. And if you have the need not to cache the
component, the probability is high, that some parameters have changed ...

- Jörg


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

    http://xircles.codehaus.org/manage_email