Re: [webbeans-dev] Web Bean discovery

Gavin, I need to better understand the use-cases we are trying to address here - I've been over this again, and there is no way I can see to build a flexible class discovery system that performs well without understanding what sort of conditions/restrictions we want to impose. So far, I have: * abstract classes * non-abstract classes (simple/enterprise beans) * annotations annotated with the some meta-annotations (e.g. stereotypes) What else? Pete On 26 Nov 2008, at 17:42, Gavin King wrote: > Right, it is important that any jboss-specific functionality is > abstracted. > > On Wed, Nov 26, 2008 at 7:45 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: >> >> Ok - so we would need to wrap this ClassFilter in an equivalent Web Beans >> API I think, and then use Javassist as you suggest. Any idea how portable >> such an approach will be to other app servers? >> >> On 26 Nov 2008, at 18:29, Ales Justin wrote: >> >>> 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 >>> >>> _______________________________________________ >>> webbeans-dev mailing list >>> webbeans-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/webbeans-dev >> >> _______________________________________________ >> webbeans-dev mailing list >> webbeans-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/webbeans-dev >> > > > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > _______________________________________________ > webbeans-dev mailing list > webbeans-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/webbeans-dev _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev