-
1. Re: specifying bean classes at weld boot
nickarls Mar 31, 2010 4:44 PM (in response to fiorenzino)Write an extension that observes ProcessAnnotatedType and veto():s the one's you don't want
OTOH. Scalability is of interest, Weld should be able to handle 4000 beans but we need to establish some sort of guidelines on what memconsumption to expect...
-
2. Re: specifying bean classes at weld boot
swd847 Apr 1, 2010 1:56 AM (in response to fiorenzino)How much memory were you giving the JVM (what was -Xmx)?
I wonder how hard it would be to write a class generator, that generates a lot of semi-random classes to see how weld handles it / give us something to profile.
-
3. Re: specifying bean classes at weld boot
nickarls Apr 1, 2010 8:38 AM (in response to fiorenzino)Yes, I was just thinking along the same lines.
The one who feels challenged might want to attach the generator as an incorporation to https://jira.jboss.org/jira/browse/WELD-88
Perhaps it might even be able to use directly in a unit test with dynamically generated classes. Perhaps. -
4. Re: specifying bean classes at weld boot
swd847 Apr 1, 2010 9:33 AM (in response to fiorenzino)Perhaps it could generate the classes using javassist and add them through BeforeBeanDiscovery.
I don't know about adding them in a unit test though, as performance is going to depend on the machine, and running out of memory in a unit test can be really confusing (as the error manifests as an OutOfMemoryError in the report creation phase).
-
5. Re: specifying bean classes at weld boot
pisi79 Apr 1, 2010 11:43 AM (in response to fiorenzino)@Nicklas
-
6. Re: specifying bean classes at weld boot
pisi79 Apr 1, 2010 11:45 AM (in response to fiorenzino)
Samuele Pasini wrote on Apr 01, 2010 11:43:
@NicklasWrite an extension that observes ProcessAnnotatedType and veto():s the one's you don't want
You're certainly right, but we have no time to do that now.
So far, we have managed to get along with the memory problem by means of packaging:
we have weld-managed beans classes under
WEB-INF/classes
and library jars in
WEB-INF/lib
we have beans.xml files under:
WEB-INF and within jars that have weld beans, not the other ones.
we've changed deployment legacy classes:
from WEB-INF/classes to WEB-INF/lib jars without beans.xml
@StuartHow much memory were you giving the JVM (what was -Xmx)?
We have launched JBoss with up to the following mem spaces:
-Xms128m -Xmx4096m -XX:MaxPermSize- 512m
but with no success. Packaging did the magic.
Bye,
Samuele
PS: don't blame us for that but we needed to bring Weld to a legacy jboss install.
Our configuration is JBoss 4.2.3.GA with weld-servletClick HELP for text formatting instructions. Then edit this text and check the preview.
-
7. Re: specifying bean classes at weld boot
pisi79 Apr 1, 2010 11:47 AM (in response to fiorenzino)Again: sorry for my bad luck with quoting
Write an extension that observes ProcessAnnotatedType and veto():s the one's you don't wantYou're certainly right, but we have no time to do that now.
So far, we have managed to get along with the memory problem by means of packaging:
we have weld-managed beans classes under
WEB-INF/classesand library jars in
WEB-INF/libwe have beans.xml files under:
WEB-INF and within jars that have weld beans, not the other ones.we've changed deployment legacy classes: from WEB-INF/classes to WEB-INF/lib jars
without beans.xml
How much memory were you giving the JVM (what was -Xmx)?We have launched JBoss with up to the following mem spaces:
-Xms128m -Xmx4096m -XX:MaxPermSize=512m
but with no success. Packaging did the magic.
Bye,
SamuelePS: don't blame us for that but we needed to bring Weld to a legacy jboss install.
Our configuration is JBoss 4.2.3.GA with weld-servlet -
8. Re: specifying bean classes at weld boot
alin.heyoulin.qq.com Apr 1, 2010 1:32 PM (in response to fiorenzino)I have the same this problem. I have mentioned that why cdi load all class as bean before.I like the loading way of guice or seam or spring. I think CDI spec should add @CDI to that staup-load class. If using extension veto what about other third party package? I don't know what classes of third party package should veto.
-
9. Re: specifying bean classes at weld boot
nickarls Apr 4, 2010 9:19 PM (in response to fiorenzino)The third party lib won't have a beans.xml, therefore they won't be scanned.
-
10. Re: specifying bean classes at weld boot
alin.heyoulin.qq.com Apr 5, 2010 4:22 PM (in response to fiorenzino)I mean that third party package such as granite cdi,seam3 modules.
-
11. Re: specifying bean classes at weld boot
nickarls Apr 5, 2010 4:52 PM (in response to fiorenzino)Well, if they have a beans.xml in them, they are supposed to be scanned. And you always have the option of making the extension so that it vetos anything not in your approved packages-prefixes-list.
-
-
13. Re: specifying bean classes at weld boot
nickarls Apr 7, 2010 8:53 AM (in response to fiorenzino)Well, I've seen it in a draft but it's not in the spec yet so it's safest to rely on per-bean extension