[weld-dev] A significantly negative article on Weld

Mark Struberg struberg at yahoo.de
Fri Nov 12 03:52:42 EST 2010 

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. 

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 ;)

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. 


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.

LieGrue,
strub


--- On Thu, 11/11/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: Thursday, November 11, 2010, 12:48 PM
> There is no way I can see that *any*
> future release of CDI (MR or full JSR) can change the
> behaviour so that you have to explicitly specify @Dependent
> to have it picked up as a bean, without majorly breaking
> backwards compatibility, which is something a JCP spec
> cannot do. And this, even if there was consensus that this
> was the right thing to do, which there certainly isn't.
> Further, I'm not really convinced this would have any real
> effect on startup time or memory usage that we can't achieve
> by better design in the implementations anyway. For example,
> even if we did make this change to provide container startup
> events for all classes we have to scan all classes anyway
> (and only firing events for annotated classes would be
> another large change in design of CDI as well as a big
> reduction in functionality.
> 
> So, IMO, not worth spending time even considering this,
> because it's not going to happen :-) (at least, as the
> default operation mode, it could be an optional mode but
> then easier for a container to just support it if they want
> to).
> 
> I'm not sure quite what you mean by "he BDA definition for
> interceptors, alternatives and decorators should get
> tweaked", have you filed a spec issue in the issue tracker
> for this, along with a proposal we can look at?
> 
> On 10 Nov 2010, at 21:59, Mark Struberg wrote:
> 
> > yes Clint, but that's nonsense anyway! Just take any
> 3rd party jar you like and try to inject it. It WONT work,
> because there is no beans.xml in there... So it really boils
> down to be unnecessary overhead.
> > 
> > @Stu
> >> We do this because this is what the spec says we
> have to do :-)
> > 
> > So let's fix the spec in those areas ;) JSR-299 is
> mainly really rock solid, but the automatically picking up
> @Dependent beans + the BDA definition for interceptors,
> alternatives and decorators should get tweaked in a
> maintenance release pretty quickly. 
> > 
> > LieGrue,
> > strub 
> > 
> > --- On Wed, 11/10/10, Clint Popetz <cpopetz at gmail.com>
> wrote:
> > 
> >> From: Clint Popetz <cpopetz at gmail.com>
> >> Subject: Re: [weld-dev] A significantly negative
> article on Weld
> >> To: "Mark Struberg" <struberg at yahoo.de>
> >> Cc: "Pete Muir" <pmuir at bleepbleep.org.uk>,
> "Stuart Douglas" <stuart.w.douglas at gmail.com>,
> "Samuel Mendenhall" <samuel.mendenhall at gmail.com>,
> "Weld Dev List" <weld-dev at lists.jboss.org>
> >> Date: Wednesday, November 10, 2010, 8:52 PM
> >> If you go that route, you lose the
> >> ability to inject instances of
> >> third party classes without defining a @Produces
> >> method.  That may be
> >> preferable to the existing problems caused by
> default
> >> @Dependents, but
> >> I wanted to point it out for clarity.
> >> 
> >> -Clint
> >> 
> >> On Wed, Nov 10, 2010 at 2:46 PM, Mark Struberg
> <struberg at yahoo.de>
> >> wrote:
> >>> Sorry to drop in here, but I think there might
> be a
> >> conceptional problem. Why do we pickup each and
> every class
> >> as @Dependent? In most cases this is either
> unnecessary or
> >> even leads to AmbiguousResolutionExceptions.
> >>> 
> >>> I'd strongly favour to drop this and instead
> only
> >> pickup a bean as managed if it has a scope
> annotation or a
> >> few other very limited cases. This would also
> highly
> >> increase startup time imo...
> >>> 
> >>> LieGrue,
> >>> strub
> >>> 
> >>> 
> >>> --- On Wed, 11/10/10, Stuart Douglas <stuart.w.douglas at gmail.com>
> >> wrote:
> >>> 
> >>> From: Stuart Douglas <stuart.w.douglas at gmail.com>
> >>> Subject: Re: [weld-dev] A significantly
> negative
> >> article on Weld
> >>> To: "Pete Muir" <pmuir at bleepbleep.org.uk>
> >>> Cc: "Samuel Mendenhall" <samuel.mendenhall at gmail.com>,
> >> "Weld Dev List" <weld-dev at lists.jboss.org>
> >>> Date: Wednesday, November 10, 2010, 9:12 AM
> >>> 
> >>> 
> >>> I just ran some very quick and dirty profiling
> with
> >> the latest Jbossas and the results are as
> follows:
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>>  Beans
> >>>  Startup Time
> >>>  Startup (WELDX)
> >>>  Memory Usage
> >>>  Mem Usage(no beans.xml)
> >>> 
> >>> 
> >>>  No Deployment
> >>>  17
> >>> 
> >>> 
> >>> 
> >>> 
> >>>  135
> >>> 
> >>> 
> >>>  20
> >>>  20
> >>>  22
> >>>  149
> >>> 
> >>> 
> >>> 
> >>> 
> >>>  500
> >>>  24
> >>>  26
> >>>  178
> >>> 
> >>> 
> >>> 
> >>> 
> >>>  2000
> >>>  35
> >>>  43
> >>>  265
> >>> 
> >>> 
> >>> 
> >>> 
> >>>  5000
> >>>  87
> >>>  104
> >>>  440
> >>>  210
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> So jboss uses 135Mb normally, and 210Mb when a
> war
> >> with 5000 classes is deployed that does not have
> beans.xml.
> >> When you add weld to the mix the memory usage
> jumps by 230Mb
> >> to 440Mb.
> >>> According to yjp WeldClassImpl (and it's
> retained
> >> WeldMethod/Field etc) is responsible for 120Mb of
> this.
> >> Other major culprits seem to be
> TypeSafeObserverResolver at
> >> 24Mb (as it is caching
> ProcessAnnotatedType<Bean*> *
> >> 5000) and TypeSafeDecoratorResolver at 13Mb. Not
> much else
> >> stands out.
> >>> The beans used where quite simple (1 injection
> point,
> >> 7 fields, 6 methods), no normal scoped beans, no
> >> interceptors, not decorators. Weldx does have a
> notable
> >> effect on startup time, which I will also
> investigate.
> >>> I don't think it will be to hard to
> significantly
> >> reduce this. Reducing the number of HashMap's in
> >> WeldClassImpl (and replacing some with
> ImmutableArraySet)
> >> should give a significant gain, and clearing the
> >> TypeSafeObserverResolver and
> TypeSafeDecoratorResolver after
> >> startup should also save around 40Mb. I'll try and
> do some
> >> work this week and see how much I can get this
> down.
> >>> Stuart
> >>> On 10/11/2010, at 8:48 AM, Pete Muir wrote:
> >>> I'm about to post a blog about this.
> >>> 
> >>> On 9 Nov 2010, at 21:43, Lincoln Baxter, III
> wrote:
> >>> 
> >>> Are these points valid?
> >>> 
> >>> If so, are we aware of them? Just trying to
> raise
> >> awareness to what people are saying out in the
> world. I have
> >> noticed a relatively high memory footprint in Seam
> Forge,
> >> using Weld SE.
> >>> 
> >>> http://www.dzone.com/links/r/cdi_a_major_risk_factor_in_java_ee_6.html
> >>> 
> >>> Is there anything we can address here and
> attempt to
> >> demystify this blog?
> >>> 
> >>> --
> >>> Lincoln Baxter, III
> >>> http://ocpsoft.com
> >>> http://scrumshark.com
> >>> "Keep it Simple"
> >>>
> _______________________________________________
> >>> weld-dev mailing list
> >>> weld-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/weld-dev
> >>> 
> >>> 
> >>>
> _______________________________________________
> >>> weld-dev mailing list
> >>> weld-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/weld-dev
> >>> 
> >>> 
> >>> -----Inline Attachment Follows-----
> >>> 
> >>>
> _______________________________________________
> >>> weld-dev mailing list
> >>> weld-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/weld-dev
> >>> 
> >>> 
> >>> 
> >>>
> _______________________________________________
> >>> weld-dev mailing list
> >>> weld-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/weld-dev
> >>> 
> >> 
> >> 
> >> 
> >> -- 
> >> Clint Popetz
> >> http://42lines.net
> >> Scalable Web Application Development
> >> 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > weld-dev mailing list
> > weld-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/weld-dev
> 
>

More information about the weld-dev mailing list