specifying bean classes at weld boot

[fiorenzino]

hello,
i'm trying to use weld with very huge old web application (more than 4000 classes).

Problem is that at bootstrap time, weld starts consuming more and more memory
till I get the following message:

java.lang.OutOfMemoryError: Java heap space
     at com.google.common.collect.Multimaps.newSetMultimap(Multimaps.java:248)
     at org.jboss.weld.introspector.AnnotationStore.<init>(AnnotationStore.java:183)
     at org.jboss.weld.introspector.AnnotationStore.of(AnnotationStore.java:108)

Is there a way to specify the only beans I want Weld to scan?

Is it possible, for instance, to write something into beans.xml to
specify which packages or classes to scan?

Thanks in advance,

fiorenzo

[nickarls]

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...

[swd847]

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.

[nickarls]

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.

[swd847]

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

[pisi79]

@Nicklas

[pisi79]

Samuele Pasini wrote on Apr 01, 2010 11:43:


@Nicklas

Write 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



@Stuart

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,
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-servlet

Click HELP for text formatting instructions. Then edit this text and check the preview.

[pisi79]

Again: sorry for my bad luck with quoting

Write 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

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,
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-servlet

[alin.heyoulin.qq.com]

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.

[nickarls]

The third party lib won't have a beans.xml, therefore they won't be scanned.

[alin.heyoulin.qq.com]

I mean that third party package such as granite cdi,seam3 modules.

[nickarls]

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.

[hmo]

What about this?

My Link

Nick, when do you think it will be ready?

[nickarls]

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