[webbeans-dev] Web Bean discovery

Pete Muir pmuir at redhat.com
Thu Dec 4 11:11:41 EST 2008


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 at redhat.com> 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/microcontainer/src/main/java/org/jboss/webbeans/integration/microcontainer/WebBeanDiscoveryDeployer.java
>>>
>>> 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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>>>
>>> _______________________________________________
>>> webbeans-dev mailing list
>>> webbeans-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>>
>> _______________________________________________
>> webbeans-dev mailing list
>> webbeans-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>>
>
>
>
> -- 
> Gavin King
> gavin.king at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev




More information about the weld-dev mailing list