Yeah, it's missing stuff :-) But what you said in your email looks good (though I think that we can predicate using java config on just the context param, not need to change the listener as well).
Ales and I talked about this idea for scanning packages, and we don't think we have enough control of how the CL works to be able to scan for packages without doing most/all of the work of scanning everything... On 13 Nov 2010, at 14:35, Ales Justin wrote: > The commit looks partial -- I only see two changes, and no > DefaultServletDeployment, WeldContext, ... > * > https://github.com/paulbakker/core/tree/master/environments/servlet/core/src/main/java/org/jboss/weld/environment/servlet > > On Sat, Nov 13, 2010 at 3:17 PM, Paul Bakker <[email protected]> wrote: > 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 [[email protected]] > Sent: 12 November 2010 18:14 > To: Paul Bakker > Cc: [email protected] > 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 [[email protected]] > > Sent: 12 November 2010 17:05 > > To: Pete Muir > > Cc: Paul Bakker; [email protected] > > 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/weld-dev > _______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
