[jboss-dev] Way to scan for classes that extend or implement

[Ales Justin]

> No, not annotation on anntation.  Please look at the example below again.

That's what I meant by contradiction.
Your example wasn't backing up what you said you impled / need.
But OK, we're on the same page now. ;-)

> JAX-RS services are identified via the @Path annotation, just like EJB's 
> are identified with @Stateless or @Stateful.
> 
> The different is that the @Path annotation can either be on the class, 
> or an implemented interface.
> 
> This does not exist in the scanner framework ATM, AFAICT.

Sure it does, see my pseudo code below.

First you get all the classes that are annotated with @Path.
Either they are interfaces or direct classes.
Then you can get super classes of these annotated classes.

You need some checks where exactly is the @PAth annotation,
but that should be trivial.

> Ales Justin wrote:
>> You can already do this with existing indexes.
>> 
>> AnnIndex ai = ...;
>> Set<Class> annClasses = ai.classHasAnnotation(Path.class.getName());
>> 
>> HierarchyIndex hi = ...;
>> for (Class annClass : annClasses)
>> {
>>   Set<Class> hieClasses - hi.getSuperTypes(annClass);
>>   ...
>> }
>> 
>> Actually, you're in contradiction here:
>> * "classes that implement anntotations that are annotated with"
>> * MyResource is not an annotation
>> 
>> For "annotation on annotation" one could simply use the AI twice.
>> 
>> On Jun 14, 2010, at 3:43 PM, Bill Burke wrote:
>> 
>>> I also have written a scanner plugin that indexes classes that implement 
>>> anntotations that are annotated with:
>>> 
>>> i.e.
>>> 
>>> @Path
>>> public interface MyResource {}
>>> 
>>> public class MyResourceImpl implements MyResource {}
>>> 
>>> 
>>> Set<String> classes = 
>>> interfaceIndex.getAnntoationIndex(Path.class.getName())
>>> 
>>> 
>>> 
>>> Ales Justin wrote:
>>>> I've fixed this in scanning trunk, so you don't need the url anymore.
>>>> If null, the whole deployment unit's owning classpath will be checked.
>>>> 
>>>> For the moment you can use the scanning trunk's snapshot - the api is still the same,
>>>> and I'll try to do new release asap -- need to fix some CL & Deployers issue before doing the whole cycle.
>>>> 
>>>> 
>>>> On Jun 11, 2010, at 10:46 PM, Rémy Maucherat wrote:
>>>> 
>>>>> On Fri, Jun 11, 2010 at 5:35 PM, Bill Burke <bburke at redhat.com> wrote:
>>>>>> Hmmm, where you get the classpathItem from then?  AnnotationIndex
>>>>>> doesn't require for you to provide this info.
>>>>> It's just a regular VirtualFile to the JAR or exploded folder. For the
>>>>> classpath you could do:
>>>>> List<VirtualFile> classpath = (VFSDeploymentUnit) unit.getClassPath();
>>>>> 
>>>>> Rémy
>>>>> 
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>> 
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>> -- 
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> 
>>> 
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>> 
>> 
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 
> 
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development