cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: [RT] Concerns surrounding CocoonNG
Date Wed, 11 Aug 2004 20:06:44 GMT
Hi Niclas,

we're drifting OT though, but I could not let your statement uncommented as
it gave a false impression ;-)

Niclas Hedhman wrote:
> On Thursday 12 August 2004 03:24, Jörg Schaible wrote:
>> Niclas Hedhman wrote:
>> > The next step ain't that far away, we are just struggling with some
>> > semantics, especially surrounding the possibility of more than a single
>> > constructor, which Pico says is a no-no, but could be a necessity.
>> Pico supports multiple ctors now for quite some time (as it does setter
>> injection - its just not preferred).
> Ok. May I ask how Pico resolves which constructor to use, when two or
> more, seemingly incompatible, constructors can be satisfied?

In short: It selects the one with the most arguments it can satisfy. You
have influence on that selection though defining parameters, that can also
have resolvable dependencies though.

>> > Another 'issue' that CDI imposes is how to deal with aggregations and
>> > possibly custom configuration/parameterization objects, which Pico
>> > (unlike Type2) will need.
>> Concerning aggregations Pico handles Java arrays and there is already
>> support for typed aggregations in the queue .. just commented out waiting
>> for JDK 1.5.
> I was thinking more of ;  I have a component that needs MANY arguments in
> its initialization, of various types, more than is barely feasible to feed
> into the constructor. Pico (when I read it last time, some time ago)
> recommended that configuration types were to be used, i.e. one wraps up
> those values into another object and pass it in the constructor. The class
> of that object, can not really be pico-styled, since that would then have
> the same problem. Then we are back to the Configuration class in Avalon,
> or something similar.

If you have a more bean-style component, you may use the setter injection.
The number of arguments does not really matter. If you use the parameter
definition as mensioned above, you can also do it that way. But, sometimes
it *is* convenient to have a Configuration class, isn't it a valid pattern?
It just depend on the case and your needs.

- Jörg

View raw message