You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Guillaume Sauthier (OW2/GMail)" <gu...@gmail.com> on 2013/02/01 10:21:33 UTC
Re: New IPojo Manipuator, Handler Annotation Management
Just to be crystal clear, if we enable this behavior for iPOJO custom
annotations, that will prevent the handler developer to access runtime
information about its annotation at runtime.
For example, let say that I have annotated my handler annotation, I will
not be able to ever read these data. Because if I want my custom annotation
to be considered a handler annotation, I have to set the @Retention to
CLASS.
Currently this is not an issue for iPOJO itself, I've checked our
annotations, and none have set the @Retention (default retention is CLASS).
ATM, I cannot think of another limitation.
WDYT ?
--G
2013/1/31 Göktürk Gezer <go...@gmail.com>
> On Thu, Jan 31, 2013 at 3:33 PM, Guillaume Sauthier (OW2/GMail) <
> guillaume.ow2@gmail.com> wrote:
>
> > Oh, I did not noticed that 'visible' attribute.
> >
> > If this check is limited to annotations that are matching ipojo custom
> > annotation, it may work.
> >
>
> Yes indeed.
>
>
> > But this have to be documented somewhere, stating that if the annotation
> of
> > a handler have a RUNTIME RetentionPolicy, it will be ignored by iPOJO.
> > Clement, WDYT ?
> >
>
> +1
>
>
> >
> > What is wrong is to judge that visible annotations cannot be handler
> > annotation at all just because they're also visible at runtime.
> >
>
> I think this is a safe bet. I don't see why someone would want to make
> ipojo handler annotation visible. Handlers will already see that
> annotation's attributes the hard way. But there are plenty of code out
> there those depend on reading the visible annotations through reflection.
> By putting visible annotations into metadata calculation we're prohibiting
> those use cases. Invisible attributes are on the other hand mostly used by
> frameworks to be accessed at compile time for audition and code generation
> like the IPojo itself.
>
> I believe this is necessary to let IPojo components interoperate with other
> runtime-annotation based code.
>
>
> Best,
> Gokturk
>
>
> > --G
> >
> >
> > 2013/1/31 Göktürk Gezer <go...@gmail.com>
> >
> > > If RetentionPolicy of a annotation is Runtime, It should be mapped to
> > below
> > > method in "visible" argument as I know:
> > > This is my modified version and works the way expected. I'm just
> > returning
> > > null when annotation is visible by judging just by looking at visible
> > > argument.
> > > I'm not sure if this "visible" argument is ever sent true when
> > > RetentionPolicy of a annotation is not RetentionPolicy.Runtime.
> > >
> > > /**
> > > * Visit class annotations.
> > > * This method detects @component and @provides annotations.
> > > * @param desc : annotation descriptor.
> > > * @param visible : is the annotation visible at runtime.
> > > * @return the annotation visitor.
> > > * @see
> > > org.objectweb.asm.ClassAdapter#visitAnnotation(java.lang.String,
> boolean)
> > > */
> > > public AnnotationVisitor visitAnnotation(String desc, boolean
> > visible)
> > > {
> > >
> > > /*
> > > * Visible annotations are mostly destined to be read by
> reflection
> > > * at runtime. We retain runtime visible annotations on component
> > > * as they are and left them out in meta-data calculation.
> > > */
> > > if(visible){
> > > return null;
> > > }
> > >
> > > // Return the visitor to be executed (may be null)
> > > return registry.selection(workbench)
> > > .type(node)
> > > .annotatedWith(desc)
> > > .get();
> > > }
> > >
> > > On Thu, Jan 31, 2013 at 12:02 PM, Guillaume Sauthier (Objectweb) <
> > > guillaume.sauthier@objectweb.org> wrote:
> > >
> > > > Hmmm
> > > >
> > > > The issue is that during manipulation, we d'ont have access to the
> > > > metadata of the annotation (retention policy for example).
> > > > What I can propose is to create a new manipulator module with an
> empty
> > > > binding just for your annotation.
> > > > With this, the manipulator will call your empty binding, and no
> handler
> > > > metadata will be generated.
> > > > So effectively, it will ignore your annotation (even if it matches
> the
> > > > custom iPOJO annotation processing)
> > > >
> > > > --G
> > > >
> > > >
> > > > 2013/1/30 Göktürk Gezer <go...@gmail.com>
> > > >
> > > >> No, there is no problem associated with backward compatibility.
> > > >> Actually this is the default behaviour with the old one too.
> > > >>
> > > >> What i'm suggesting is : once some class is annotated with
> @Component,
> > > >> all other annotations on this type are treated as handlers and there
> > > >> must be a backing handler to use that component. What I want is to
> be
> > > >> able to put annotations on components which is not handler but to be
> > > >> read in runtime by reflection. So if we left out annotations with
> > > >> runtime retentency in metadata calculation, we're golden. Besides
> > > >> runtime annotations are by their nature should be treated this way
> > IMO.
> > > >>
> > > >>
> > > >> Gokturk From: Guillaume Sauthier (Objectweb)
> > > >> Sent: 1/30/2013 12:50 PM
> > > >>
> > > >> To: dev@felix.apache.org
> > > >> Subject: Re: New IPojo Manipuator, Handler Annotation Management
> > > >> Sorry, I didn't understand the issue.
> > > >> Are you seeing a problem for the old style custom annotation support
> > > >> (looking for annotation with either handler or ipojo in their name)
> ?
> > > >> --G
> > > >>
> > > >>
> > > >> 2013/1/29 Göktürk Gezer <go...@gmail.com>
> > > >>
> > > >> > Hi,
> > > >> >
> > > >> > New IPojo manipulator picks all annotations for type as handler to
> > > wire
> > > >> > them into @Component annotation. This creates a problem when some
> > > >> > annotation is used in component type but not intended as handler
> > > >> purposes.
> > > >> >
> > > >> > I think we should exclude annotations with run-time retention
> policy
> > > >> from
> > > >> > handler metadatas. WDYT?
> > > >> >
> > > >> >
> > > >> > Regards,
> > > >> > Gokturk
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
Re: New IPojo Manipuator, Handler Annotation Management
Posted by Göktürk Gezer <go...@gmail.com>.
Hi
On Fri, Feb 1, 2013 at 11:21 AM, Guillaume Sauthier (OW2/GMail) <
guillaume.ow2@gmail.com> wrote:
> Just to be crystal clear, if we enable this behavior for iPOJO custom
> annotations, that will prevent the handler developer to access runtime
> information about its annotation at runtime.
>
Handler itself will access those information because those information will
be at generated metadata for component.
> For example, let say that I have annotated my handler annotation, I will
> not be able to ever read these data. Because if I want my custom annotation
> to be considered a handler annotation, I have to set the @Retention to
> CLASS.
>
If we're annotating a handler annotation for runtime usage we can embed
those annotation into main handler annotation as attributes, and handler
can see them in generated metadata. Which would be better design approach
IMO.
However detaching IPojo components from all existing codes those depend on
visible annotations is something we wouldn't want to do.
>
> Currently this is not an issue for iPOJO itself, I've checked our
> annotations, and none have set the @Retention (default retention is CLASS).
>
Yes I doubled the check to be sure.
>
> ATM, I cannot think of another limitation.
>
Me neither.
> WDYT ?
> --G
>
>
> 2013/1/31 Göktürk Gezer <go...@gmail.com>
>
> > On Thu, Jan 31, 2013 at 3:33 PM, Guillaume Sauthier (OW2/GMail) <
> > guillaume.ow2@gmail.com> wrote:
> >
> > > Oh, I did not noticed that 'visible' attribute.
> > >
> > > If this check is limited to annotations that are matching ipojo custom
> > > annotation, it may work.
> > >
> >
> > Yes indeed.
> >
> >
> > > But this have to be documented somewhere, stating that if the
> annotation
> > of
> > > a handler have a RUNTIME RetentionPolicy, it will be ignored by iPOJO.
> > > Clement, WDYT ?
> > >
> >
> > +1
> >
> >
> > >
> > > What is wrong is to judge that visible annotations cannot be handler
> > > annotation at all just because they're also visible at runtime.
> > >
> >
> > I think this is a safe bet. I don't see why someone would want to make
> > ipojo handler annotation visible. Handlers will already see that
> > annotation's attributes the hard way. But there are plenty of code out
> > there those depend on reading the visible annotations through reflection.
> > By putting visible annotations into metadata calculation we're
> prohibiting
> > those use cases. Invisible attributes are on the other hand mostly used
> by
> > frameworks to be accessed at compile time for audition and code
> generation
> > like the IPojo itself.
> >
> > I believe this is necessary to let IPojo components interoperate with
> other
> > runtime-annotation based code.
> >
> >
> > Best,
> > Gokturk
> >
> >
> > > --G
> > >
> > >
> > > 2013/1/31 Göktürk Gezer <go...@gmail.com>
> > >
> > > > If RetentionPolicy of a annotation is Runtime, It should be mapped to
> > > below
> > > > method in "visible" argument as I know:
> > > > This is my modified version and works the way expected. I'm just
> > > returning
> > > > null when annotation is visible by judging just by looking at visible
> > > > argument.
> > > > I'm not sure if this "visible" argument is ever sent true when
> > > > RetentionPolicy of a annotation is not RetentionPolicy.Runtime.
> > > >
> > > > /**
> > > > * Visit class annotations.
> > > > * This method detects @component and @provides annotations.
> > > > * @param desc : annotation descriptor.
> > > > * @param visible : is the annotation visible at runtime.
> > > > * @return the annotation visitor.
> > > > * @see
> > > > org.objectweb.asm.ClassAdapter#visitAnnotation(java.lang.String,
> > boolean)
> > > > */
> > > > public AnnotationVisitor visitAnnotation(String desc, boolean
> > > visible)
> > > > {
> > > >
> > > > /*
> > > > * Visible annotations are mostly destined to be read by
> > reflection
> > > > * at runtime. We retain runtime visible annotations on
> component
> > > > * as they are and left them out in meta-data calculation.
> > > > */
> > > > if(visible){
> > > > return null;
> > > > }
> > > >
> > > > // Return the visitor to be executed (may be null)
> > > > return registry.selection(workbench)
> > > > .type(node)
> > > > .annotatedWith(desc)
> > > > .get();
> > > > }
> > > >
> > > > On Thu, Jan 31, 2013 at 12:02 PM, Guillaume Sauthier (Objectweb) <
> > > > guillaume.sauthier@objectweb.org> wrote:
> > > >
> > > > > Hmmm
> > > > >
> > > > > The issue is that during manipulation, we d'ont have access to the
> > > > > metadata of the annotation (retention policy for example).
> > > > > What I can propose is to create a new manipulator module with an
> > empty
> > > > > binding just for your annotation.
> > > > > With this, the manipulator will call your empty binding, and no
> > handler
> > > > > metadata will be generated.
> > > > > So effectively, it will ignore your annotation (even if it matches
> > the
> > > > > custom iPOJO annotation processing)
> > > > >
> > > > > --G
> > > > >
> > > > >
> > > > > 2013/1/30 Göktürk Gezer <go...@gmail.com>
> > > > >
> > > > >> No, there is no problem associated with backward compatibility.
> > > > >> Actually this is the default behaviour with the old one too.
> > > > >>
> > > > >> What i'm suggesting is : once some class is annotated with
> > @Component,
> > > > >> all other annotations on this type are treated as handlers and
> there
> > > > >> must be a backing handler to use that component. What I want is to
> > be
> > > > >> able to put annotations on components which is not handler but to
> be
> > > > >> read in runtime by reflection. So if we left out annotations with
> > > > >> runtime retentency in metadata calculation, we're golden. Besides
> > > > >> runtime annotations are by their nature should be treated this way
> > > IMO.
> > > > >>
> > > > >>
> > > > >> Gokturk From: Guillaume Sauthier (Objectweb)
> > > > >> Sent: 1/30/2013 12:50 PM
> > > > >>
> > > > >> To: dev@felix.apache.org
> > > > >> Subject: Re: New IPojo Manipuator, Handler Annotation Management
> > > > >> Sorry, I didn't understand the issue.
> > > > >> Are you seeing a problem for the old style custom annotation
> support
> > > > >> (looking for annotation with either handler or ipojo in their
> name)
> > ?
> > > > >> --G
> > > > >>
> > > > >>
> > > > >> 2013/1/29 Göktürk Gezer <go...@gmail.com>
> > > > >>
> > > > >> > Hi,
> > > > >> >
> > > > >> > New IPojo manipulator picks all annotations for type as handler
> to
> > > > wire
> > > > >> > them into @Component annotation. This creates a problem when
> some
> > > > >> > annotation is used in component type but not intended as handler
> > > > >> purposes.
> > > > >> >
> > > > >> > I think we should exclude annotations with run-time retention
> > policy
> > > > >> from
> > > > >> > handler metadatas. WDYT?
> > > > >> >
> > > > >> >
> > > > >> > Regards,
> > > > >> > Gokturk
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>