You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by Mark Struberg <st...@yahoo.de> on 2011/03/04 13:57:28 UTC
TCK working again
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
Re: TCK working again
Posted by Mark Struberg <st...@yahoo.de>.
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 <da...@yahoo.com> wrote:
> From: David Jencks <da...@yahoo.com>
> Subject: Re: TCK working again
> To: dev@openwebbeans.apache.org
> 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 <da...@yahoo.com>
> wrote:
> >
> >> From: David Jencks <da...@yahoo.com>
> >> Subject: Re: TCK working again
> >> To: dev@openwebbeans.apache.org
> >> 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
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
>
>
Re: TCK working again
Posted by David Jencks <da...@yahoo.com>.
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 <da...@yahoo.com> wrote:
>
>> From: David Jencks <da...@yahoo.com>
>> Subject: Re: TCK working again
>> To: dev@openwebbeans.apache.org
>> 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
>>>
>>>
>>>
>>
>>
>
>
>
Re: TCK working again
Posted by Mark Struberg <st...@yahoo.de>.
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 <da...@yahoo.com> wrote:
> From: David Jencks <da...@yahoo.com>
> Subject: Re: TCK working again
> To: dev@openwebbeans.apache.org
> 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
> >
> >
> >
>
>
Re: TCK working again
Posted by David Jencks <da...@yahoo.com>.
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
>
>
>