This is trivial to do in JBoss5. ;-)
http://anonsvn.jboss.org/repos/jbossas/projects/webbeans-ri-int/trunk/mic...
module.visit(visitor, ClassFilter.INSTANCE, null, urls.toArray(new
URL[urls.size()]));
You only need to replace this ClassFilter parameter.
e.g. some Javassist based filter --> no need to load the class to inspect it
You could then organize your 'store' accordingly to the filter.
e.g. CombinedFilter(modifier, type, ...) --> push to sub-store
Pete Muir wrote:
I was talking to Gavin about this, and he suggested that the
discovery
should be more flexible and allow selectors/restrictions to be applied
to the classes discovered (for example, only abstract classes).
I can only speak about JBoss5, but I suspect this approach is common -
JBoss allows you to attach a visitor to the deployer and allows you to
do something with classes it finds (e.g. store them in some data
structure). This happens before web apps (from the Servlet listener)
starts.
The current approach is to discover the resources needed (as defined by
the spec) and store them in a datastructure, which is available later
for querying when we boot the Web Beans RI through the ServletListener.
So, the only way I can see to be more flexible is to add the ability to
apply selectors to the WebBeanDiscovery interface, and index the classes
discovered based on selectors in the jboss-webbeans integration library.
This requires us to define the selectors we can use. We already have:
* Modifier (for discovering abstract classes)
* TYPE annotations
are there any others we are likely to need - it is better to define
these upfront before we do a release of the WebBeanDiscovery API...
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev