[weld-dev] Specifying the classes to install

[Pete Muir]

Yes, that's exactly what we were thinking of for the "Java API". I argued exactly the same point about the refactoring as well :-)

And the tool is for just that reason -- maybe we can even reuse the existing beans.xml excludes syntax, and apply the excludes that we can (i.e. not the ones conditional upon the runtime env) at that point, via this generated class.

So, prototype away!

Also, can you sign a cla at cla.jboss.org?

On 12 Nov 2010, at 17:03, Paul Bakker wrote:

> I think the following might work:
> 
> 1- Introduce an interface 'WeldApplication' with a method: Class<?>[] registerClasses();
> 2- A user implements this interface and returns an array of class literals for all classes that should become managed.
> 3- Register the user's implementation as a context-param in web.xml
> 4- Check if this parameter is set in the ServletListener, and if it is, instantiate it. We can now completely skip scanning and just go forward with the classes specified by registerClasses().
> 
> I believe a Java class is a lot more user friendly then a plain text file because it's type safe. It will at least not brake if you refactor a class name. We could still provide a tool to generate this kind of class because the lack of wildcards might be unconfinient for larger applications. 
> 
> What do you think? If this idea generally fits your idea about it I can try to prototype it this weekend.
> 
> Paul
> 
> ________________________________________
> From: Pete Muir [pmuir at redhat.com]
> Sent: 12 November 2010 17:05
> To: Pete Muir
> Cc: Paul Bakker; weld-dev at lists.jboss.org
> Subject: Specifying the classes to install
> 
> On 11 Nov 2010, at 12:54, Pete Muir wrote:
> 
>> 
>> On 10 Nov 2010, at 21:59, Paul Bakker wrote:
>> 
>>> It's not easy to drop because it's part of the CDI spec I guess. But besides that I don't think it's a conceptual problem, it has a lot of advantages (injecting third party classes for example). In some cases (when startup times are important, e.g. on GAE) it would be nice to override this behavior though.
>> 
>> Agreed, Ales has started prototyping this in Weld already :-)
> 
> Ales and I discussed this on IM. Points of note:
> 
> * The deployment for Weld is split up like:
> 
>  1) scan classloader
>  2) load classes
>  3) send PAT events
>  4) create beans
> 
>  Weld already supports skipping (2), (3), (4) via the beans.xml support for excluding classes, so we have removed some overhead, but being able to skip (1) will help as well.
> 
> * We could introduce a Java API for this, where you can specify classes to load in a list, array or similar (refactor safe compared to a plain text file)
> 
> * You need to specify each class, no support for wildcards etc. here
> 
> * We could introduce a build-time tool that does support wildcards, and generates the plain text descriptor
> 
> * A build time tool would also fit well with the support for jandex that we want to add
> 
> Op dit e-mail bericht is de disclaimer van Info Support van toepassing, zie http://www.infosupport.com/disclaimer