Hi Caspar, Thanks for the idea, I did not consider ASM. Since it reads bytecode it will be able to access those annotations and that is confirmed by the docs.
Thanks. Robert > -----Original Message----- > From: Caspar MacRae [mailto:[email protected]] > Sent: Friday, April 13, 2012 5:32 PM > To: [email protected] > Subject: Re: Proposal to make org.apache.felix.scr.annotations > available at Runtime > > Hi Robert, > > Apologies, I didn't read the spec in detail. As it's for unit tests > you > could access the runtime annotations with ASM? > > cheers, > Caspar > > > On 13 April 2012 14:03, Robert Munteanu <[email protected]> wrote: > > > Hi Caspar, > > > > Thanks for your reply. I've glanced over > > http://www.osgi.org/download/osgi-early-draft-2011-09.pdf and noticed > > that the annotations are defined with > > @Retention(value=RetentionPolicy.CLASS) . I've also found that the > same > > will happen with the SCR annotations from Felix in the next release ( > > https://issues.apache.org/jira/browse/FELIX-3247 ) . > > > > That means that the annotations will not be available at runtime, so > I > > will not be able to configure components by myself in unit tests. I > assume > > that Felix annotations will follow the official ones, so it makes > little > > sense to argue for making them available at runtime. > > > > Robert > > > > > -----Original Message----- > > > From: Caspar MacRae [mailto:[email protected]] > > > Sent: Friday, April 13, 2012 3:48 PM > > > To: [email protected] > > > Subject: Re: Proposal to make org.apache.felix.scr.annotations > > > available at Runtime > > > > > > Hi Robert, > > > > > > In a broader scope this will happen for RFC 0172 Declarative > Services > > > Annotations (runtime processing of SCR components), however this > brings > > > with it standardised annotations. > > > > > > cheers, > > > Caspar > > > > > > > > > On 13 April 2012 13:33, Robert Munteanu <[email protected]> wrote: > > > > > > > Hi, > > > > > > > > I've noticed that the annotations from > > > org.apache.felix.scr.annotations > > > > are declared with @Retention(RetentionPolicy.SOURCE) . I think > the > > > > following use cases would benefit from the annotations being > > > available at > > > > runtime . > > > > > > > > 1. Configuring component instances outside a OSGi container > > > > > > > > I often develop components which I want to test in plain JUnit > tests > > > > rather than in a container. These components have references > which I > > > need > > > > to satisfy in order for the unit test to run. Since the > annotations > > > are > > > > available only in the source file, I am unable to inspect the > > > declared > > > > references and inject them in a generic manner. > > > > > > > > The alternative is to manually configure each reference, but that > > > gets > > > > tedious pretty fast. > > > > > > > > 2. Processing SCR annotations in a JSR-269 annotation processor > > > > > > > > Having the annotations available to the processor ( strictly > speaking > > > only > > > > RetentionPolicy.CLASS is required ) would allow much simpler > > > integration of > > > > SCR processing since the processor would only need to be > available as > > > a JAR > > > > on the compile classpath, rather than a separate maven plugin > > > invocation or > > > > explicit ant task call. > > > > > > > > Above the other two use cases, having annotations at runtime can > > > generally > > > > ease integration with other systems which can inspect the > component > > > > configuration at runtime. > > > > > > > > The single downside that I see is that the annotations will > increase > > > the > > > > file size of the deployed bundles ( although I don't think it > will be > > > a > > > > huge increase ). > > > > > > > > I'm willing to prepare a patch, but would like your opinion > first. > > > > > > > > Thanks, > > > > > > > > Robert > > > > > >
