2:46 p.m.
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
2:51 p.m.
New subject: A significantly negative article on Weld
We do this because this is what the spec says we have to do :-)
Stuart
On Thu, Nov 11, 2010 at 7:46 AM, 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
2:59 p.m.
New subject: A significantly negative article on Weld
It's not easy to drop because it's part of the CDI spec I guess. But besides that
I don't think it's a conceptual problem, it has a lot of advantages (injecting
third party classes for example). In some cases (when startup times are important, e.g. on
GAE) it would be nice to override this behavior though. The XML module in Seam 3 might be
useful for declaring components, and all other components should be left untouched. A Java
class would be even better for this (no XML parser overhead).
This is a big step back in the programming model, but makes Weld useable in situations
that startup times and memory usage are very important.
Paul Bakker
________________________________________
From: weld-dev-bounces(a)lists.jboss.org [weld-dev-bounces(a)lists.jboss.org] on behalf of
Stuart Douglas [stuart.w.douglas(a)gmail.com]
Sent: 10 November 2010 21:51
To: Mark Struberg
Cc: Samuel Mendenhall; Pete Muir; Weld Dev List
Subject: Re: [weld-dev] A significantly negative article on Weld
We do this because this is what the spec says we have to do :-)
Stuart
On Thu, Nov 11, 2010 at 7:46 AM, 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
Op dit e-mail bericht is de disclaimer van Info Support van toepassing, zie
http://www.infosupport.com/disclaimer
6:54 a.m.
New subject: A significantly negative article on Weld
On 10 Nov 2010, at 21:59, Paul Bakker wrote:
It's not easy to drop because it's part of the CDI spec I
guess. But besides that I don't think it's a conceptual problem, it has a lot of
advantages (injecting third party classes for example). In some cases (when startup times
are important, e.g. on GAE) it would be nice to override this behavior though.
Agreed, Ales has started prototyping this in Weld already :-)
The XML module in Seam 3 might be useful for declaring components,
and all other components should be left untouched. A Java class would be even better for
this (no XML parser overhead).
This is a big step back in the programming model, but makes Weld useable in situations
that startup times and memory usage are very important.
This discussion has actually changed course somewhat, from talking about memory usage to
startup time -- the blog I wrote concentrates only on memory usage. There are lots of ways
to improve startup time. The biggest overhead we have observed is actually loading the
classes to scan in the first place, followed by the scan. We can use a project such as
jandex to improve both of these significantly, by generating all the metadata about the
classes as part of the build, and storing it in the deployed jar. This should have a major
effect on a runtime env like GAE which has to go through startup much more often.
In fact, I want to take this one step further for Weld 1.1 and offer a full "partial
startup" mode, whereby the environment can say to Weld "I've already scanned
all the classes, built up all the metadata about annotations, meta-annotations etc. and
called all of the ProcessAnnotatedType events, and applied modifications from them back,
here is the set of AnnotatedTypes from which to generate beans". Obviously very
useful in something like GAE which needs to cold-start much more often (my crude estimate
is this could save say 60% of startup time without us doing any optimisation on startup
time, something I hope Stale can look at once he has worked on runtime performance). This
will also be very useful in JBoss AS 7 which will offer the ability to build parts of the
deployment on the domain controller before handing it off to the individual servers.
7:51 a.m.
New subject: A significantly negative article on Weld
In fact, I want to take this one step further for Weld 1.1 and offer
a full "partial startup" mode, whereby the environment can say to Weld
"I've already scanned all the classes, built up all the metadata about
annotations, meta-annotations etc. and called all of the ProcessAnnotatedType events, and
applied modifications from them back, here is the set of AnnotatedTypes from which to
generate beans". Obviously very useful in something like GAE which needs to
cold-start much more often (my crude estimate is this could save say 60% of startup time
without us doing any optimisation on startup time, something I hope Stale can look at once
he has worked on runtime performance). This will also be very useful in JBoss AS 7 which
will offer the ability to build parts of the deployment on the domain controller before
handing it off to the individual servers.
How much time do you expect it will take to get proper API in place to support this?
As we can first try it in JBossAS6, which already has similar mechanism in place; e.g. for
JSF, Hibernate, RestEasy, ...
Another useful feature -- which is also already supported in Jandex and Scanning,
is a way to serialize annotation information, hence no need for actual scanning.
(in Scanning you can actually serialize any information; e.g. Hibernate mapping files
location)
My guess is this would also be very useful for overall Weld config,
specially in restricted envs; GAE, ...
8:10 a.m.
New subject: A significantly negative article on Weld
On 12 Nov 2010, at 13:51, Ales Justin wrote:
> In fact, I want to take this one step further for Weld 1.1 and
offer a full "partial startup" mode, whereby the environment can say to Weld
"I've already scanned all the classes, built up all the metadata about
annotations, meta-annotations etc. and called all of the ProcessAnnotatedType events, and
applied modifications from them back, here is the set of AnnotatedTypes from which to
generate beans". Obviously very useful in something like GAE which needs to
cold-start much more often (my crude estimate is this could save say 60% of startup time
without us doing any optimisation on startup time, something I hope Stale can look at once
he has worked on runtime performance). This will also be very useful in JBoss AS 7 which
will offer the ability to build parts of the deployment on the domain controller before
handing it off to the individual servers.
How much time do you expect it will take to get proper API in place to support this?
As we can first try it in JBossAS6, which already has similar mechanism in place; e.g.
for JSF, Hibernate, RestEasy, ...
Am aiming to do it after Devoxx.
Another useful feature -- which is also already supported in Jandex and Scanning,
is a way to serialize annotation information, hence no need for actual scanning.
(in Scanning you can actually serialize any information; e.g. Hibernate mapping files
location)
Exactly.
My guess is this would also be very useful for overall Weld config,
specially in restricted envs; GAE, ...
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
10:05 a.m.
New subject: Specifying the classes to install
On 11 Nov 2010, at 12:54, Pete Muir wrote:
On 10 Nov 2010, at 21:59, Paul Bakker wrote:
> It's not easy to drop because it's part of the CDI spec I guess. But besides
that I don't think it's a conceptual problem, it has a lot of advantages
(injecting third party classes for example). In some cases (when startup times are
important, e.g. on GAE) it would be nice to override this behavior though.
Agreed, Ales has started prototyping this in Weld already :-)
Ales and I discussed this on IM. Points of note:
* The deployment for Weld is split up like:
1) scan classloader
2) load classes
3) send PAT events
4) create beans
Weld already supports skipping (2), (3), (4) via the beans.xml support for excluding
classes, so we have removed some overhead, but being able to skip (1) will help as well.
* We could introduce a Java API for this, where you can specify classes to load in a list,
array or similar (refactor safe compared to a plain text file)
* You need to specify each class, no support for wildcards etc. here
* We could introduce a build-time tool that does support wildcards, and generates the
plain text descriptor
* A build time tool would also fit well with the support for jandex that we want to add
11:03 a.m.
New subject: Specifying the classes to install
I think the following might work:
1- Introduce an interface 'WeldApplication' with a method: Class<?>[]
registerClasses();
2- A user implements this interface and returns an array of class literals for all classes
that should become managed.
3- Register the user's implementation as a context-param in web.xml
4- Check if this parameter is set in the ServletListener, and if it is, instantiate it. We
can now completely skip scanning and just go forward with the classes specified by
registerClasses().
I believe a Java class is a lot more user friendly then a plain text file because it's
type safe. It will at least not brake if you refactor a class name. We could still provide
a tool to generate this kind of class because the lack of wildcards might be unconfinient
for larger applications.
What do you think? If this idea generally fits your idea about it I can try to prototype
it this weekend.
Paul
________________________________________
From: Pete Muir [pmuir(a)redhat.com]
Sent: 12 November 2010 17:05
To: Pete Muir
Cc: Paul Bakker; weld-dev(a)lists.jboss.org
Subject: Specifying the classes to install
On 11 Nov 2010, at 12:54, Pete Muir wrote:
On 10 Nov 2010, at 21:59, Paul Bakker wrote:
> It's not easy to drop because it's part of the CDI spec I guess. But besides
that I don't think it's a conceptual problem, it has a lot of advantages
(injecting third party classes for example). In some cases (when startup times are
important, e.g. on GAE) it would be nice to override this behavior though.
Agreed, Ales has started prototyping this in Weld already :-)
Ales and I discussed this on IM. Points of note:
* The deployment for Weld is split up like:
1) scan classloader
2) load classes
3) send PAT events
4) create beans
Weld already supports skipping (2), (3), (4) via the beans.xml support for excluding
classes, so we have removed some overhead, but being able to skip (1) will help as well.
* We could introduce a Java API for this, where you can specify classes to load in a list,
array or similar (refactor safe compared to a plain text file)
* You need to specify each class, no support for wildcards etc. here
* We could introduce a build-time tool that does support wildcards, and generates the
plain text descriptor
* A build time tool would also fit well with the support for jandex that we want to add
Op dit e-mail bericht is de disclaimer van Info Support van toepassing, zie
http://www.infosupport.com/disclaimer
11:14 a.m.
New subject: Specifying the classes to install
Yes, that's exactly what we were thinking of for the "Java API". I argued
exactly the same point about the refactoring as well :-)
And the tool is for just that reason -- maybe we can even reuse the existing beans.xml
excludes syntax, and apply the excludes that we can (i.e. not the ones conditional upon
the runtime env) at that point, via this generated class.
So, prototype away!
Also, can you sign a cla at cla.jboss.org?
On 12 Nov 2010, at 17:03, Paul Bakker wrote:
I think the following might work:
1- Introduce an interface 'WeldApplication' with a method: Class<?>[]
registerClasses();
2- A user implements this interface and returns an array of class literals for all
classes that should become managed.
3- Register the user's implementation as a context-param in web.xml
4- Check if this parameter is set in the ServletListener, and if it is, instantiate it.
We can now completely skip scanning and just go forward with the classes specified by
registerClasses().
I believe a Java class is a lot more user friendly then a plain text file because
it's type safe. It will at least not brake if you refactor a class name. We could
still provide a tool to generate this kind of class because the lack of wildcards might be
unconfinient for larger applications.
What do you think? If this idea generally fits your idea about it I can try to prototype
it this weekend.
Paul
________________________________________
From: Pete Muir [pmuir(a)redhat.com]
Sent: 12 November 2010 17:05
To: Pete Muir
Cc: Paul Bakker; weld-dev(a)lists.jboss.org
Subject: Specifying the classes to install
On 11 Nov 2010, at 12:54, Pete Muir wrote:
>
> On 10 Nov 2010, at 21:59, Paul Bakker wrote:
>
>> It's not easy to drop because it's part of the CDI spec I guess. But
besides that I don't think it's a conceptual problem, it has a lot of advantages
(injecting third party classes for example). In some cases (when startup times are
important, e.g. on GAE) it would be nice to override this behavior though.
>
> Agreed, Ales has started prototyping this in Weld already :-)
Ales and I discussed this on IM. Points of note:
* The deployment for Weld is split up like:
1) scan classloader
2) load classes
3) send PAT events
4) create beans
Weld already supports skipping (2), (3), (4) via the beans.xml support for excluding
classes, so we have removed some overhead, but being able to skip (1) will help as well.
* We could introduce a Java API for this, where you can specify classes to load in a
list, array or similar (refactor safe compared to a plain text file)
* You need to specify each class, no support for wildcards etc. here
* We could introduce a build-time tool that does support wildcards, and generates the
plain text descriptor
* A build time tool would also fit well with the support for jandex that we want to add
Op dit e-mail bericht is de disclaimer van Info Support van toepassing, zie
http://www.infosupport.com/disclaimer
11:31 a.m.
New subject: Specifying the classes to install
Yes, that's exactly what we were thinking of for the "Java
API". I argued exactly the same point about the refactoring as well :-)
And the tool is for just that reason -- maybe we can even reuse the existing beans.xml
excludes syntax, and apply the excludes that we can (i.e. not the ones conditional upon
the runtime env) at that point, via this generated class.
So, prototype away!
Have a look at my current "exact" scanning,
and perhaps we can just extend that to first apply this interface logic,
then fall back on the .txt file.
btw: we're currently using String collection of classes.
Afair we used to have Class collection, which would be more convenient here.
8:17 a.m.
New subject: Specifying the classes to install
Hey Pete,
I took a first shot a the JavaConfig prototype and it seems to be working well. I had to
refactor a bit to decouple some implementation classes and add some interfaces to add it
in a clean way, hope that's ok with you. I notice a difference of about 2 seconds on
startup time of a small project :-)
Take a look here for the general idea:
https://github.com/paulbakker/core/commit/03c615b43f2ea682e1dd9ee584bea8a...
The code is still a bit messy (some sysouts etc...) but I'm happy the idea seems to be
working at least, I'll clean the code up tomorrow.
A user would have to change the following in the web.xml:
<!-- The class that implements WeldContext -->
<context-param>
<param-name>weld.javaconfig.class</param-name>
<param-value>org.nljug.cfp.WeldApplicationContext</param-value>
</context-param>
<!-- Instead of the standard Listener -->
<listener>
<listener-class>org.jboss.weld.environment.servlet.JavaConfigListener</listener-class>
</listener>
I have a vague idea how to solve the wildcard problem too. Maybe we can add another method
to the WeldContext class: 'registerPackages' that returns a list of Strings of
package names. Using these strings we can scan selectively in those packages.
Paul
________________________________________
From: Pete Muir [pmuir(a)redhat.com]
Sent: 12 November 2010 18:14
To: Paul Bakker
Cc: weld-dev(a)lists.jboss.org
Subject: Re: Specifying the classes to install
Yes, that's exactly what we were thinking of for the "Java API". I argued
exactly the same point about the refactoring as well :-)
And the tool is for just that reason -- maybe we can even reuse the existing beans.xml
excludes syntax, and apply the excludes that we can (i.e. not the ones conditional upon
the runtime env) at that point, via this generated class.
So, prototype away!
Also, can you sign a cla at cla.jboss.org?
On 12 Nov 2010, at 17:03, Paul Bakker wrote:
I think the following might work:
1- Introduce an interface 'WeldApplication' with a method: Class<?>[]
registerClasses();
2- A user implements this interface and returns an array of class literals for all
classes that should become managed.
3- Register the user's implementation as a context-param in web.xml
4- Check if this parameter is set in the ServletListener, and if it is, instantiate it.
We can now completely skip scanning and just go forward with the classes specified by
registerClasses().
I believe a Java class is a lot more user friendly then a plain text file because
it's type safe. It will at least not brake if you refactor a class name. We could
still provide a tool to generate this kind of class because the lack of wildcards might be
unconfinient for larger applications.
What do you think? If this idea generally fits your idea about it I can try to prototype
it this weekend.
Paul
________________________________________
From: Pete Muir [pmuir(a)redhat.com]
Sent: 12 November 2010 17:05
To: Pete Muir
Cc: Paul Bakker; weld-dev(a)lists.jboss.org
Subject: Specifying the classes to install
On 11 Nov 2010, at 12:54, Pete Muir wrote:
>
> On 10 Nov 2010, at 21:59, Paul Bakker wrote:
>
>> It's not easy to drop because it's part of the CDI spec I guess. But
besides that I don't think it's a conceptual problem, it has a lot of advantages
(injecting third party classes for example). In some cases (when startup times are
important, e.g. on GAE) it would be nice to override this behavior though.
>
> Agreed, Ales has started prototyping this in Weld already :-)
Ales and I discussed this on IM. Points of note:
* The deployment for Weld is split up like:
1) scan classloader
2) load classes
3) send PAT events
4) create beans
Weld already supports skipping (2), (3), (4) via the beans.xml support for excluding
classes, so we have removed some overhead, but being able to skip (1) will help as well.
* We could introduce a Java API for this, where you can specify classes to load in a
list, array or similar (refactor safe compared to a plain text file)
* You need to specify each class, no support for wildcards etc. here
* We could introduce a build-time tool that does support wildcards, and generates the
plain text descriptor
* A build time tool would also fit well with the support for jandex that we want to add
Op dit e-mail bericht is de disclaimer van Info Support van toepassing, zie
http://www.infosupport.com/disclaimer
8:35 a.m.
New subject: Specifying the classes to install
The commit looks partial -- I only see two changes, and no
DefaultServletDeployment, WeldContext, ...
*
https://github.com/paulbakker/core/tree/master/environments/servlet/core/...
On Sat, Nov 13, 2010 at 3:17 PM, Paul Bakker <paulb(a)infosupport.com> wrote:
Hey Pete,
I took a first shot a the JavaConfig prototype and it seems to be working
well. I had to refactor a bit to decouple some implementation classes and
add some interfaces to add it in a clean way, hope that's ok with you. I
notice a difference of about 2 seconds on startup time of a small project
:-)
Take a look here for the general idea:
https://github.com/paulbakker/core/commit/03c615b43f2ea682e1dd9ee584bea8a...
The code is still a bit messy (some sysouts etc...) but I'm happy the idea
seems to be working at least, I'll clean the code up tomorrow.
A user would have to change the following in the web.xml:
<!-- The class that implements WeldContext -->
<context-param>
<param-name>weld.javaconfig.class</param-name>
<param-value>org.nljug.cfp.WeldApplicationContext</param-value>
</context-param>
<!-- Instead of the standard Listener -->
<listener>
<listener-class>org.jboss.weld.environment.servlet.JavaConfigListener</listener-class>
</listener>
I have a vague idea how to solve the wildcard problem too. Maybe we can add
another method to the WeldContext class: 'registerPackages' that returns a
list of Strings of package names. Using these strings we can scan
selectively in those packages.
Paul
________________________________________
From: Pete Muir [pmuir(a)redhat.com]
Sent: 12 November 2010 18:14
To: Paul Bakker
Cc: weld-dev(a)lists.jboss.org
Subject: Re: Specifying the classes to install
Yes, that's exactly what we were thinking of for the "Java API". I argued
exactly the same point about the refactoring as well :-)
And the tool is for just that reason -- maybe we can even reuse the
existing beans.xml excludes syntax, and apply the excludes that we can (i.e.
not the ones conditional upon the runtime env) at that point, via this
generated class.
So, prototype away!
Also, can you sign a cla at cla.jboss.org?
On 12 Nov 2010, at 17:03, Paul Bakker wrote:
> I think the following might work:
>
> 1- Introduce an interface 'WeldApplication' with a method: Class<?>[]
registerClasses();
> 2- A user implements this interface and returns an array of class
literals for all classes that should become managed.
> 3- Register the user's implementation as a context-param in web.xml
> 4- Check if this parameter is set in the ServletListener, and if it is,
instantiate it. We can now completely skip scanning and just go forward with
the classes specified by registerClasses().
>
> I believe a Java class is a lot more user friendly then a plain text file
because it's type safe. It will at least not brake if you refactor a class
name. We could still provide a tool to generate this kind of class because
the lack of wildcards might be unconfinient for larger applications.
>
> What do you think? If this idea generally fits your idea about it I can
try to prototype it this weekend.
>
> Paul
>
> ________________________________________
> From: Pete Muir [pmuir(a)redhat.com]
> Sent: 12 November 2010 17:05
> To: Pete Muir
> Cc: Paul Bakker; weld-dev(a)lists.jboss.org
> Subject: Specifying the classes to install
>
> On 11 Nov 2010, at 12:54, Pete Muir wrote:
>
>>
>> On 10 Nov 2010, at 21:59, Paul Bakker wrote:
>>
>>> It's not easy to drop because it's part of the CDI spec I guess.
But
besides that I don't think it's a conceptual problem, it has a lot of
advantages (injecting third party classes for example). In some cases (when
startup times are important, e.g. on GAE) it would be nice to override this
behavior though.
>>
>> Agreed, Ales has started prototyping this in Weld already :-)
>
> Ales and I discussed this on IM. Points of note:
>
> * The deployment for Weld is split up like:
>
> 1) scan classloader
> 2) load classes
> 3) send PAT events
> 4) create beans
>
> Weld already supports skipping (2), (3), (4) via the beans.xml support
for excluding classes, so we have removed some overhead, but being able to
skip (1) will help as well.
>
> * We could introduce a Java API for this, where you can specify classes
to load in a list, array or similar (refactor safe compared to a plain text
file)
>
> * You need to specify each class, no support for wildcards etc. here
>
> * We could introduce a build-time tool that does support wildcards, and
generates the plain text descriptor
>
> * A build time tool would also fit well with the support for jandex that
we want to add
>
> Op dit e-mail bericht is de disclaimer van Info Support van toepassing,
zie http://www.infosupport.com/disclaimer
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
8:42 a.m.
New subject: Specifying the classes to install
Yeah, it's missing stuff :-)
But what you said in your email looks good (though I think that we can predicate using
java config on just the context param, not need to change the listener as well).
Ales and I talked about this idea for scanning packages, and we don't think we have
enough control of how the CL works to be able to scan for packages without doing most/all
of the work of scanning everything...
On 13 Nov 2010, at 14:35, Ales Justin wrote:
The commit looks partial -- I only see two changes, and no
DefaultServletDeployment, WeldContext, ...
*
https://github.com/paulbakker/core/tree/master/environments/servlet/core/...
On Sat, Nov 13, 2010 at 3:17 PM, Paul Bakker <paulb(a)infosupport.com> wrote:
Hey Pete,
I took a first shot a the JavaConfig prototype and it seems to be working well. I had to
refactor a bit to decouple some implementation classes and add some interfaces to add it
in a clean way, hope that's ok with you. I notice a difference of about 2 seconds on
startup time of a small project :-)
Take a look here for the general idea:
https://github.com/paulbakker/core/commit/03c615b43f2ea682e1dd9ee584bea8a...
The code is still a bit messy (some sysouts etc...) but I'm happy the idea seems to
be working at least, I'll clean the code up tomorrow.
A user would have to change the following in the web.xml:
<!-- The class that implements WeldContext -->
<context-param>
<param-name>weld.javaconfig.class</param-name>
<param-value>org.nljug.cfp.WeldApplicationContext</param-value>
</context-param>
<!-- Instead of the standard Listener -->
<listener>
<listener-class>org.jboss.weld.environment.servlet.JavaConfigListener</listener-class>
</listener>
I have a vague idea how to solve the wildcard problem too. Maybe we can add another
method to the WeldContext class: 'registerPackages' that returns a list of Strings
of package names. Using these strings we can scan selectively in those packages.
Paul
________________________________________
From: Pete Muir [pmuir(a)redhat.com]
Sent: 12 November 2010 18:14
To: Paul Bakker
Cc: weld-dev(a)lists.jboss.org
Subject: Re: Specifying the classes to install
Yes, that's exactly what we were thinking of for the "Java API". I argued
exactly the same point about the refactoring as well :-)
And the tool is for just that reason -- maybe we can even reuse the existing beans.xml
excludes syntax, and apply the excludes that we can (i.e. not the ones conditional upon
the runtime env) at that point, via this generated class.
So, prototype away!
Also, can you sign a cla at cla.jboss.org?
On 12 Nov 2010, at 17:03, Paul Bakker wrote:
> I think the following might work:
>
> 1- Introduce an interface 'WeldApplication' with a method: Class<?>[]
registerClasses();
> 2- A user implements this interface and returns an array of class literals for all
classes that should become managed.
> 3- Register the user's implementation as a context-param in web.xml
> 4- Check if this parameter is set in the ServletListener, and if it is, instantiate
it. We can now completely skip scanning and just go forward with the classes specified by
registerClasses().
>
> I believe a Java class is a lot more user friendly then a plain text file because
it's type safe. It will at least not brake if you refactor a class name. We could
still provide a tool to generate this kind of class because the lack of wildcards might be
unconfinient for larger applications.
>
> What do you think? If this idea generally fits your idea about it I can try to
prototype it this weekend.
>
> Paul
>
> ________________________________________
> From: Pete Muir [pmuir(a)redhat.com]
> Sent: 12 November 2010 17:05
> To: Pete Muir
> Cc: Paul Bakker; weld-dev(a)lists.jboss.org
> Subject: Specifying the classes to install
>
> On 11 Nov 2010, at 12:54, Pete Muir wrote:
>
>>
>> On 10 Nov 2010, at 21:59, Paul Bakker wrote:
>>
>>> It's not easy to drop because it's part of the CDI spec I guess. But
besides that I don't think it's a conceptual problem, it has a lot of advantages
(injecting third party classes for example). In some cases (when startup times are
important, e.g. on GAE) it would be nice to override this behavior though.
>>
>> Agreed, Ales has started prototyping this in Weld already :-)
>
> Ales and I discussed this on IM. Points of note:
>
> * The deployment for Weld is split up like:
>
> 1) scan classloader
> 2) load classes
> 3) send PAT events
> 4) create beans
>
> Weld already supports skipping (2), (3), (4) via the beans.xml support for
excluding classes, so we have removed some overhead, but being able to skip (1) will help
as well.
>
> * We could introduce a Java API for this, where you can specify classes to load in a
list, array or similar (refactor safe compared to a plain text file)
>
> * You need to specify each class, no support for wildcards etc. here
>
> * We could introduce a build-time tool that does support wildcards, and generates
the plain text descriptor
>
> * A build time tool would also fit well with the support for jandex that we want to
add
>
> Op dit e-mail bericht is de disclaimer van Info Support van toepassing, zie
http://www.infosupport.com/disclaimer
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
8:42 a.m.
New subject: Specifying the classes to install
Sorry you're right. First time working with git...
I've added them.
Paul
________________________________
From: Ales Justin [ales.justin(a)gmail.com]
Sent: 13 November 2010 15:35
To: Paul Bakker
Cc: Pete Muir; weld-dev(a)lists.jboss.org
Subject: Re: [weld-dev] Specifying the classes to install
The commit looks partial -- I only see two changes, and no DefaultServletDeployment,
WeldContext, ...
*
https://github.com/paulbakker/core/tree/master/environments/servlet/core/...
On Sat, Nov 13, 2010 at 3:17 PM, Paul Bakker
<paulb@infosupport.com<mailto:paulb@infosupport.com>> wrote:
Hey Pete,
I took a first shot a the JavaConfig prototype and it seems to be working well. I had to
refactor a bit to decouple some implementation classes and add some interfaces to add it
in a clean way, hope that's ok with you. I notice a difference of about 2 seconds on
startup time of a small project :-)
Take a look here for the general idea:
https://github.com/paulbakker/core/commit/03c615b43f2ea682e1dd9ee584bea8a...
The code is still a bit messy (some sysouts etc...) but I'm happy the idea seems to be
working at least, I'll clean the code up tomorrow.
A user would have to change the following in the web.xml:
<!-- The class that implements WeldContext -->
<context-param>
<param-name>weld.javaconfig.class</param-name>
<param-value>org.nljug.cfp.WeldApplicationContext</param-value>
</context-param>
<!-- Instead of the standard Listener -->
<listener>
<listener-class>org.jboss.weld.environment.servlet.JavaConfigListener</listener-class>
</listener>
I have a vague idea how to solve the wildcard problem too. Maybe we can add another method
to the WeldContext class: 'registerPackages' that returns a list of Strings of
package names. Using these strings we can scan selectively in those packages.
Paul
________________________________________
From: Pete Muir [pmuir@redhat.com<mailto:pmuir@redhat.com>]
Sent: 12 November 2010 18:14
To: Paul Bakker
Cc: weld-dev@lists.jboss.org<mailto:weld-dev@lists.jboss.org>
Subject: Re: Specifying the classes to install
Yes, that's exactly what we were thinking of for the "Java API". I argued
exactly the same point about the refactoring as well :-)
And the tool is for just that reason -- maybe we can even reuse the existing beans.xml
excludes syntax, and apply the excludes that we can (i.e. not the ones conditional upon
the runtime env) at that point, via this generated class.
So, prototype away!
Also, can you sign a cla at cla.jboss.org<http://cla.jboss.org>?
On 12 Nov 2010, at 17:03, Paul Bakker wrote:
I think the following might work:
1- Introduce an interface 'WeldApplication' with a method: Class<?>[]
registerClasses();
2- A user implements this interface and returns an array of class literals for all
classes that should become managed.
3- Register the user's implementation as a context-param in web.xml
4- Check if this parameter is set in the ServletListener, and if it is, instantiate it.
We can now completely skip scanning and just go forward with the classes specified by
registerClasses().
I believe a Java class is a lot more user friendly then a plain text file because
it's type safe. It will at least not brake if you refactor a class name. We could
still provide a tool to generate this kind of class because the lack of wildcards might be
unconfinient for larger applications.
What do you think? If this idea generally fits your idea about it I can try to prototype
it this weekend.
Paul
________________________________________
From: Pete Muir [pmuir@redhat.com<mailto:pmuir@redhat.com>]
Sent: 12 November 2010 17:05
To: Pete Muir
Cc: Paul Bakker; weld-dev@lists.jboss.org<mailto:weld-dev@lists.jboss.org>
Subject: Specifying the classes to install
On 11 Nov 2010, at 12:54, Pete Muir wrote:
>
> On 10 Nov 2010, at 21:59, Paul Bakker wrote:
>
>> It's not easy to drop because it's part of the CDI spec I guess. But
besides that I don't think it's a conceptual problem, it has a lot of advantages
(injecting third party classes for example). In some cases (when startup times are
important, e.g. on GAE) it would be nice to override this behavior though.
>
> Agreed, Ales has started prototyping this in Weld already :-)
Ales and I discussed this on IM. Points of note:
* The deployment for Weld is split up like:
1) scan classloader
2) load classes
3) send PAT events
4) create beans
Weld already supports skipping (2), (3), (4) via the beans.xml support for excluding
classes, so we have removed some overhead, but being able to skip (1) will help as well.
* We could introduce a Java API for this, where you can specify classes to load in a
list, array or similar (refactor safe compared to a plain text file)
* You need to specify each class, no support for wildcards etc. here
* We could introduce a build-time tool that does support wildcards, and generates the
plain text descriptor
* A build time tool would also fit well with the support for jandex that we want to add
Op dit e-mail bericht is de disclaimer van Info Support van toepassing, zie
http://www.infosupport.com/disclaimer
_______________________________________________
weld-dev mailing list
weld-dev@lists.jboss.org<mailto:weld-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/weld-dev
2:52 p.m.
New subject: A significantly negative article on Weld
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
2:59 p.m.
New subject: A significantly negative article on Weld
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
6:48 a.m.
New subject: A significantly negative article on Weld
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
2:52 a.m.
New subject: A significantly negative article on Weld
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(a)bleepbleep.org.uk> wrote:
From: Pete Muir <pmuir(a)bleepbleep.org.uk>
Subject: Re: [weld-dev] A significantly negative article on Weld
To: "Mark Struberg" <struberg(a)yahoo.de>
Cc: "Clint Popetz" <cpopetz(a)gmail.com>, "Samuel Mendenhall"
<samuel.mendenhall(a)gmail.com>, "Weld Dev List"
<weld-dev(a)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(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
4:49 a.m.
New subject: A significantly negative article on Weld
Hi Mark
On 12 November 2010 08:52, Mark Struberg <struberg(a)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!
6:52 a.m.
New subject: A significantly negative article on Weld
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(a)bleepbleep.org.uk> wrote:
From: Pete Muir <pmuir(a)bleepbleep.org.uk>
Subject: Re: [weld-dev] A significantly negative article on Weld
To: "Mark Struberg" <struberg(a)yahoo.de>
Cc: "Clint Popetz" <cpopetz(a)gmail.com>, "Samuel Mendenhall"
<samuel.mendenhall(a)gmail.com>, "Weld Dev List"
<weld-dev(a)lists.jboss.org>
Date: Friday, November 12, 2010, 10:49 AM
Hi Mark
On 12 November 2010 08:52, Mark Struberg <struberg(a)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!
3:01 p.m.
New subject: A significantly negative article on Weld
On Wed, Nov 10, 2010 at 3:52 PM, Clint Popetz <cpopetz(a)gmail.com> wrote:
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.
Actually, there is one other approach to registering a class from a non-bean
archive (no beans.xml), which is used in Weld Extensions. You can add the
annotated types explicitly in an extension:
void beforeBeanDiscovery(@Observes BeforeBeanDiscovery event,
BeanManager beanManager)
{
event.addAnnotatedType(beanManager.createAnnotatedType(BeanIAm.class));
}
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
6:09 p.m.
New subject: A significantly negative article on Weld
Couldn't we handle @Dependent beans in some kind of lazy manner? I.e.
rather than picking them all up at deployment time pick them up when
they're actually required.
On 11/11/10 06:52, Clint Popetz wrote:
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
>
6:21 p.m.
New subject: A significantly negative article on Weld
The problem with this is they have to go through the SPI at boot time
(i.e. ProcessAnnotatedType and ProcessBean).
Stuart
On Thu, Nov 11, 2010 at 11:09 AM, Shane Bryzak <sbryzak(a)redhat.com> wrote:
Couldn't we handle @Dependent beans in some kind of lazy manner?
I.e.
rather than picking them all up at deployment time pick them up when
they're actually required.
On 11/11/10 06:52, Clint Popetz wrote:
> 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
>>
>
>
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
10:35 p.m.
New subject: A significantly negative article on Weld
Re: lazy handling of @Dependent beans - Not with the current contract -
i.e. imagine this
@RequestScoped
public class Foo
{
@Dependent Bar bar;
}
public class BarBar implements Bar
{
}
When the BeanManager is completely initialized, there must be 100%
certainty that one and only one Bar implementation exists (this
simplifies things by ignoring qualifiers). This can be achieved only by
scanning all potential candidates upfront. That being said, there are
means for reducing the scope of the scanning process (more granular bean
deployments, custom scanner configuration - although this is Weld-specific).
On 10-11-10 7:09 PM, Shane Bryzak wrote:
Couldn't we handle @Dependent beans in some kind of lazy manner?
I.e.
rather than picking them all up at deployment time pick them up when
they're actually required.
On 11/11/10 06:52, Clint Popetz wrote:
> 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
>>
>
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
5142
days inactive
5145
days old
23 comments
10 participants
participants (10)
-
Ales Justin -
Clint Popetz -
Dan Allen -
Marius Bogoevici -
Mark Struberg -
Paul Bakker -
Pete Muir -
Pete Muir -
Shane Bryzak -
Stuart Douglas