You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Clement Escoffier <cl...@gmail.com> on 2013/05/01 09:24:15 UTC

Re: [iPOJO] Usage of @Requires in superclass

Hi,

As Neil said, the current annotation processing would too brittle if we try to analyze parent classes.
So unfortunately, no, @Requires from parent classes are not processed.

However we have plan to implement this support in iPOJO 2.x (work already started).

Regards,

Clement

On 30 avr. 2013, at 22:43, Neil Bartlett <nj...@gmail.com> wrote:

> I'm speculating here, but I imagine iPOJO doesn't handle this for the
> same reason that bnd doesn't. Both analyze the annotations at
> build-time to generate the runtime metadata (and in iPOJO's case,
> injected bytecodes). At build time, the only class we can guarantee to
> have visibility of is the actual component class that is being
> analyzed; we may not have visibility of the full super-class
> hierarchy. Therefore to ensure consistency, only the direct
> annotations on the component class are considered.
> 
> If we also considered annotations on the super-classes, then this
> would sometimes work but sometimes NOT work, depending on a fairly
> arbitrary and poorly-controlled aspect of the build environment.
> 
> Neil
> 
> On Tue, Apr 30, 2013 at 7:42 PM, lessonz <le...@gmail.com> wrote:
>> My understanding is it has nothing to do with iPOJO and everything to do
>> with how Java handles annotations.
>> On Apr 30, 2013 12:34 PM, "Michiel Vermandel" <mv...@yahoo.com> wrote:
>> 
>>> Thanks
>>> Would be nice if it could.
>>> But I'm quite new to iPOJO. Maybe I can't yet grasp the reason for this...
>>> 
>>> 
>>> -----------------
>>> http://www.codessentials.com - Your essential software, for free!
>>> Follow us at http://twitter.com/#!/Codessentials
>>> 
>>> 
>>> ________________________________
>>> From: lessonz <le...@gmail.com>
>>> To: users@felix.apache.org; Michiel Vermandel <mv...@yahoo.com>
>>> Sent: Tuesday, April 30, 2013 6:44 PM
>>> Subject: Re: [iPOJO] Usage of @Requires in superclass
>>> 
>>> 
>>> It's been my experience this does not work.
>>> 
>>> 
>>> On Tue, Apr 30, 2013 at 6:12 AM, Michiel Vermandel <mvermand@yahoo.com
>>>> wrote:
>>> 
>>>> Hello,
>>>> 
>>>> Can I use @Requires on a field of a (Abstract) class that will be
>>> extended?
>>>> Of course only the extending classes will be instantiated.
>>>> 
>>>> Thank you
>>>> 
>>>> 
>>>> -----------------
>>>> http://www.codessentials.com - Your essential software, for free!
>>>> Follow us at http://twitter.com/#!/Codessentials
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: [iPOJO] Usage of @Requires in superclass

Posted by lessonz <le...@gmail.com>.
Is there an issue filed somewhere we can follow?


On Wed, May 1, 2013 at 1:24 AM, Clement Escoffier <
clement.escoffier@gmail.com> wrote:

> Hi,
>
> As Neil said, the current annotation processing would too brittle if we
> try to analyze parent classes.
> So unfortunately, no, @Requires from parent classes are not processed.
>
> However we have plan to implement this support in iPOJO 2.x (work already
> started).
>
> Regards,
>
> Clement
>
> On 30 avr. 2013, at 22:43, Neil Bartlett <nj...@gmail.com> wrote:
>
> > I'm speculating here, but I imagine iPOJO doesn't handle this for the
> > same reason that bnd doesn't. Both analyze the annotations at
> > build-time to generate the runtime metadata (and in iPOJO's case,
> > injected bytecodes). At build time, the only class we can guarantee to
> > have visibility of is the actual component class that is being
> > analyzed; we may not have visibility of the full super-class
> > hierarchy. Therefore to ensure consistency, only the direct
> > annotations on the component class are considered.
> >
> > If we also considered annotations on the super-classes, then this
> > would sometimes work but sometimes NOT work, depending on a fairly
> > arbitrary and poorly-controlled aspect of the build environment.
> >
> > Neil
> >
> > On Tue, Apr 30, 2013 at 7:42 PM, lessonz <le...@gmail.com>
> wrote:
> >> My understanding is it has nothing to do with iPOJO and everything to do
> >> with how Java handles annotations.
> >> On Apr 30, 2013 12:34 PM, "Michiel Vermandel" <mv...@yahoo.com>
> wrote:
> >>
> >>> Thanks
> >>> Would be nice if it could.
> >>> But I'm quite new to iPOJO. Maybe I can't yet grasp the reason for
> this...
> >>>
> >>>
> >>> -----------------
> >>> http://www.codessentials.com - Your essential software, for free!
> >>> Follow us at http://twitter.com/#!/Codessentials
> >>>
> >>>
> >>> ________________________________
> >>> From: lessonz <le...@gmail.com>
> >>> To: users@felix.apache.org; Michiel Vermandel <mv...@yahoo.com>
> >>> Sent: Tuesday, April 30, 2013 6:44 PM
> >>> Subject: Re: [iPOJO] Usage of @Requires in superclass
> >>>
> >>>
> >>> It's been my experience this does not work.
> >>>
> >>>
> >>> On Tue, Apr 30, 2013 at 6:12 AM, Michiel Vermandel <mvermand@yahoo.com
> >>>> wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> Can I use @Requires on a field of a (Abstract) class that will be
> >>> extended?
> >>>> Of course only the extending classes will be instantiated.
> >>>>
> >>>> Thank you
> >>>>
> >>>>
> >>>> -----------------
> >>>> http://www.codessentials.com - Your essential software, for free!
> >>>> Follow us at http://twitter.com/#!/Codessentials
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>