[weld-dev] Specifying the classes to install

[Ales Justin]

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 <paulb at infosupport.com> 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 [pmuir at redhat.com]
> Sent: 12 November 2010 18:14
> To: Paul Bakker
> Cc: weld-dev at 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 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
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20101113/b969a6f9/attachment-0001.html