Hey Pete,

I took a first shot a the JavaConfig prototype and it seems to be working well. I had to refactor a bit to decouple some implementation classes and add some interfaces to add it in a clean way, hope that's ok with you. I notice a difference of about 2 seconds on startup time of a small project :-)

Take a look here for the general idea: https://github.com/paulbakker/core/commit/03c615b43f2ea682e1dd9ee584bea8ab86afc76f

The code is still a bit messy (some sysouts etc...) but I'm happy the idea seems to be working at least, I'll clean the code up tomorrow.

A user would have to change the following in the web.xml:

<!-- The class that implements WeldContext -->
<context-param>
       <param-name>weld.javaconfig.class</param-name>
       <param-value>org.nljug.cfp.WeldApplicationContext</param-value>
   </context-param>

<!-- Instead of the standard Listener -->
   <listener>
       <listener-class>org.jboss.weld.environment.servlet.JavaConfigListener</listener-class>
   </listener>

I have a vague idea how to solve the wildcard problem too. Maybe we can add another method to the WeldContext class: 'registerPackages' that returns a list of Strings of package names. Using these strings we can scan selectively in those packages.

Paul


________________________________________
From: Pete Muir [pmuir@redhat.com]

Sent: 12 November 2010 18:14
To: Paul Bakker
Cc: weld-dev@lists.jboss.org
Subject: Re: Specifying the classes to install

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


_______________________________________________
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev