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 <[email protected]> wrote: > From: Pete Muir <[email protected]> > Subject: Re: [weld-dev] A significantly negative article on Weld > To: "Mark Struberg" <[email protected]> > Cc: "Clint Popetz" <[email protected]>, "Samuel Mendenhall" > <[email protected]>, "Weld Dev List" <[email protected]> > Date: Friday, November 12, 2010, 10:49 AM > Hi Mark > > On 12 November 2010 08:52, Mark Struberg <[email protected]> > 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! > _______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
