Nabble - NanoContainer - PicoContainer

booter never deployed?

2009-11-27T01:33:51Z

hi all,

i miss picocontainer-booter from repositories - was t never deployed?

regards

----[ Konstantin Pribluda http://www.pribluda.de ]----------------
JTec quality components: http://www.pribluda.de/projects/

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Dev

RE: RE: How does picocontainer handles constructor exceptions

2009-11-06T13:16:36Z

Pedro Félix wrote:

>> >> > Namely, I was thinking about the different solutions to
>> >> > handle this
>> >> > situations:
>> >> >
>> >> > Hypothesis 1: Forbid checked exceptions
>> >> > on constructors and "bubble
>> >> > up" unchecked exceptions
>> >>
>> >> Checked exceptions are enforced at compile time. With the
>> reflection,
>> >> all exceptions become unchecked.
>> >
>> > Well, this prohibition would be enforced on runtime. It is possible,
>> using
>> > reflection, to determine if a constructor throws checked exceptions.
>> > However, it may not make lots of sense.
>> It does not mater, since you cannot rethrow the checked exception without
>> declaring it for your method again.
> I understand "you cannot rethrow the checked exception without declaring
> it for your method again", but don't understand your point.

I reread this topic any my comment does really not make a lot sense - so
forget it ;-)

- Jörg

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Users

RE: RE: How does picocontainer handles constructor exceptions

2009-11-06T05:48:12Z

> >> > Namely, I was thinking about the different solutions to
> >> > handle this
> >> > situations:
> >> >
> >> > Hypothesis 1: Forbid checked exceptions
> >> > on constructors and "bubble
> >> > up" unchecked exceptions
> >>
> >> Checked exceptions are enforced at compile time. With the
> reflection,
> >> all exceptions become unchecked.
> >
> > Well, this prohibition would be enforced on runtime. It is possible,
> using
> > reflection, to determine if a constructor throws checked exceptions.
> > However, it may not make lots of sense.
> It does not mater, since you cannot rethrow the checked exception without declaring it for your method again.

I understand "you cannot rethrow the checked exception without declaring it for your method again", but don't understand your point.

>
> >> > Hypothesis 3: Try to recover from
> >> > exception, namely if the
> >> > dependency is not mandatory.
> >> >
> >> > Why do you think that this last behavior "is pretty bad"?
> >> >
> >>
> >> Because it's pretty difficult to imagine how to recover from object
> >> creation failure.
> > Well, I'm not recovering the creation of the object that thrown the
> > exception in the ctor. Instead, I'm trying to "recover" the creation
> of a
> > directly or indirectly dependent object, assuming that this
> dependency is
> > optional.
>
> It's the default behaviour that makes most sense. A dependency that
> cannot
> be satisfied leaves the depending component in an unspecified
> state. "Assuming" that the dependency is optional is not really valid
> here.
> Explicitly expressing that it is optional - then yes. See my other
> mail.

I completely agree. This behavior would only make sense if the dependency is explicitly marked as optional by the dependant type.

Thanks
Pedro

> - Jörg
>
>
> ---------------------------------------------------------------------
> 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

From forum: NanoContainer - PicoContainer - Users

RE: How does picocontainer handles constructor exceptions

2009-11-06T05:08:51Z

Hi Pedro,

Pedro Félix wrote at Freitag, 6. November 2009 13:57:

> See comments below
>>
>> > Namely, I was thinking about the different solutions to
>> > handle this
>> > situations:
>> >
>> > Hypothesis 1: Forbid checked exceptions
>> > on constructors and "bubble
>> > up" unchecked exceptions
>>
>> Checked exceptions are enforced at compile time. With the reflection,
>> all exceptions become unchecked.
>
> Well, this prohibition would be enforced on runtime. It is possible, using
> reflection, to determine if a constructor throws checked exceptions.
> However, it may not make lots of sense.

It does not mater, since you cannot rethrow the checked exception without
declaring it for your method again.

>> > Hypothesis 3: Try to recover from
>> > exception, namely if the
>> > dependency is not mandatory.
>> >
>> > Why do you think that this last behavior "is pretty bad"?
>> >
>>
>> Because it's pretty difficult to imagine how to recover from object
>> creation failure.
> Well, I'm not recovering the creation of the object that thrown the
> exception in the ctor. Instead, I'm trying to "recover" the creation of a
> directly or indirectly dependent object, assuming that this dependency is
> optional.

It's the default behaviour that makes most sense. A dependency that cannot
be satisfied leaves the depending component in an unspecified
state. "Assuming" that the dependency is optional is not really valid here.
Explicitly expressing that it is optional - then yes. See my other mail.

- Jörg

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Users

RE: How does picocontainer handles constructor exceptions

2009-11-06T04:57:40Z

See comments below

>
> > Namely, I was thinking about the different solutions to
> > handle this
> > situations:
> >
> > Hypothesis 1: Forbid checked exceptions
> > on constructors and "bubble
> > up" unchecked exceptions
>
> Checked exceptions are enforced at compile time. With the reflection,
> all exceptions become unchecked.

Well, this prohibition would be enforced on runtime. It is possible, using
reflection, to determine if a constructor throws checked exceptions.
However, it may not make lots of sense.

> > Hypothesis 3: Try to recover from
> > exception, namely if the
> > dependency is not mandatory.
> >
> > Why do you think that this last behavior "is pretty bad"?
> >
>
> Because it's pretty difficult to imagine how to recover from object
> creation failure.
Well, I'm not recovering the creation of the object that thrown the
exception in the ctor. Instead, I'm trying to "recover" the creation of a
directly or indirectly dependent object, assuming that this dependency is
optional.

> regards,
Thanks, regards
Pedro

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Users

RE: How does picocontainer handles constructor exceptions

2009-11-06T03:50:03Z

--- On Fri, 11/6/09, Pedro Félix <pedrofelix@...> wrote:

> Namely, I was thinking about the different solutions to
> handle this
> situations:
>
>     Hypothesis 1: Forbid checked exceptions
> on constructors and "bubble
> up" unchecked exceptions

Checked exceptions are enforced at compile time. With the reflection, all exceptions become unchecked.

>     Hypothesis 3: Try to recover from
> exception, namely if the
> dependency is not mandatory.
>
> Why do you think that this last behavior "is pretty bad"?
>

Because it's pretty difficult to imagine how to recover from object creation failure.

regards,

----[ Konstantin Pribluda http://www.pribluda.de ]----------------
JTec quality components: http://www.pribluda.de/projects/

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Users

RE: How does picocontainer handles constructor exceptions

2009-11-06T02:21:55Z

Paul,

Thanks for the reply.
I really don't have a concrete use case for this functionality.

I'm currently just studying Dependency Injection (DI) concepts and was
curious about the way that constructor exceptions are handled by the several
containers.
Namely, I was thinking about the different solutions to handle this
situations:

Hypothesis 1: Forbid checked exceptions on constructors and "bubble
up" unchecked exceptions

Hypothesis 2: Allow checked exceptions on constructors and also
"bubble them up"

Hypothesis 3: Try to recover from exception, namely if the
dependency is not mandatory.

Why do you think that this last behavior "is pretty bad"?

Once again, thanks.

Regards
Pedro Félix

> -----Original Message-----
> From: Paul Hammant [mailto:paul@...]
> Sent: quinta-feira, 5 de Novembro de 2009 23:10
> To: user@...
> Subject: Re: [picocontainer-user] How does picocontainer handles
> constructor exceptions
>
> Pedro,
>
> >> It has to call a constructor to witness the
> >> exception, it can't exclude C as an injectee at any time - it is
> >> registered therefore it is a candidate for injection.
>
> > Yes, I understand that C constructor will always be called. However,
> > since B
> > is not mandatory, the exception throw by C constructor could (at
> > least in
> > theory) be ignored and A be constructed without a B instance.
>
> I'm not sure that PicoContainer should have that behavior by detault.
> In fact I think it pretty bad. However, we're into facilitating other
> people's visions...
>
> For your use case, would you like us to catch an exception, then try
> another permutation of component deps that may work, then silently
> return an instance of the type that was the subject of getComponent() ?
>
> - 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

From forum: NanoContainer - PicoContainer - Users

Re: How does picocontainer handles constructor exceptions

2009-11-06T00:39:58Z

Paul Hammant wrote at Freitag, 6. November 2009 00:10:

> Pedro,
>
>>> It has to call a constructor to witness the
>>> exception, it can't exclude C as an injectee at any time - it is
>>> registered therefore it is a candidate for injection.
>
>> Yes, I understand that C constructor will always be called. However,
>> since B
>> is not mandatory, the exception throw by C constructor could (at
>> least in
>> theory) be ignored and A be constructed without a B instance.
>
> I'm not sure that PicoContainer should have that behavior by detault.
> In fact I think it pretty bad. However, we're into facilitating other
> people's visions...
>
> For your use case, would you like us to catch an exception, then try
> another permutation of component deps that may work, then silently
> return an instance of the type that was the subject of getComponent() ?

Maybe we can mark dependencies of a component as optional and then look for
alternatives:

class X {
X(Foo foo, @Optional Bar bar){}
}

- Jörg

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Users

Re: How does picocontainer handles constructor exceptions

2009-11-05T15:10:27Z

Pedro,

>> It has to call a constructor to witness the
>> exception, it can't exclude C as an injectee at any time - it is
>> registered therefore it is a candidate for injection.

> Yes, I understand that C constructor will always be called. However,
> since B
> is not mandatory, the exception throw by C constructor could (at
> least in
> theory) be ignored and A be constructed without a B instance.

I'm not sure that PicoContainer should have that behavior by detault.
In fact I think it pretty bad. However, we're into facilitating other
people's visions...

For your use case, would you like us to catch an exception, then try
another permutation of component deps that may work, then silently
return an instance of the type that was the subject of getComponent() ?

- Paul

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Users

RE: How does picocontainer handles constructor exceptions

2009-11-05T14:25:37Z

> It has to call a constructor to witness the
> exception, it can't exclude C as an injectee at any time - it is
> registered therefore it is a candidate for injection.
Yes, I understand that C constructor will always be called. However, since B
is not mandatory, the exception throw by C constructor could (at least in
theory) be ignored and A be constructed without a B instance.

Thanks
Pedro

> -----Original Message-----
> From: Paul Hammant [mailto:paul@...]
> Sent: quinta-feira, 5 de Novembro de 2009 22:18
> To: user@...
> Subject: Re: [picocontainer-user] How does picocontainer handles
> constructor exceptions
>
> It will bubble all the way to the creation of user (thereby vetoing
> it) .... if A had a mandatory dep on B
>
> Pico will always choose a path that satisfies the constructor with the
> most args. It will still get the injection-time exception as
> described above. It has to call a constructor to witness the
> exception, it can't exclude C as an injectee at any time - it is
> registered therefore it is a candidate for injection.
>
> Regards,
>
> - Paul
>
> On Nov 5, 2009, at 1:49 PM, Pedro Félix wrote:
>
> > Thanks for the reply.
> >
> > 1) Where can I find more information regarding this subject?
> >
> > 2) Consider the following scenario
> >
> > User->A->B->C
> >
> > a) User code requests an A instance
> > b) Type A has an optional dependency on B
> > c) Type B has a mandatory dependency on C
> > d) The construction of a C instance results in an exception
> >
> > The exception in C construction results on an exception bubbling up
> > to the
> > initial call requesting an A instance?
> > Or, since B is not mandatory, the request for A succeeds?
> >
> > Thanks
> > Pedro Félix
> >
> >> -----Original Message-----
> >> From: Konstantin Priblouda [mailto:kpriblouda@...]
> >> Sent: quinta-feira, 5 de Novembro de 2009 19:23
> >> To: user@...
> >> Subject: Re: [picocontainer-user] How does picocontainer handles
> >> constructor exceptions
> >>
> >> AFAIR, they are passed through to caller. But nothing prevents you
> >> from
> >> implementing custom behaviour and catch them.
> >>
> >> regards,
> >>
> >> ----[ Konstantin Pribluda http://www.pribluda.de ]----------------
> >> JTec quality components: http://www.pribluda.de/projects/
> >>
> >>
> >> --- On Thu, 11/5/09, Pedro Félix <pedrofelix@...> wrote:
> >>
> >>> From: Pedro Félix <pedrofelix@...>
> >>> Subject: [picocontainer-user] How does picocontainer handles
> >> constructor exceptions
> >>> To: user@...
> >>> Date: Thursday, November 5, 2009, 7:16 PM
> >>> Hi,
> >>>
> >>> How does picocontainer handles exceptions (checked or
> >>> unchecked) throwed by
> >>> the constructor during constructor injection?
> >>>
> >>> Thanks
> >>> Pedro Félix
> >>>
> >>>
> >>> -------------------------------------------------------------------
> --
> >>> 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
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Users

Re: How does picocontainer handles constructor exceptions

2009-11-05T14:17:56Z

It will bubble all the way to the creation of user (thereby vetoing
it) .... if A had a mandatory dep on B

Pico will always choose a path that satisfies the constructor with the
most args. It will still get the injection-time exception as
described above. It has to call a constructor to witness the
exception, it can't exclude C as an injectee at any time - it is
registered therefore it is a candidate for injection.

Regards,

- Paul

On Nov 5, 2009, at 1:49 PM, Pedro Félix wrote:

> Thanks for the reply.
>
> 1) Where can I find more information regarding this subject?
>
> 2) Consider the following scenario
>
> User->A->B->C
>
> a) User code requests an A instance
> b) Type A has an optional dependency on B
> c) Type B has a mandatory dependency on C
> d) The construction of a C instance results in an exception
>
> The exception in C construction results on an exception bubbling up
> to the
> initial call requesting an A instance?
> Or, since B is not mandatory, the request for A succeeds?
>
> Thanks
> Pedro Félix
>
>> -----Original Message-----
>> From: Konstantin Priblouda [mailto:kpriblouda@...]
>> Sent: quinta-feira, 5 de Novembro de 2009 19:23
>> To: user@...
>> Subject: Re: [picocontainer-user] How does picocontainer handles
>> constructor exceptions
>>
>> AFAIR, they are passed through to caller. But nothing prevents you
>> from
>> implementing custom behaviour and catch them.
>>
>> regards,
>>
>> ----[ Konstantin Pribluda http://www.pribluda.de ]----------------
>> JTec quality components: http://www.pribluda.de/projects/
>>
>>
>> --- On Thu, 11/5/09, Pedro Félix <pedrofelix@...> wrote:
>>
>>> From: Pedro Félix <pedrofelix@...>
>>> Subject: [picocontainer-user] How does picocontainer handles
>> constructor exceptions
>>> To: user@...
>>> Date: Thursday, November 5, 2009, 7:16 PM
>>> Hi,
>>>
>>> How does picocontainer handles exceptions (checked or
>>> unchecked) throwed by
>>> the constructor during constructor injection?
>>>
>>> Thanks
>>> Pedro Félix
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
>
> ---------------------------------------------------------------------
> 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

From forum: NanoContainer - PicoContainer - Users

RE: How does picocontainer handles constructor exceptions

2009-11-05T11:49:43Z

Thanks for the reply.

1) Where can I find more information regarding this subject?

2) Consider the following scenario

User->A->B->C

a) User code requests an A instance
b) Type A has an optional dependency on B
c) Type B has a mandatory dependency on C
d) The construction of a C instance results in an exception

The exception in C construction results on an exception bubbling up to the
initial call requesting an A instance?
Or, since B is not mandatory, the request for A succeeds?

Thanks
Pedro Félix

> -----Original Message-----
> From: Konstantin Priblouda [mailto:kpriblouda@...]
> Sent: quinta-feira, 5 de Novembro de 2009 19:23
> To: user@...
> Subject: Re: [picocontainer-user] How does picocontainer handles
> constructor exceptions
>
> AFAIR, they are passed through to caller. But nothing prevents you from
> implementing custom behaviour and catch them.
>
> regards,
>
> ----[ Konstantin Pribluda http://www.pribluda.de ]----------------
> JTec quality components: http://www.pribluda.de/projects/
>
>
> --- On Thu, 11/5/09, Pedro Félix <pedrofelix@...> wrote:
>
> > From: Pedro Félix <pedrofelix@...>
> > Subject: [picocontainer-user] How does picocontainer handles
> constructor exceptions
> > To: user@...
> > Date: Thursday, November 5, 2009, 7:16 PM
> > Hi,
> >
> > How does picocontainer handles exceptions (checked or
> > unchecked) throwed by
> > the constructor during constructor injection?
> >
> > Thanks
> > Pedro Félix
> >
> >
> > ---------------------------------------------------------------------
> > 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

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Users

Re: How does picocontainer handles constructor exceptions

2009-11-05T11:22:42Z

AFAIR, they are passed through to caller. But nothing prevents you from
implementing custom behaviour and catch them.

regards,

----[ Konstantin Pribluda http://www.pribluda.de ]----------------
JTec quality components: http://www.pribluda.de/projects/

--- On Thu, 11/5/09, Pedro Félix <pedrofelix@...> wrote:

> From: Pedro Félix <pedrofelix@...>
> Subject: [picocontainer-user] How does picocontainer handles constructor exceptions
> To: user@...
> Date: Thursday, November 5, 2009, 7:16 PM
> Hi,
>
> How does picocontainer handles exceptions (checked or
> unchecked) throwed by
> the constructor during constructor injection?
>
> Thanks
> Pedro Félix
>
>
> ---------------------------------------------------------------------
> 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

From forum: NanoContainer - PicoContainer - Users

Re: How does picocontainer handles constructor exceptions

2009-11-05T11:14:07Z

They are rethrown (and wrapped inside)
org.picocontainer.PicoCompositionException. Unless the original
exception was a RuntimeException derivative, in which case it is
directly thrown to the thing calling getComponent().

Regards,

- Paul

On Nov 5, 2009, at 11:16 AM, Pedro Félix wrote:

> Hi,
>
> How does picocontainer handles exceptions (checked or unchecked)
> throwed by
> the constructor during constructor injection?
>
> Thanks
> Pedro Félix
>
>
> ---------------------------------------------------------------------
> 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

From forum: NanoContainer - PicoContainer - Users

How does picocontainer handles constructor exceptions

2009-11-05T09:16:46Z

Hi,

How does picocontainer handles exceptions (checked or unchecked) throwed by
the constructor during constructor injection?

Thanks
Pedro Félix

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Users

PicoContainer 2.9 released.

2009-11-02T06:13:54Z

Notes -

New (since 2.8.3):

Lifecycle strategy allows for concept of lazy starting. This means components are started at first access. PICO-355
Regex collecting of components for injection, or just on getComponent() now built in.

Changes (versus 2.8.3):

Purposeful injection of a Null parameter fixed PICO-364
Small performance improvements for getAdapter/getInstance
Dependencies for Log4J and SLF4J moved forward
Paranamer upgraded to 2.1
Exception in Lifecycle methods bug fixed PICO-363
PicoBuilder able to do more with Lifecycle strategies
Factory Injection improved with an 'InjectInto' type PICO-358

Regards,

- Paul

From forum: NanoContainer - PicoContainer - Dev

PicoContainer 2.9 released.

2009-11-02T06:13:54Z

Notes -

New (since 2.8.3):

Lifecycle strategy allows for concept of lazy starting. This means components are started at first access. PICO-355
Regex collecting of components for injection, or just on getComponent() now built in.

Changes (versus 2.8.3):

Purposeful injection of a Null parameter fixed PICO-364
Small performance improvements for getAdapter/getInstance
Dependencies for Log4J and SLF4J moved forward
Paranamer upgraded to 2.1
Exception in Lifecycle methods bug fixed PICO-363
PicoBuilder able to do more with Lifecycle strategies
Factory Injection improved with an 'InjectInto' type PICO-358

Regards,

- Paul

From forum: NanoContainer - PicoContainer - Users

Re: PicoContainer 2.9 release ?

2009-10-29T03:18:34Z

Mauro Talevi wrote:

> Michael Rimovm wrote:
>>> We've modest new functionality for Lazy lifecycle, improves for null
>>> handling, and a bunch of bug fixes.
>>
>>> Any objections to doing a release tomorrow?
>>
>> Nope! Sounds like a plan.
>>
>
> +1
>
>>
>> P.S. Jörg, thanks for the pointer to the Versions plugin! Cool stuff.
>>
>
> Yes, it's quite useful!

Especially for plugins - yes. Stephen Conolly did a good job. There's also a
display-dependency-updates goal - however, here you have to keep a close
eye on the report. If the version does not follow the Maven strategy -x.y.z
or the metadata in the remote repo is incomplete or wrong, then the
reported versions are not really helpful (for XStream):

[INFO] jmock:jmock ................................. 1.0.1 ->
20031129.200437

Nonsense.

[INFO] junit:junit ............................................. 3.8.1 ->
4.4

We have 4.5, but it's missing in central's metadata ...

[INFO] xml-apis:xml-apis .................................... 1.3.04 ->
2.0.2
[INFO] xmlpull:xmlpull ........................... 1.1.3.1 ->
1.1.3.4d_b4_min

Both versions are invalid.

So use it with care :)

Cheers,
Jörg

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Dev

Re: PicoContainer 2.9 release ?

2009-10-29T02:50:13Z

Michael Rimovm wrote:
>> We've modest new functionality for Lazy lifecycle, improves for null
>> handling, and a bunch of bug fixes.
>
>> Any objections to doing a release tomorrow?
>
> Nope! Sounds like a plan.
>

+1

>
> P.S. Jörg, thanks for the pointer to the Versions plugin! Cool stuff.
>

Yes, it's quite useful!

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Dev

Re: PicoContainer 2.9 release ?

2009-10-28T15:14:04Z

> P.S. Jörg, thanks for the pointer to the Versions plugin! Cool stuff.

Like that? Wait until you try out ...

mvn dependency:tree

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Dev

RE: PicoContainer 2.9 release ?

2009-10-28T15:08:36Z

>We've modest new functionality for Lazy lifecycle, improves for null
>handling, and a bunch of bug fixes.

>Any objections to doing a release tomorrow?

Nope! Sounds like a plan.
-Mike

P.S. Jörg, thanks for the pointer to the Versions plugin! Cool stuff.

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Dev

PicoContainer 2.9 release ?

2009-10-28T10:37:44Z

We've modest new functionality for Lazy lifecycle, improves for null
handling, and a bunch of bug fixes.

Any objections to doing a release tomorrow?

I've to look some more at the plugin versions declarations in poms,
but have nothing else backlogged.

Regards,

- Paul

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Dev

Re: Lazy lifecycle

2009-09-30T08:07:16Z

Thanks in advance Paul.

2009/9/30 Paul Hammant <paul@...>:

> Sorry Mark, I'll take a look tonight.
>
> Regards,
>
> - Paul
>
> On Sep 30, 2009, at 9:38 AM, Mark Hobson wrote:
>
>> Anyone have any pointers regarding this?
>>
>> Cheers,
>>
>> Mark
>>
>> 2009/9/23 Mark Hobson <markhobson@...>:
>>>
>>> Finally got back to this issue after a slight delay! I've reopened
>>> PICO-355 as the original fix didn't fulfil my requirements. I'll try
>>> to explain better this time..
>>>
>>> Currently, if you register a startable component, it is started when
>>> the container is started. I want a lifecycle strategy that only
>>> starts components when they are instantiated for use.
>>>
>>> For example, this is what currently happens ('A' is a Startable
>>> component):
>>>
>>> 1) pico.as(CACHE).addComponent(A.class)
>>> 2) pico.start()
>>> 3) (A is started)
>>>
>>> This is what I want to achieve:
>>>
>>> 1) pico.as(CACHE).addComponent(A.class)
>>> 2) pico.start()
>>> 3) (A is *not* started)
>>> 4) pico.getComponent(A.class)
>>> 5) (A is started)
>>>
>>> Similarly, stop and dispose need to behave accordingly.
>>>
>>> I've attached the above example as PICO-355-test2.patch under
>>> PICO-355. I'm happy to have a stab at providing a fix if someone
>>> could point me in the right direction.
>>>
>>> Cheers,
>>>
>>> Mark
>>>
>>> 2009/6/11 Paul Hammant <paul@...>:
>>>>
>>>> Sure there is plenty of time for me to change it. send me a modified
>>>> testcase if you so desire :)
>>>>
>>>> Regards,
>>>>
>>>> - Paul
>>>>
>>>> On Jun 11, 2009, at 9:14 AM, Mark Hobson wrote:
>>>>
>>>>> Strange, I didn't receive any email notifications. Thanks for the
>>>>> quick fix, although I'm not sure that that's what I need. I'll try to
>>>>> find some time soon to have a proper look and let you know.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Mark
>>>>>
>>>>> 2009/6/8 Paul Hammant <paul@...>:
>>>>>>
>>>>>> fixed :)
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> - Paul
>>>>>>
>>>>>> On Jun 8, 2009, at 5:31 AM, Mark Hobson wrote:
>>>>>>
>>>>>>> Paul, did you get a chance to take a look at this?
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Mark
>>>>>>>
>>>>>>> 2009/5/27 Mark Hobson <markhobson@...>:
>>>>>>>>
>>>>>>>> 2009/5/26 Paul Hammant <paul@...>:
>>>>>>>>>
>>>>>>>>> That should be easy.
>>>>>>>>
>>>>>>>> Cool :)
>>>>>>>>
>>>>>>>>> Can to get us half way by writing a testcase :-) Perhaps a mod to
>>>>>>>>> StartableLifecycleStrategyTestCase
>>>>>>>>> I expect I'll be subclassing (or better) StartableLifecycleStrategy
>>>>>>>>> ...
>>>>>>>>
>>>>>>>> Sure, I raised PICO-355 and attached a test case. I'm not sure how
>>>>>>>> you want to implement this; I changed
>>>>>>>> testThirdPartyStartableAndDisposable to be AUTOMATIC to signify an
>>>>>>>> eager lifecycle, but this is obviously quite a change that will
>>>>>>>> affect
>>>>>>>> users.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Mark
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Dev

Re: Lazy lifecycle

2009-09-30T07:47:43Z

Sorry Mark, I'll take a look tonight.

Regards,

- Paul

On Sep 30, 2009, at 9:38 AM, Mark Hobson wrote:

> Anyone have any pointers regarding this?
>
> Cheers,
>
> Mark
>
> 2009/9/23 Mark Hobson <markhobson@...>:
>> Finally got back to this issue after a slight delay! I've reopened
>> PICO-355 as the original fix didn't fulfil my requirements. I'll try
>> to explain better this time..
>>
>> Currently, if you register a startable component, it is started when
>> the container is started. I want a lifecycle strategy that only
>> starts components when they are instantiated for use.
>>
>> For example, this is what currently happens ('A' is a Startable
>> component):
>>
>> 1) pico.as(CACHE).addComponent(A.class)
>> 2) pico.start()
>> 3) (A is started)
>>
>> This is what I want to achieve:
>>
>> 1) pico.as(CACHE).addComponent(A.class)
>> 2) pico.start()
>> 3) (A is *not* started)
>> 4) pico.getComponent(A.class)
>> 5) (A is started)
>>
>> Similarly, stop and dispose need to behave accordingly.
>>
>> I've attached the above example as PICO-355-test2.patch under
>> PICO-355. I'm happy to have a stab at providing a fix if someone
>> could point me in the right direction.
>>
>> Cheers,
>>
>> Mark
>>
>> 2009/6/11 Paul Hammant <paul@...>:
>>> Sure there is plenty of time for me to change it. send me a
>>> modified
>>> testcase if you so desire :)
>>>
>>> Regards,
>>>
>>> - Paul
>>>
>>> On Jun 11, 2009, at 9:14 AM, Mark Hobson wrote:
>>>
>>>> Strange, I didn't receive any email notifications. Thanks for the
>>>> quick fix, although I'm not sure that that's what I need. I'll
>>>> try to
>>>> find some time soon to have a proper look and let you know.
>>>>
>>>> Cheers,
>>>>
>>>> Mark
>>>>
>>>> 2009/6/8 Paul Hammant <paul@...>:
>>>>>
>>>>> fixed :)
>>>>>
>>>>> Regards,
>>>>>
>>>>> - Paul
>>>>>
>>>>> On Jun 8, 2009, at 5:31 AM, Mark Hobson wrote:
>>>>>
>>>>>> Paul, did you get a chance to take a look at this?
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>> 2009/5/27 Mark Hobson <markhobson@...>:
>>>>>>>
>>>>>>> 2009/5/26 Paul Hammant <paul@...>:
>>>>>>>>
>>>>>>>> That should be easy.
>>>>>>>
>>>>>>> Cool :)
>>>>>>>
>>>>>>>> Can to get us half way by writing a testcase :-) Perhaps a
>>>>>>>> mod to
>>>>>>>> StartableLifecycleStrategyTestCase
>>>>>>>> I expect I'll be subclassing (or better)
>>>>>>>> StartableLifecycleStrategy
>>>>>>>> ...
>>>>>>>
>>>>>>> Sure, I raised PICO-355 and attached a test case. I'm not
>>>>>>> sure how
>>>>>>> you want to implement this; I changed
>>>>>>> testThirdPartyStartableAndDisposable to be AUTOMATIC to
>>>>>>> signify an
>>>>>>> eager lifecycle, but this is obviously quite a change that
>>>>>>> will affect
>>>>>>> users.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Mark
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> 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

From forum: NanoContainer - PicoContainer - Dev

Re: Lazy lifecycle

2009-09-30T07:38:32Z

Anyone have any pointers regarding this?

Cheers,

Mark

2009/9/23 Mark Hobson <markhobson@...>:

> Finally got back to this issue after a slight delay! I've reopened
> PICO-355 as the original fix didn't fulfil my requirements. I'll try
> to explain better this time..
>
> Currently, if you register a startable component, it is started when
> the container is started. I want a lifecycle strategy that only
> starts components when they are instantiated for use.
>
> For example, this is what currently happens ('A' is a Startable component):
>
> 1) pico.as(CACHE).addComponent(A.class)
> 2) pico.start()
> 3) (A is started)
>
> This is what I want to achieve:
>
> 1) pico.as(CACHE).addComponent(A.class)
> 2) pico.start()
> 3) (A is *not* started)
> 4) pico.getComponent(A.class)
> 5) (A is started)
>
> Similarly, stop and dispose need to behave accordingly.
>
> I've attached the above example as PICO-355-test2.patch under
> PICO-355. I'm happy to have a stab at providing a fix if someone
> could point me in the right direction.
>
> Cheers,
>
> Mark
>
> 2009/6/11 Paul Hammant <paul@...>:
>> Sure there is plenty of time for me to change it. send me a modified
>> testcase if you so desire :)
>>
>> Regards,
>>
>> - Paul
>>
>> On Jun 11, 2009, at 9:14 AM, Mark Hobson wrote:
>>
>>> Strange, I didn't receive any email notifications. Thanks for the
>>> quick fix, although I'm not sure that that's what I need. I'll try to
>>> find some time soon to have a proper look and let you know.
>>>
>>> Cheers,
>>>
>>> Mark
>>>
>>> 2009/6/8 Paul Hammant <paul@...>:
>>>>
>>>> fixed :)
>>>>
>>>> Regards,
>>>>
>>>> - Paul
>>>>
>>>> On Jun 8, 2009, at 5:31 AM, Mark Hobson wrote:
>>>>
>>>>> Paul, did you get a chance to take a look at this?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Mark
>>>>>
>>>>> 2009/5/27 Mark Hobson <markhobson@...>:
>>>>>>
>>>>>> 2009/5/26 Paul Hammant <paul@...>:
>>>>>>>
>>>>>>> That should be easy.
>>>>>>
>>>>>> Cool :)
>>>>>>
>>>>>>> Can to get us half way by writing a testcase :-) Perhaps a mod to
>>>>>>> StartableLifecycleStrategyTestCase
>>>>>>> I expect I'll be subclassing (or better) StartableLifecycleStrategy
>>>>>>> ...
>>>>>>
>>>>>> Sure, I raised PICO-355 and attached a test case. I'm not sure how
>>>>>> you want to implement this; I changed
>>>>>> testThirdPartyStartableAndDisposable to be AUTOMATIC to signify an
>>>>>> eager lifecycle, but this is obviously quite a change that will affect
>>>>>> users.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Dev

Re: Lazy lifecycle

2009-09-23T04:16:24Z

Finally got back to this issue after a slight delay! I've reopened
PICO-355 as the original fix didn't fulfil my requirements. I'll try
to explain better this time..

Currently, if you register a startable component, it is started when
the container is started. I want a lifecycle strategy that only
starts components when they are instantiated for use.

For example, this is what currently happens ('A' is a Startable component):

1) pico.as(CACHE).addComponent(A.class)
2) pico.start()
3) (A is started)

This is what I want to achieve:

1) pico.as(CACHE).addComponent(A.class)
2) pico.start()
3) (A is *not* started)
4) pico.getComponent(A.class)
5) (A is started)

Similarly, stop and dispose need to behave accordingly.

I've attached the above example as PICO-355-test2.patch under
PICO-355. I'm happy to have a stab at providing a fix if someone
could point me in the right direction.

Cheers,

Mark

2009/6/11 Paul Hammant <paul@...>:

> Sure there is plenty of time for me to change it. send me a modified
> testcase if you so desire :)
>
> Regards,
>
> - Paul
>
> On Jun 11, 2009, at 9:14 AM, Mark Hobson wrote:
>
>> Strange, I didn't receive any email notifications. Thanks for the
>> quick fix, although I'm not sure that that's what I need. I'll try to
>> find some time soon to have a proper look and let you know.
>>
>> Cheers,
>>
>> Mark
>>
>> 2009/6/8 Paul Hammant <paul@...>:
>>>
>>> fixed :)
>>>
>>> Regards,
>>>
>>> - Paul
>>>
>>> On Jun 8, 2009, at 5:31 AM, Mark Hobson wrote:
>>>
>>>> Paul, did you get a chance to take a look at this?
>>>>
>>>> Cheers,
>>>>
>>>> Mark
>>>>
>>>> 2009/5/27 Mark Hobson <markhobson@...>:
>>>>>
>>>>> 2009/5/26 Paul Hammant <paul@...>:
>>>>>>
>>>>>> That should be easy.
>>>>>
>>>>> Cool :)
>>>>>
>>>>>> Can to get us half way by writing a testcase :-) Perhaps a mod to
>>>>>> StartableLifecycleStrategyTestCase
>>>>>> I expect I'll be subclassing (or better) StartableLifecycleStrategy
>>>>>> ...
>>>>>
>>>>> Sure, I raised PICO-355 and attached a test case. I'm not sure how
>>>>> you want to implement this; I changed
>>>>> testThirdPartyStartableAndDisposable to be AUTOMATIC to signify an
>>>>> eager lifecycle, but this is obviously quite a change that will affect
>>>>> users.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Mark
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Dev

Re: Using regex to gather a list of components for injection

2009-09-16T11:41:40Z

> BTW, I'd prefer to composition/decoration of ComponentMonitor over
> inheritance.

I completely agree. As is, it was just to satisfy a unit test.

- Paul

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Dev

Re: Using regex to gather a list of components for injection

2009-09-16T08:06:36Z

Michael Rimov wrote:

>> http://fisheye.codehaus.org/changelog/picocontainer/?cs=5523
>>
>> I've started something, that should end up in Gems. It is related to
>> ComponentMonitor in that it leverages the noComponentFound
>> functionality. Thoughts as to name for it? It makes components that
>> are not ordinarily in the container. a Missing Component maker if you
>> like (though as you know by now I should never be allowed to name
>> classes).
>
> You know, I'd like to see these kinds of things somehow tagged with the Moniker
> along the lines of "ExternalProvider", since they're bending ComponentMonitor
> into a Provider.
>
> Perhaps a marker interface to allow easy tracing through the IDE and Javadocs?
>

Yes, I agree, it kinda warrants more than a monitor. We could introduce
an AutoComposer concept and have a RegexAutoComposer as the regex impl.

BTW, I'd prefer to composition/decoration of ComponentMonitor over
inheritance.

> Other than that, I agree with Joerg.....

Yep, definitely a Regex impl should have Regex in its name.

Cheers

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Dev

RE: Using regex to gather a list of components for injection

2009-09-15T10:48:33Z

> http://fisheye.codehaus.org/changelog/picocontainer/?cs=5523
>
> I've started something, that should end up in Gems. It is related to
> ComponentMonitor in that it leverages the noComponentFound
> functionality. Thoughts as to name for it? It makes components that
> are not ordinarily in the container. a Missing Component maker if you
> like (though as you know by now I should never be allowed to name
> classes).

You know, I'd like to see these kinds of things somehow tagged with the Moniker
along the lines of "ExternalProvider", since they're bending ComponentMonitor
into a Provider.

Perhaps a marker interface to allow easy tracing through the IDE and Javadocs?

Other than that, I agree with Joerg.....

-Mike

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Dev

Re: Using regex to gather a list of components for injection

2009-09-15T09:33:50Z

Paul Hammant wrote:

> http://fisheye.codehaus.org/changelog/picocontainer/?cs=5523
>
> I've started something, that should end up in Gems. It is related to
> ComponentMonitor in that it leverages the noComponentFound
> functionality. Thoughts as to name for it? It makes components that
> are not ordinarily in the container. a Missing Component maker if you
> like (though as you know by now I should never be allowed to name
> classes).

What's wrong with RegexComposer ?

- Jörg

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Dev

Using regex to gather a list of components for injection

2009-09-15T05:12:27Z

http://fisheye.codehaus.org/changelog/picocontainer/?cs=5523

I've started something, that should end up in Gems. It is related to
ComponentMonitor in that it leverages the noComponentFound
functionality. Thoughts as to name for it? It makes components that
are not ordinarily in the container. a Missing Component maker if you
like (though as you know by now I should never be allowed to name
classes).

Regards,

- Paul

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Dev

Re: List of named components as arg to constructor param

2009-09-15T05:06:29Z

Actually, a bug in PicoContainer itself would prevent that from
working. There's a SNAPSHOT that's been uploaded that will work
better ( picocontainer 2.9-20090915.120308-1 )

Watch for some new architecture in the next release that will allow
for regex to be used in component gathering for situations like this.

Regards,

- Paul

On Sep 12, 2009, at 9:57 AM, Paul Hammant wrote:

> pico = new DefaultPicoContainer(new NullComponentMonitor() {
>
> public Object noComponentFound(MutablePicoContainer container,
> Object componentKey);
> String[] keys = componentKey.split(",");
> List<Element>() elements = new ArrayList<Element>();
> for (String key in keys) {
> elements.add(container.get(key));
> }
> return new Composition(elements);
> }
>
> });
>
>
> pico.addComponent("elementA", Element.class, new ConstantParameter
> ("configA"))
> pico.addComponent("elementB", Element.class, new ConstantParameter
> ("configB"))
> pico.addComponent("elementC", Element.class, new ConstantParameter
> ("configC"))
>
> abComposition = pico.getComponent("elementA,elementB");
> bcComposition = pico.getComponent("elementB,elementC");
>
> -----
>
> No need to add Composition to the container for this specialized
> case, it'll be cached anyway for the key in question, unless you
> don't do caching in the PicoContainer setup. You obviously have to
> be comfortable with participating in the List creation.
>
> You could aim at some smaller language in the missing key
> definition , of you were prepared to do more string processing in
> the noComponentFound(..).
>
> abComposition = pico.getComponent("A,B");
> abComposition = pico.getComponent("AB");
> abComposition = pico.getComponent("compositionAB");
> abComposition = pico.getComponent("elems(A,B)");
>
> Regards,
>
> - Paul
>
>
> On Sep 11, 2009, at 5:38 AM, joe panico wrote:
>
>> Hello,
>>
>> I'm using PicoContainer 2.8.3.
>>
>> I would like Pico to explicitly wire specific named (keyed)
>> components
>> into a constructor arg for a List type param. For example:
>>
>> class Element{
>> private final String config;
>> public Element(String config){
>> this.config = config
>> }
>> }
>>
>> class Composition{
>> private final List<Element> elements;
>> public Composition(List<Element> elements){
>> this.elements = elements
>> }
>> }
>>
>> pico.addComponent("elementA", Element.class, new ConstantParameter
>> ("configA"))
>> pico.addComponent("elementB", Element.class, new ConstantParameter
>> ("configB"))
>> pico.addComponent("elementC", Element.class, new ConstantParameter
>> ("configC"))
>>
>> pico.addComponent("compositionAB", Composition.class, ?tell it to use
>> keys "elementA" + "elementB"?)
>> pico.addComponent("compositionBC", Composition.class, ?tell it to use
>> keys "elementB" + "elementC"?)
>>
>> How do I achieve those last two lines of pseudo code? I don't care if
>> the solution is not typesafe with respect to generics.
>>
>> thanks for any pointers.
>>
>> Joe
>>
>> ---------------------------------------------------------------------
>> 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
>
>

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Users

Re: List of named components as arg to constructor param

2009-09-12T07:57:44Z

pico = new DefaultPicoContainer(new NullComponentMonitor() {

public Object noComponentFound(MutablePicoContainer container,
Object componentKey);
String[] keys = componentKey.split(",");
List<Element>() elements = new ArrayList<Element>();
for (String key in keys) {
elements.add(container.get(key));
}
return new Composition(elements);
}

});

pico.addComponent("elementA", Element.class, new ConstantParameter
("configA"))
pico.addComponent("elementB", Element.class, new ConstantParameter
("configB"))
pico.addComponent("elementC", Element.class, new ConstantParameter
("configC"))

abComposition = pico.getComponent("elementA,elementB");
bcComposition = pico.getComponent("elementB,elementC");

-----

No need to add Composition to the container for this specialized case,
it'll be cached anyway for the key in question, unless you don't do
caching in the PicoContainer setup. You obviously have to be
comfortable with participating in the List creation.

You could aim at some smaller language in the missing key definition ,
of you were prepared to do more string processing in the
noComponentFound(..).

abComposition = pico.getComponent("A,B");
abComposition = pico.getComponent("AB");
abComposition = pico.getComponent("compositionAB");
abComposition = pico.getComponent("elems(A,B)");

Regards,

- Paul

On Sep 11, 2009, at 5:38 AM, joe panico wrote:

> Hello,
>
> I'm using PicoContainer 2.8.3.
>
> I would like Pico to explicitly wire specific named (keyed) components
> into a constructor arg for a List type param. For example:
>
> class Element{
> private final String config;
> public Element(String config){
> this.config = config
> }
> }
>
> class Composition{
> private final List<Element> elements;
> public Composition(List<Element> elements){
> this.elements = elements
> }
> }
>
> pico.addComponent("elementA", Element.class, new ConstantParameter
> ("configA"))
> pico.addComponent("elementB", Element.class, new ConstantParameter
> ("configB"))
> pico.addComponent("elementC", Element.class, new ConstantParameter
> ("configC"))
>
> pico.addComponent("compositionAB", Composition.class, ?tell it to use
> keys "elementA" + "elementB"?)
> pico.addComponent("compositionBC", Composition.class, ?tell it to use
> keys "elementB" + "elementC"?)
>
> How do I achieve those last two lines of pseudo code? I don't care if
> the solution is not typesafe with respect to generics.
>
> thanks for any pointers.
>
> Joe
>
> ---------------------------------------------------------------------
> 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

From forum: NanoContainer - PicoContainer - Users

List of named components as arg to constructor param

2009-09-11T03:38:44Z

Hello,

I'm using PicoContainer 2.8.3.

I would like Pico to explicitly wire specific named (keyed) components
into a constructor arg for a List type param. For example:

class Element{
private final String config;
public Element(String config){
this.config = config
}
}

class Composition{
private final List<Element> elements;
public Composition(List<Element> elements){
this.elements = elements
}
}

pico.addComponent("elementA", Element.class, new ConstantParameter("configA"))
pico.addComponent("elementB", Element.class, new ConstantParameter("configB"))
pico.addComponent("elementC", Element.class, new ConstantParameter("configC"))

pico.addComponent("compositionAB", Composition.class, ?tell it to use
keys "elementA" + "elementB"?)
pico.addComponent("compositionBC", Composition.class, ?tell it to use
keys "elementB" + "elementC"?)

How do I achieve those last two lines of pseudo code? I don't care if
the solution is not typesafe with respect to generics.

thanks for any pointers.

Joe

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Users

Null Parameter Question asked on User List

2009-09-05T11:01:02Z

Re: http://jira.codehaus.org/browse/PICO-364

I wanted to ask you guys before changing this.

Since Paul refactored the Parameter return type, shouldn't it be safe to say
that SingleMemberInjector.isNullParamAllowed() is an obsolete method?

Instead, we would just check that Parameter.Resolver.isResolved() is true, and
accept whatever value the Parameter returns?

To me that's a bit of a behavior change and wanted to ask you guys first.

Thanks,
-Mike

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

http://xircles.codehaus.org/manage_email

From forum: NanoContainer - PicoContainer - Dev