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(a)redhat.com]
Sent: 12 November 2010 17:05
To: Pete Muir
Cc: Paul Bakker; weld-dev(a)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