Re: [webbeans-dev] Web Bean discovery

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