"alesj" wrote : "david.lloyd(a)jboss.com" wrote : So we have to index all of them (unless there is some hint from the user that scanning is not necessary for a class or package or whatever) | | | Yes. | The restriction mechanism should be plugable, | and the one's I can think of right now are: | * OSGi manifest export header | * jboss-classloading.xml capabilities | Far simpler than designing a plugin mechanism for restrictions is to simplify the API so that you just give it the input streams of classes you want to index. Simplfying the API is usually preferable to adding an abstraction. "alesj" wrote : "david.lloyd(a)jboss.com" wrote : | | and remember (sans-classloading) where annotations are located, and the relationships between classes, so that we can find all classes and subclasses with certain annotations without actually loading any classes. | This sounds interesting, but what's the easiest way to achieve this? | I guess Javassist knows how to handle this. | How hard would it be to add this to Reflect ... | | But is this really necessary? | This should be done by tool anyway, | depending on explicitly provided dependencies (mvn, ant, ...), | so it should be easy to include all of the needed jars to make it run under UCL. | The specifications for many of our components (like EJB 3.1) tell us that we can't rely on this, or at least that's my understanding from the developer meeting when we decided we had to do it this way. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261305#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...