actually we won't use all the annotations anymore after the metadata (our 
Beans) got constructed. So it is really just lots of garbage in the ClassLoader.

LieGrue,
strub

--- On Sat, 3/5/11, David Jencks <[email protected]> wrote:

> From: David Jencks <[email protected]>
> Subject: Re: TCK working again
> To: [email protected]
> Date: Saturday, March 5, 2011, 6:16 PM
> Hi Mark,
> 
> My thinking on this is that you can use asm to find classes
> of interest, but to actually get to the annotations or
> details about the class you need to load the class and use
> normal reflection.  I don't think our goal here is
> really to rewrite java.lang.reflect but to only look at
> classes that we need to.
> 
> I would like to stay focussed on the goal of determining
> which classes can be CDI beans based on annotations, loading
> those eagerly, and loading the rest of them lazily.  My
> impression is that a large proportion of the reflection
> objects used to examine the class will actually be used by
> OWB when using the class, so there isn't much extra overhead
> for classes that are actually CDI beans.  If we can
> avoid looking at classes that aren't CDI beans I think we
> will have done well enough.
> 
> thanks
> david jencks
> 
> 
> On Mar 5, 2011, at 2:43 AM, Mark Struberg wrote:
> 
> > Another question: 
> > 
> > we not only need something like
> > 
> > ScannerService#getDeclaredFields(String className);
> > 
> > And of course also a method to get all the annotations
> from this field.
> > 
> > basically all the reflect stuff in a class would be
> needed. But without filling the classloader with crap which
> we cannot get rid of later ;)
> > 
> > 
> > LieGrue,
> > strub
> > 
> > --- On Fri, 3/4/11, David Jencks <[email protected]>
> wrote:
> > 
> >> From: David Jencks <[email protected]>
> >> Subject: Re: TCK working again
> >> To: [email protected]
> >> Date: Friday, March 4, 2011, 5:41 PM
> >> xbean can tell you about the
> >> subclasses of classes you found from an
> annotation. 
> >> The annotation tells you about Farmer, then since
> @Observes
> >> is inherited you look for subclasses of Farmer and
> find
> >> LazyFarmer.
> >> 
> >> I still don't see any problems as long as
> completely
> >> non-annotation-related pojo beans can be defined
> lazily on
> >> first (dynamic) use.
> >> 
> >> david jencks
> >> 
> >> On Mar 4, 2011, at 4:57 AM, Mark Struberg wrote:
> >> 
> >>> hi!
> >>> 
> >>> I've now fixed the
> DefinitionUtil#isPurePojoBean and a
> >> few other things which means the TCK is now
> working again.
> >>> 
> >>> 
> >>> @djencks: I fear we really have to scan all
> beans. In
> >> the official TCK there is a class
> >>> 
> >>> public class LazyFarmer extends Farmer 
> >>> {
> >>> }
> >>> 
> >>> but since Farmer is
> >>> 
> >>> public class Farmer
> >>> {
> >>> 
> >>>    public void
> >> observeEggLaying(@Observes Egg egg)
> >>>    {
> >>>   
>    egg.recordVisit(this);
> >>>    }
> >>> 
> >>> }
> >>> 
> >>> it is also a JSR-299 managed bean and MUST get
> picked
> >> up eagerly :(
> >>> 
> >>> So without the definition in the spec that any
> CDI
> >> bean have to define a proper scope, we just need
> to suck all
> >> the classes :(
> >>> 
> >>> Currently all this class loading consumes a
> huge
> >> amount of PermGenSpace, and here is where xbean
> could help.
> >> If we dont use 
> >>> 
> >>> Class#getDeclaredConstructors() / Annotations
> >>> Class#getDeclaredMethods() / Annotations
> >>> ...
> >>> 
> >>> but instead get this info from XBean, then we
> do not
> >> pollute the ClassLoader and after the scanning, we
> can just
> >> clear the XBean cache again to reduce memory
> consumption.
> >>> 
> >>> LieGrue,
> >>> strub
> >>> 
> >>> 
> >>> 
> >> 
> >> 
> > 
> > 
> > 
> 
> 



Reply via email to