[weld-dev] A significantly negative article on Weld

[Pete Muir]

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!