Hi! I've talked about this problem with pete, and he changed the beans.xml schema so it's now allowed to e.g. have own <includes> and <excludes> sections. This would allow us to introduce a _non_portable_ (but who cares) way to limit the memory consumption in OWB.
LieGrue, strub --- On Mon, 1/10/11, Gerhard <[email protected]> wrote: > From: Gerhard <[email protected]> > Subject: Re: Can we avoid loading all the classes during startup? > To: [email protected] > Date: Monday, January 10, 2011, 8:55 AM > hi david, > > imo it isn't really a big deal to scan all >bean > archives<. if you really > have a lot of classes which shouldn't be used as beans, > just create a jar > for them. > (esp. i don't see #3 - you just need a single portable > extension which > calls AnnotatedType#getJavaClass during bootstrapping. e.g. > codi uses it for > @ProjectStageActivated and i guess one of the jboss > extensions is/will be > doing the same.) > > however, we should fix at least OWB-475. > > regards, > gerhard > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > 2011/1/10 David Jencks <[email protected]> > > > David Blevins and I have been hoping that it would be > possible to avoid > > loading all the classes in an application when > "deploying" it into OWB. > > Mark has been telling me that this won't work. > > > > It's pretty easy to scan the application and find all > the classes with > > relevant annotations and all the classes that are > injected into something > > using ASM so all the other classes aren't > loaded. However I now see that > > there's a BeanManager method > > > > public Set<Bean<?>> > getBeans(Type beanType, Annotation... bindings) > > > > where you can pass in an arbitrary class and get the > possible beans back. > > This certainly means that just finding all the beans > referenced in ways such > > as the injection targets or having a name is not > sufficient. I can think of > > a couple ways to proceed that might help: > > > > 1. eagerly create and register Bean<X> for > classes that are easy to > > identify as above and lazily create Bean<X> for > otherwise unidentifiable > > beans on demand. I haven't found anything in the > spec that says tis can't > > be done but haven't looked very hard. > > > > 2. We can identify some classes during scanning that > can't be beans, (e.g. > > having only non-default constructors not annotated > with @Inject) and exclude > > only these from consideration. This would be > pretty easy but is apt to load > > many more classes than we'd like. > > > > 3. Modify the AbstractOWBBean and AnnotatedTypeImpl so > they lazily load the > > bean class. I haven't investigated, so maybe the > bean class is needed > > immediately. I wonder if it might not be needed > immediately for beans with > > no annotations. > > > > Thoughts or advice? > > > > thanks > > david jencks > > > > > > > > > > > > >
