Design flaw working with JavaBeans

Hi ASlak,

since you've started working on this, here some of my thoughts:

What about enhancing the ctors for ConstantParameter and CompnentParameter for a hint and have a getHint method in the Parameter iface?

I would like to code:

registerComponentImplementation(Group.class, GroupImpl.class);
registerComponentImplementation(Address.class, AddressImpl.class, new Parameter[]

)

what I would like to support with this:

1)

class AddressImpl {
AddressImpl();
void setName(String name)

;
}

2)

class AddressImpl {
AddressImpl(Group goup, String name)

}

With the hint I can specify the setter for the SICA explicitly. For CICA we may not instist on the parameter's sequence (once proposed by Thomas), only interesting if the parameters getting ambigous. Without a hint the SICA may just try to fulfill all dependencies from the setters.

I would also implement the hint as Object instead of a String. This can be used by more advanced CAs e.g. using a regular expression.

WDYT?

The hint would only make sense when used with SetterInjectionComponentAdapter (new name for BeanComponentAdapter).

So it is a tad ugly.

-But it is also a pragmatic solution.

I'm in favour of it as long as the old constructors for ComponentParameter and ConstantParameter are left intact.

I have made one of the tests pass using a naive solution. It would have to be improved when implementing the hints.

I'll assign this to you.

> The hint would only make sense when used with
> SetterInjectionComponentAdapter (new name for BeanComponentAdapter).

as the sequence makes sense only for the CICA, but wait - this is what Pico is about

>So it is a tad ugly.
>-But it is also a pragmatic solution.

Think so too. Additionally the BeanPropertyCA gets then superfluous ... do you mind if I remove it ?

> I'm in favour of it as long as the old constructors for
> ComponentParameter and ConstantParameter are left intact.

That was my intension.

> I have made one of the tests pass using a naive solution.
> It would have to be improved when implementing the hints.
> I'll assign this to you.

Fine. BTW, this hybrid test is about a component, that has basically bean style, but offers other ctors than the standard ctor, too. Remember, CICA takes by default always the longest ctor, but I invoke and use the component as pure bean and need therefore the standard ctor for instantiation.

Waiting for refactored SICA

Jorg, I have no outstanding refactorings to do here. Is everyone fine with Jorg proceeding with his suggested refactorings? (I am fine with that).

Looks good to me.

Is this still desired? I'm not sure its a design flaw.. just a wacky corner case.

If the user knew which parameters were to be used in the cxtor, and which in setters, a solution can be synthesized by wrapping a CICA with a BPCA. BPCA. setProperties() can be parameters as well as map that would cascade key lookups back onto a PC in order to satisfy component deps.

I'm not sure if this functionality should be implemented in the core container, or if providing a solution as an example in the docs would suffice.

Yes, I have this still on my todo list. Intension is to use a SICA as a delegator for CICA. This will support classes having a bean type interface and also ctor with params.

no problem. i'll try working up a patch then based upon your testcase (was looking for things to fix to get familiar with the code)

Is the patch still current for latest Svn HEAD ?

I think this is covered by MultiInjection .. which is an aggregation of ...

ConstructorInjector, SetterInjector, AnnotatedMethodInjector & AnnotatedFieldInjector