[weld-dev] A significantly negative article on Weld

[Mark Struberg]

Hi!

I filed

https://jira.jboss.org/browse/CDI-18

It contains the problem description as initial filling + a description of my idea how to solve it as a first comment. 

LieGrue,
strub

--- On Fri, 11/12/10, Pete Muir <pmuir at bleepbleep.org.uk> wrote:

> From: Pete Muir <pmuir at bleepbleep.org.uk>
> Subject: Re: [weld-dev] A significantly negative article on Weld
> To: "Mark Struberg" <struberg at yahoo.de>
> Cc: "Clint Popetz" <cpopetz at gmail.com>, "Samuel Mendenhall" <samuel.mendenhall at gmail.com>, "Weld Dev List" <weld-dev at lists.jboss.org>
> Date: Friday, November 12, 2010, 10:49 AM
> Hi Mark
> 
> On 12 November 2010 08:52, Mark Struberg <struberg at yahoo.de>
> wrote:
> > Hoi Pete!
> >
> > I think I first sent my caveat against it in a mail to
> the EG in dec 2009 or so. I also discussed this issue in
> length with Dan while we did our talk about CDI at the last
> JSFdays conference.
> >
> > The point is: the automatic @Dependent pickup does
> _NOT_ work for legacy classes anyway, because those jars
> doesn't contain a beans.xml!
> > So the whole _initial_ argument why we need this is
> simply wrong imo.
> 
> I'm not aware that this was the initial argument as to why
> they were
> needed, afaik, it was a decision about the design of the
> programming
> model. Gavin or another EG member maybe can comment on
> this.
> 
> > You are right of course that we would have to look at
> what happens to classes in a new project having a
> beans.xml.
> > From having 7 large projects with EE6 in production
> already (~2.000 classes, 500 JSF pages, serving > 1 mio
> page hits/day) I can tell you that all it would change for
> _my_ projects is that I could remove the @Typed() from those
> classes - because all the non-annotated classes I have get
> served via @Produces methods anyway ;)
> >
> 
> Well, this is your design decision, and not one that
> everyone makes for sure.
> 
> Regardless, your proposal does not touch on backwards
> compatibility in
> any way, and it can't be considered seriously until it
> does.
> 
> > For the performance:
> > true: we would have to pickup each class and scan if
> there is a scope annotation. We would also need to send the
> ProcessAnnotatedType SystemEvent for it.
> > But we would not need to do further scanning.
> 
> We would still want to send a ProcessAnnotatedType for
> every class,
> not just those with scope annotations for sure. This is
> part of what
> makes CDI's extensions so powerful.
> 
> >
> >
> > For the BDA definition for interceptors, decorators
> and alternatives:
> >
> > The spec says (example for alternatives):
> > "By default, a bean archive has no selected
> alternatives. An alternative must be explicitly declared
> using the <alternatives> element of the beans.xml file
> of the bean archive."
> >
> > Other sections of the spec also indicate that an
> <alternative> I do e.g. in a WEB-INF/beans.xml does
> NOT count for the jars in it's WEB-INF/lib folder.
> >
> > Thus if you like to enable an Alternative for your
> webapp you would need to REPACKAGE ALL YOUR JARS! Pardon the
> words, but this is bullshit and should get fixed ;) Same
> goes for interceptors and decorators.
> >
> > I think the original problem was Gavins issue with the
> interceptor order.
> > A possible solution would be to add optional ordinal
> and enabled attributes e.g.
> >
> > <interceptors ordinal="32">
> >
>  <class>org.myclass.MyInterceptor3</class>
> >
>  <class>org.myclass.MyOtherInterceptor</class>
> >  <class
> enabled="false">org.myclass.MyFirstInterceptor</class>
> > </interceptors>
> >
> > where <interceptors> sections with higher
> ordinals get applied later and thus being more 'important'.
> So if the default interceptor order you get with a jar
> doesn't fit your needs, you can still provide a beans.xml
> containing a fixed one with a higher ordinal.
> >
> 
> You are right, this was down to ordering issues, and I
> agree that it
> doesn't work out that well for extensions. Do you want to
> come up with
> a formal proposal attached to a CDI issue for the community
> to
> consider about how to take this forward? I would suggest
> starting with
> an informal description, and then refine to be a formal
> change using
> spec language.
> 
> Thanks!
>