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(a)gmail.com> wrote:
> From: Clint Popetz <cpopetz(a)gmail.com>
> Subject: Re: [weld-dev] A significantly negative article on Weld
> To: "Mark Struberg" <struberg(a)yahoo.de>
> Cc: "Pete Muir" <pmuir(a)bleepbleep.org.uk>, "Stuart Douglas"
<stuart.w.douglas(a)gmail.com>, "Samuel Mendenhall"
<samuel.mendenhall(a)gmail.com>, "Weld Dev List"
<weld-dev(a)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(a)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(a)gmail.com>
> wrote:
>>
>> From: Stuart Douglas <stuart.w.douglas(a)gmail.com>
>> Subject: Re: [weld-dev] A significantly negative
> article on Weld
>> To: "Pete Muir" <pmuir(a)bleepbleep.org.uk>
>> Cc: "Samuel Mendenhall" <samuel.mendenhall(a)gmail.com>,
> "Weld Dev List" <weld-dev(a)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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>>
>> -----Inline Attachment Follows-----
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>>
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev