10:14 a.m.
I'm looking for volunteers or the people responsible for the existing
-jboss-beans.xml files in jbossas. :-)
The reason is a new way to optimize boot time a bit.
We have two new annotations we can add to our beans.
(1) @org.jboss.beans.metadata.api.annotations.MCAnnotations
This one takes two attributes:
(a) Class<? extends Annotation>[] value() default {};
(b) boolean ignore() default false
With (a) you can provide a set of annotation classes that might be used
on your bean/class to use MC's IoC.
e.g. @org.jboss.beans.metadata.api.annotations.Inject
Only matching plugins will be then used, instead of all.
With (b) you can simply say ignore any @annotation MC IoC lookup.
This is probably mostly true for all beans.
(2) @org.jboss.aop.microcontainer.annotations.DisableAOP
This one instructs MC to ignore transparent AOP usage when handling your
bean.
It will not look for aspect dependencies or try to create an AOP proxy.
It will simply fall back to plain POJO handling.
If you use @JMX or anything similar, this should then *not* be used.
But for anything else it should be good to use it.
How to use this?
(a) either annotate your service/bean classes
(b) simply use xml way of annotating your beans
e.g.
<annotation>(a)org.jboss.beans.metadata.api.annotations.MCAnnotations({org.jboss.beans.metadata.api.annotations.Inject.class})</annotation>
<annotation>(a)org.jboss.aop.microcontainer.annotations.DisableAOP</annotation>
(c) if you know that none of your beans in <deployment> (-beans.xml
file) uses any of the needed features,
you can simply add xml way to the <deployment> element.
This way all beans inherit the annotation from deployment.
So, let's get busy "annotating" those jbossas beans. ;-)
ps: how should we proceed with this? :-)
10:33 a.m.
Aha, another thing you can use to optimize things.
It's the lazy install of OnDemand beans.
e.g.
<bean name="SomeBean" class="org.jboss.acme.Acme" mode="On
Demand"/>
<lazy bean="SomeBean">
<interface>org.jboss.acme.IAcme<interface>
</lazy>
<bean name="DependantBean" class="org.jboss.foobar.Foobar">
<constructor>
<parameter><inject bean="SomeBeanProxy"></parameter>
<constructor>
</bean>
If the bean doesn't have interfaces:
<bean name="OtherBean" class="org.jboss.acme.Acme" mode="On
Demand"/>
<lazy bean="OtherBean" exposeClass="true"/>
<bean name="DependantBean" class="org.jboss.foobar.Foobar">
<constructor>
<parameter><inject bean="OtherBeanProxy"></parameter>
<constructor>
</bean>
10:40 a.m.
What are the SomeBeanProxy and OtherBeanProxy in these examples? And
when exactly are these "lazy" beans installed?
-Jaikiran
Ales Justin wrote:
Aha, another thing you can use to optimize things.
It's the lazy install of OnDemand beans.
e.g.
<bean name="SomeBean" class="org.jboss.acme.Acme" mode="On
Demand"/>
<lazy bean="SomeBean">
<interface>org.jboss.acme.IAcme<interface>
</lazy>
<bean name="DependantBean" class="org.jboss.foobar.Foobar">
<constructor>
<parameter><inject bean="SomeBeanProxy"></parameter>
<constructor>
</bean>
If the bean doesn't have interfaces:
<bean name="OtherBean" class="org.jboss.acme.Acme" mode="On
Demand"/>
<lazy bean="OtherBean" exposeClass="true"/>
<bean name="DependantBean" class="org.jboss.foobar.Foobar">
<constructor>
<parameter><inject bean="OtherBeanProxy"></parameter>
<constructor>
</bean>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
12:30 p.m.
What are the SomeBeanProxy and OtherBeanProxy in these examples?
Those are the lazy proxies generated by <lazy/>.
We try to use the best lazy mechanism available.
(1) Javassist (allows for class exposure in a proxy)
(2) JBossAOP (although currently if this exists, (1) should too)
(3) JDK dynamic proxies (needs interfaces)
I would need to check if we can avoid the explicit injection,
and use lazy nested directly:
<property name="someProp"><lazy
bean"SomeBean"/></property>
And when exactly are these "lazy" beans installed?
They have a dependency on the "bean", at Not_Installed state.
Meaning the minute "bean" is installed in MC, you can have lazy proxy
for it.
-Jaikiran
Ales Justin wrote:
> Aha, another thing you can use to optimize things.
> It's the lazy install of OnDemand beans.
>
> e.g.
> <bean name="SomeBean" class="org.jboss.acme.Acme"
mode="On Demand"/>
>
> <lazy bean="SomeBean">
> <interface>org.jboss.acme.IAcme<interface>
> </lazy>
>
> <bean name="DependantBean"
class="org.jboss.foobar.Foobar">
> <constructor>
> <parameter><inject
bean="SomeBeanProxy"></parameter>
> <constructor>
> </bean>
>
> If the bean doesn't have interfaces:
>
> <bean name="OtherBean" class="org.jboss.acme.Acme"
mode="On Demand"/>
>
> <lazy bean="OtherBean" exposeClass="true"/>
>
> <bean name="DependantBean"
class="org.jboss.foobar.Foobar">
> <constructor>
> <parameter><inject
bean="OtherBeanProxy"></parameter>
> <constructor>
> </bean>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
3:38 a.m.
Is there any place (forum or wiki or anything else) where i can read
about its usage or more about where these kind of lazy beans would come
in handy?
-Jaikiran
Ales Justin wrote:
> What are the SomeBeanProxy and OtherBeanProxy in these examples?
Those are the lazy proxies generated by <lazy/>.
We try to use the best lazy mechanism available.
(1) Javassist (allows for class exposure in a proxy)
(2) JBossAOP (although currently if this exists, (1) should too)
(3) JDK dynamic proxies (needs interfaces)
I would need to check if we can avoid the explicit injection,
and use lazy nested directly:
<property name="someProp"><lazy
bean"SomeBean"/></property>
> And when exactly are these "lazy" beans installed?
They have a dependency on the "bean", at Not_Installed state.
Meaning the minute "bean" is installed in MC, you can have lazy proxy
for it.
> -Jaikiran
> Ales Justin wrote:
>> Aha, another thing you can use to optimize things.
>> It's the lazy install of OnDemand beans.
>>
>> e.g.
>> <bean name="SomeBean" class="org.jboss.acme.Acme"
mode="On Demand"/>
>>
>> <lazy bean="SomeBean">
>> <interface>org.jboss.acme.IAcme<interface>
>> </lazy>
>>
>> <bean name="DependantBean"
class="org.jboss.foobar.Foobar">
>> <constructor>
>> <parameter><inject
bean="SomeBeanProxy"></parameter>
>> <constructor>
>> </bean>
>>
>> If the bean doesn't have interfaces:
>>
>> <bean name="OtherBean" class="org.jboss.acme.Acme"
mode="On Demand"/>
>>
>> <lazy bean="OtherBean" exposeClass="true"/>
>>
>> <bean name="DependantBean"
class="org.jboss.foobar.Foobar">
>> <constructor>
>> <parameter><inject
bean="OtherBeanProxy"></parameter>
>> <constructor>
>> </bean>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
3:42 a.m.
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=154873
Jaikiran Pai wrote:
Is there any place (forum or wiki or anything else) where i can read
about its usage or more about where these kind of lazy beans would come
in handy?
-Jaikiran
Ales Justin wrote:
>> What are the SomeBeanProxy and OtherBeanProxy in these examples?
>
> Those are the lazy proxies generated by <lazy/>.
>
> We try to use the best lazy mechanism available.
> (1) Javassist (allows for class exposure in a proxy)
> (2) JBossAOP (although currently if this exists, (1) should too)
> (3) JDK dynamic proxies (needs interfaces)
>
> I would need to check if we can avoid the explicit injection,
> and use lazy nested directly:
>
> <property name="someProp"><lazy
bean"SomeBean"/></property>
>
>> And when exactly are these "lazy" beans installed?
>
> They have a dependency on the "bean", at Not_Installed state.
> Meaning the minute "bean" is installed in MC, you can have lazy proxy
> for it.
>
>> -Jaikiran
>> Ales Justin wrote:
>>> Aha, another thing you can use to optimize things.
>>> It's the lazy install of OnDemand beans.
>>>
>>> e.g.
>>> <bean name="SomeBean" class="org.jboss.acme.Acme"
mode="On Demand"/>
>>>
>>> <lazy bean="SomeBean">
>>> <interface>org.jboss.acme.IAcme<interface>
>>> </lazy>
>>>
>>> <bean name="DependantBean"
class="org.jboss.foobar.Foobar">
>>> <constructor>
>>> <parameter><inject
bean="SomeBeanProxy"></parameter>
>>> <constructor>
>>> </bean>
>>>
>>> If the bean doesn't have interfaces:
>>>
>>> <bean name="OtherBean" class="org.jboss.acme.Acme"
mode="On Demand"/>
>>>
>>> <lazy bean="OtherBean" exposeClass="true"/>
>>>
>>> <bean name="DependantBean"
class="org.jboss.foobar.Foobar">
>>> <constructor>
>>> <parameter><inject
bean="OtherBeanProxy"></parameter>
>>> <constructor>
>>> </bean>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
4:59 a.m.
Thanks Ales.
Based on the discussion in that thread, i understand that the "lazy"
bean will be activated on the first access (of constructor, field or
method). So here's a silly question - What stops a MC bean developer to
mark all (or most of beans) as lazy? :) That way, almost of the beans
are going to be inited (and passed through various MC lifecycle phases?)
only when they are accessed. Would this be considered a right approach?
-Jaikiran
Ales Justin wrote:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=154873
Jaikiran Pai wrote:
> Is there any place (forum or wiki or anything else) where i can read
> about its usage or more about where these kind of lazy beans would
> come in handy?
>
> -Jaikiran
> Ales Justin wrote:
>>> What are the SomeBeanProxy and OtherBeanProxy in these examples?
>>
>> Those are the lazy proxies generated by <lazy/>.
>>
>> We try to use the best lazy mechanism available.
>> (1) Javassist (allows for class exposure in a proxy)
>> (2) JBossAOP (although currently if this exists, (1) should too)
>> (3) JDK dynamic proxies (needs interfaces)
>>
>> I would need to check if we can avoid the explicit injection,
>> and use lazy nested directly:
>>
>> <property name="someProp"><lazy
bean"SomeBean"/></property>
>>
>>> And when exactly are these "lazy" beans installed?
>>
>> They have a dependency on the "bean", at Not_Installed state.
>> Meaning the minute "bean" is installed in MC, you can have lazy
>> proxy for it.
>>
>>> -Jaikiran
>>> Ales Justin wrote:
>>>> Aha, another thing you can use to optimize things.
>>>> It's the lazy install of OnDemand beans.
>>>>
>>>> e.g.
>>>> <bean name="SomeBean" class="org.jboss.acme.Acme"
mode="On Demand"/>
>>>>
>>>> <lazy bean="SomeBean">
>>>> <interface>org.jboss.acme.IAcme<interface>
>>>> </lazy>
>>>>
>>>> <bean name="DependantBean"
class="org.jboss.foobar.Foobar">
>>>> <constructor>
>>>> <parameter><inject
bean="SomeBeanProxy"></parameter>
>>>> <constructor>
>>>> </bean>
>>>>
>>>> If the bean doesn't have interfaces:
>>>>
>>>> <bean name="OtherBean" class="org.jboss.acme.Acme"
mode="On Demand"/>
>>>>
>>>> <lazy bean="OtherBean" exposeClass="true"/>
>>>>
>>>> <bean name="DependantBean"
class="org.jboss.foobar.Foobar">
>>>> <constructor>
>>>> <parameter><inject
bean="OtherBeanProxy"></parameter>
>>>> <constructor>
>>>> </bean>
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
7:25 a.m.
Based on the discussion in that thread, i understand that the
"lazy"
bean will be activated on the first access (of constructor, field or
method). So here's a silly question - What stops a MC bean developer to
mark all (or most of beans) as lazy? :) That way, almost of the beans
are going to be inited (and passed through various MC lifecycle phases?)
only when they are accessed. Would this be considered a right approach?
Definitely no. :-)
Why would you wanna "jump through hoops" for beans you know they
should/must be fully installed the moment they are dropped in.
e.g. vfs cache, log manager, deployers, binding service, ...
The proper criteria is up to the user, but it shouldn't be hard to spot
the right lazy candidates.
e.g. having TransactionManager in minimal conf
Ales Justin wrote:
> http://www.jboss.org/index.html?module=bb&op=viewtopic&t=154873
>
> Jaikiran Pai wrote:
>> Is there any place (forum or wiki or anything else) where i can read
>> about its usage or more about where these kind of lazy beans would
>> come in handy?
>>
>> -Jaikiran
>> Ales Justin wrote:
>>>> What are the SomeBeanProxy and OtherBeanProxy in these examples?
>>>
>>> Those are the lazy proxies generated by <lazy/>.
>>>
>>> We try to use the best lazy mechanism available.
>>> (1) Javassist (allows for class exposure in a proxy)
>>> (2) JBossAOP (although currently if this exists, (1) should too)
>>> (3) JDK dynamic proxies (needs interfaces)
>>>
>>> I would need to check if we can avoid the explicit injection,
>>> and use lazy nested directly:
>>>
>>> <property name="someProp"><lazy
bean"SomeBean"/></property>
>>>
>>>> And when exactly are these "lazy" beans installed?
>>>
>>> They have a dependency on the "bean", at Not_Installed state.
>>> Meaning the minute "bean" is installed in MC, you can have lazy
>>> proxy for it.
>>>
>>>> -Jaikiran
>>>> Ales Justin wrote:
>>>>> Aha, another thing you can use to optimize things.
>>>>> It's the lazy install of OnDemand beans.
>>>>>
>>>>> e.g.
>>>>> <bean name="SomeBean"
class="org.jboss.acme.Acme" mode="On Demand"/>
>>>>>
>>>>> <lazy bean="SomeBean">
>>>>> <interface>org.jboss.acme.IAcme<interface>
>>>>> </lazy>
>>>>>
>>>>> <bean name="DependantBean"
class="org.jboss.foobar.Foobar">
>>>>> <constructor>
>>>>> <parameter><inject
bean="SomeBeanProxy"></parameter>
>>>>> <constructor>
>>>>> </bean>
>>>>>
>>>>> If the bean doesn't have interfaces:
>>>>>
>>>>> <bean name="OtherBean"
class="org.jboss.acme.Acme" mode="On Demand"/>
>>>>>
>>>>> <lazy bean="OtherBean"
exposeClass="true"/>
>>>>>
>>>>> <bean name="DependantBean"
class="org.jboss.foobar.Foobar">
>>>>> <constructor>
>>>>> <parameter><inject
bean="OtherBeanProxy"></parameter>
>>>>> <constructor>
>>>>> </bean>
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
11:46 a.m.
We need the mc project release that has this and then create a container
jira for subtasks for updating the jbossas 6 deployments that will be
most improved by this.
Ales Justin wrote:
So, let's get busy "annotating" those jbossas beans. ;-)
ps: how should we proceed with this? :-)
12:32 p.m.
We need the mc project release that has this and then create a
container
jira for subtasks for updating the jbossas 6 deployments that will be
most improved by this.
The MC release that has this was just released/committed today,
and is already in 5_x.
I still need to port this to jbossas trunk.
> So, let's get busy "annotating" those jbossas
beans. ;-)
>
> ps: how should we proceed with this? :-)
10:49 a.m.
Ales Justin wrote:
> We need the mc project release that has this and then create a
> container jira for subtasks for updating the jbossas 6 deployments
> that will be most improved by this.
The MC release that has this was just released/committed today,
and is already in 5_x.
I still need to port this to jbossas trunk.
Ales, once you are done with the
necessary changes in AS trunk too,
could you please create a JIRA so that EJB3 can create a sub-task to
take care of these configurations?
On my local setup, the use of these configurations to disable AOP
dependency building on EJB3 MC beans has shown good numbers.
-Jaikiran
>> So, let's get busy "annotating" those jbossas beans. ;-)
>>
>> ps: how should we proceed with this? :-)
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
12:23 p.m.
How about a hypothetical:
(3) @org.jboss.aop.microcontainer.annotations.EnableAOP
and fall back to plain POJO handling by default.
Ales Justin wrote:
I'm looking for volunteers or the people responsible for the
existing
-jboss-beans.xml files in jbossas. :-)
The reason is a new way to optimize boot time a bit.
We have two new annotations we can add to our beans.
(1) @org.jboss.beans.metadata.api.annotations.MCAnnotations
This one takes two attributes:
(a) Class<? extends Annotation>[] value() default {};
(b) boolean ignore() default false
With (a) you can provide a set of annotation classes that might be used
on your bean/class to use MC's IoC.
e.g. @org.jboss.beans.metadata.api.annotations.Inject
Only matching plugins will be then used, instead of all.
With (b) you can simply say ignore any @annotation MC IoC lookup.
This is probably mostly true for all beans.
(2) @org.jboss.aop.microcontainer.annotations.DisableAOP
This one instructs MC to ignore transparent AOP usage when handling your
bean.
It will not look for aspect dependencies or try to create an AOP proxy.
It will simply fall back to plain POJO handling.
If you use @JMX or anything similar, this should then *not* be used.
But for anything else it should be good to use it.
How to use this?
(a) either annotate your service/bean classes
(b) simply use xml way of annotating your beans
e.g.
<annotation>(a)org.jboss.beans.metadata.api.annotations.MCAnnotations({org.jboss.beans.metadata.api.annotations.Inject.class})</annotation>
<annotation>(a)org.jboss.aop.microcontainer.annotations.DisableAOP</annotation>
(c) if you know that none of your beans in <deployment> (-beans.xml
file) uses any of the needed features,
you can simply add xml way to the <deployment> element.
This way all beans inherit the annotation from deployment.
So, let's get busy "annotating" those jbossas beans. ;-)
ps: how should we proceed with this? :-)
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
12:39 p.m.
That sounds like a good idea. Consider also the growing number of bean
declarations that are currently created programmatically by other deployers
- most (maybe all) of these would have to be refitted to add these
annotations. Better to keep the defaults to the common case if possible.
- DML
On 05/13/2009 12:23 PM, Brian Stansberry wrote:
How about a hypothetical:
(3) @org.jboss.aop.microcontainer.annotations.EnableAOP
and fall back to plain POJO handling by default.
Ales Justin wrote:
> I'm looking for volunteers or the people responsible for the existing
> -jboss-beans.xml files in jbossas. :-)
>
> The reason is a new way to optimize boot time a bit.
> We have two new annotations we can add to our beans.
>
> (1) @org.jboss.beans.metadata.api.annotations.MCAnnotations
>
> This one takes two attributes:
> (a) Class<? extends Annotation>[] value() default {};
> (b) boolean ignore() default false
>
> With (a) you can provide a set of annotation classes that might be
> used on your bean/class to use MC's IoC.
> e.g. @org.jboss.beans.metadata.api.annotations.Inject
> Only matching plugins will be then used, instead of all.
>
> With (b) you can simply say ignore any @annotation MC IoC lookup.
> This is probably mostly true for all beans.
>
> (2) @org.jboss.aop.microcontainer.annotations.DisableAOP
>
> This one instructs MC to ignore transparent AOP usage when handling
> your bean.
> It will not look for aspect dependencies or try to create an AOP proxy.
> It will simply fall back to plain POJO handling.
>
> If you use @JMX or anything similar, this should then *not* be used.
> But for anything else it should be good to use it.
>
> How to use this?
> (a) either annotate your service/bean classes
> (b) simply use xml way of annotating your beans
>
> e.g.
>
<annotation>(a)org.jboss.beans.metadata.api.annotations.MCAnnotations({org.jboss.beans.metadata.api.annotations.Inject.class})</annotation>
>
>
<annotation>(a)org.jboss.aop.microcontainer.annotations.DisableAOP</annotation>
>
>
> (c) if you know that none of your beans in <deployment> (-beans.xml
> file) uses any of the needed features,
> you can simply add xml way to the <deployment> element.
> This way all beans inherit the annotation from deployment.
>
> So, let's get busy "annotating" those jbossas beans. ;-)
>
> ps: how should we proceed with this? :-)
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
12:40 p.m.
How about a hypothetical:
(3) @org.jboss.aop.microcontainer.annotations.EnableAOP
and fall back to plain POJO handling by default.
This is already the case == we don't use AOP if there is no match.
But this requires not-so-trivial mechanism == slow.
The problem is that AOP matching is more than just annotations,
hence you cannot easily determine when you need it and when you don't.
Negating this is more straightfwd, if you ask me.
But yeah, this can be discussed more,
as this can easily be made configurable.
e.g. via new DependencyBuilder and ConstructorJoinpoint impl
Ales Justin wrote:
> I'm looking for volunteers or the people responsible for the existing
> -jboss-beans.xml files in jbossas. :-)
>
> The reason is a new way to optimize boot time a bit.
> We have two new annotations we can add to our beans.
>
> (1) @org.jboss.beans.metadata.api.annotations.MCAnnotations
>
> This one takes two attributes:
> (a) Class<? extends Annotation>[] value() default {};
> (b) boolean ignore() default false
>
> With (a) you can provide a set of annotation classes that might be
> used on your bean/class to use MC's IoC.
> e.g. @org.jboss.beans.metadata.api.annotations.Inject
> Only matching plugins will be then used, instead of all.
>
> With (b) you can simply say ignore any @annotation MC IoC lookup.
> This is probably mostly true for all beans.
>
> (2) @org.jboss.aop.microcontainer.annotations.DisableAOP
>
> This one instructs MC to ignore transparent AOP usage when handling
> your bean.
> It will not look for aspect dependencies or try to create an AOP proxy.
> It will simply fall back to plain POJO handling.
>
> If you use @JMX or anything similar, this should then *not* be used.
> But for anything else it should be good to use it.
>
> How to use this?
> (a) either annotate your service/bean classes
> (b) simply use xml way of annotating your beans
>
> e.g.
>
<annotation>(a)org.jboss.beans.metadata.api.annotations.MCAnnotations({org.jboss.beans.metadata.api.annotations.Inject.class})</annotation>
>
>
<annotation>(a)org.jboss.aop.microcontainer.annotations.DisableAOP</annotation>
>
>
> (c) if you know that none of your beans in <deployment> (-beans.xml
> file) uses any of the needed features,
> you can simply add xml way to the <deployment> element.
> This way all beans inherit the annotation from deployment.
>
> So, let's get busy "annotating" those jbossas beans. ;-)
>
> ps: how should we proceed with this? :-)
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
1:01 p.m.
Ales Justin wrote:
> How about a hypothetical:
>
> (3) @org.jboss.aop.microcontainer.annotations.EnableAOP
>
> and fall back to plain POJO handling by default.
This is already the case == we don't use AOP if there is no match.
But this requires not-so-trivial mechanism == slow.
The problem is that AOP matching is more than just annotations,
hence you cannot easily determine when you need it and when you don't.
Should I as a bean developer understand when I need it and when I don't?
(I'm truly asking, although my instinct is that I should.) If I should,
and it's not the common case, I think it's much better to require me to
explicitly configure my bean. I'm very suspicious of under-the-covers
magic that causes things to happen that I didn't understand/plan for. It
makes things hard to maintain.
Negating this is more straightfwd, if you ask me.
But yeah, this can be discussed more,
as this can easily be made configurable.
e.g. via new DependencyBuilder and ConstructorJoinpoint impl
> Ales Justin wrote:
>> I'm looking for volunteers or the people responsible for the existing
>> -jboss-beans.xml files in jbossas. :-)
>>
>> The reason is a new way to optimize boot time a bit.
>> We have two new annotations we can add to our beans.
>>
>> (1) @org.jboss.beans.metadata.api.annotations.MCAnnotations
>>
>> This one takes two attributes:
>> (a) Class<? extends Annotation>[] value() default {};
>> (b) boolean ignore() default false
>>
>> With (a) you can provide a set of annotation classes that might be
>> used on your bean/class to use MC's IoC.
>> e.g. @org.jboss.beans.metadata.api.annotations.Inject
>> Only matching plugins will be then used, instead of all.
>>
>> With (b) you can simply say ignore any @annotation MC IoC lookup.
>> This is probably mostly true for all beans.
>>
>> (2) @org.jboss.aop.microcontainer.annotations.DisableAOP
>>
>> This one instructs MC to ignore transparent AOP usage when handling
>> your bean.
>> It will not look for aspect dependencies or try to create an AOP proxy.
>> It will simply fall back to plain POJO handling.
>>
>> If you use @JMX or anything similar, this should then *not* be used.
>> But for anything else it should be good to use it.
>>
>> How to use this?
>> (a) either annotate your service/bean classes
>> (b) simply use xml way of annotating your beans
>>
>> e.g.
>>
<annotation>(a)org.jboss.beans.metadata.api.annotations.MCAnnotations({org.jboss.beans.metadata.api.annotations.Inject.class})</annotation>
>>
>>
<annotation>(a)org.jboss.aop.microcontainer.annotations.DisableAOP</annotation>
>>
>>
>> (c) if you know that none of your beans in <deployment> (-beans.xml
>> file) uses any of the needed features,
>> you can simply add xml way to the <deployment> element.
>> This way all beans inherit the annotation from deployment.
>>
>> So, let's get busy "annotating" those jbossas beans. ;-)
>>
>> ps: how should we proceed with this? :-)
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
1:59 p.m.
Should I as a bean developer understand when I need it and when I
don't?
(I'm truly asking, although my instinct is that I should.)
Yes, you should. And it's not hard to do so.
To leave out (1) or use (1)'s value you are probably using one of the
org.jboss.beans.metadata.api.annotations.* annotations in your bean class.
(or your custom annotation + pluing - like ALR does here:
http://exitcondition.alrubinger.com/2008/12/20/doing-two-models-at-the-sa...)
To use (2) you are 100% sure you don't wanna aspectize your bean.
e.g. I'm pretty sure we don't wanna our deployers as AOP proxies
If I should, and it's not the common case, I think it's much
better to require me to
explicitly configure my bean. I'm very suspicious of under-the-covers
magic that causes things to happen that I didn't understand/plan for. It
makes things hard to maintain.
There is no magic.
We know AOP is there from day one,
and @annotation based IoC handling is a-must-have in these jsr-299 days.
It's just that the sole nature of these mechanisms is not very
performance friendly.
I don't know enough about our AOP impl to say why is that,
but the @IoC is slow due to the MDR lookup approach.
Which we must use if we should claim per instance configuration.
> Negating this is more straightfwd, if you ask me.
>
> But yeah, this can be discussed more,
> as this can easily be made configurable.
> e.g. via new DependencyBuilder and ConstructorJoinpoint impl
>
>> Ales Justin wrote:
>>> I'm looking for volunteers or the people responsible for the
>>> existing -jboss-beans.xml files in jbossas. :-)
>>>
>>> The reason is a new way to optimize boot time a bit.
>>> We have two new annotations we can add to our beans.
>>>
>>> (1) @org.jboss.beans.metadata.api.annotations.MCAnnotations
>>>
>>> This one takes two attributes:
>>> (a) Class<? extends Annotation>[] value() default {};
>>> (b) boolean ignore() default false
>>>
>>> With (a) you can provide a set of annotation classes that might be
>>> used on your bean/class to use MC's IoC.
>>> e.g. @org.jboss.beans.metadata.api.annotations.Inject
>>> Only matching plugins will be then used, instead of all.
>>>
>>> With (b) you can simply say ignore any @annotation MC IoC lookup.
>>> This is probably mostly true for all beans.
>>>
>>> (2) @org.jboss.aop.microcontainer.annotations.DisableAOP
>>>
>>> This one instructs MC to ignore transparent AOP usage when handling
>>> your bean.
>>> It will not look for aspect dependencies or try to create an AOP proxy.
>>> It will simply fall back to plain POJO handling.
>>>
>>> If you use @JMX or anything similar, this should then *not* be used.
>>> But for anything else it should be good to use it.
>>>
>>> How to use this?
>>> (a) either annotate your service/bean classes
>>> (b) simply use xml way of annotating your beans
>>>
>>> e.g.
>>>
<annotation>(a)org.jboss.beans.metadata.api.annotations.MCAnnotations({org.jboss.beans.metadata.api.annotations.Inject.class})</annotation>
>>>
>>>
<annotation>(a)org.jboss.aop.microcontainer.annotations.DisableAOP</annotation>
>>>
>>>
>>> (c) if you know that none of your beans in <deployment> (-beans.xml
>>> file) uses any of the needed features,
>>> you can simply add xml way to the <deployment> element.
>>> This way all beans inherit the annotation from deployment.
>>>
>>> So, let's get busy "annotating" those jbossas beans. ;-)
>>>
>>> ps: how should we proceed with this? :-)
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
2:42 p.m.
Ales Justin wrote:
> Should I as a bean developer understand when I need it and when I
> don't? (I'm truly asking, although my instinct is that I should.)
Yes, you should. And it's not hard to do so.
To leave out (1) or use (1)'s value you are probably using one of the
org.jboss.beans.metadata.api.annotations.* annotations in your bean class.
(or your custom annotation + pluing - like ALR does here:
http://exitcondition.alrubinger.com/2008/12/20/doing-two-models-at-the-sa...)
Sure, (1) is straightforward and clear.
To use (2) you are 100% sure you don't wanna aspectize your bean.
e.g. I'm pretty sure we don't wanna our deployers as AOP proxies
It's that "100% sure" part that's the rub. :) I 100% know how I expect
my beans to be used. But I could easily be unaware of some subtlety in
how, for example, the ProfileService management view uses them.
But this quote from your first post sums it up pretty well; I should
have focused more on it:
>>>> (2)
@org.jboss.aop.microcontainer.annotations.DisableAOP
>>>>
<snip/>
>>>>
>>>> If you use @JMX or anything similar, this should then *not* be used.
>>>> But for anything else it should be good to use it.
Having a quick look through the beans in the deploy dir, a high % have
the @JMX annotation declared via xml, and probably many more have it in
the java code. That's a good argument for needing to @DisableAOP as the
norm rather than an @EnableAOP.
- Brian
12:15 p.m.
Ales Justin wrote:
There is no magic.
We know AOP is there from day one,
and @annotation based IoC handling is a-must-have in these jsr-299 days.
It's just that the sole nature of these mechanisms is not very
performance friendly.
Annotation IoC handling != AOP. This is just an implementation we chose.
The JSR-299 RI for example does not require AOP.
The AOP dependency processing "magic" is a great example of something we
don't need for container provided annotations like @JMX. Those should
all be registered up-front.
12:25 p.m.
Sure, I never implied it is the same.
I might wrote it in a confusing way.
AOP is there from day one --> @DisableAOP
@IoC & jsr-299 --> our MC IoC should support that too; annotation
based ioc
And we don't use AOP with our MC @IoC.
Just MDR, for already stated reasons.
Sent from my iPhone
On May 14, 2009, at 19:15, "Jason T. Greene" <jason.greene(a)redhat.com>
wrote:
Ales Justin wrote:
> There is no magic.
> We know AOP is there from day one,
> and @annotation based IoC handling is a-must-have in these jsr-299
> days.
>
> It's just that the sole nature of these mechanisms is not very
> performance friendly.
Annotation IoC handling != AOP. This is just an implementation we
chose. The JSR-299 RI for example does not require AOP.
The AOP dependency processing "magic" is a great example of
something we don't need for container provided annotations like
@JMX. Those should all be registered up-front.
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
1:20 p.m.
Ah, yeah now I understand what you meant. Nevermind then.
Ales Justin wrote:
Sure, I never implied it is the same.
I might wrote it in a confusing way.
AOP is there from day one --> @DisableAOP
@IoC & jsr-299 --> our MC IoC should support that too; annotation based ioc
And we don't use AOP with our MC @IoC.
Just MDR, for already stated reasons.
Sent from my iPhone
On May 14, 2009, at 19:15, "Jason T. Greene" <jason.greene(a)redhat.com>
wrote:
> Ales Justin wrote:
>> There is no magic.
>> We know AOP is there from day one,
>> and @annotation based IoC handling is a-must-have in these jsr-299 days.
>>
>> It's just that the sole nature of these mechanisms is not very
>> performance friendly.
>
> Annotation IoC handling != AOP. This is just an implementation we
> chose. The JSR-299 RI for example does not require AOP.
>
> The AOP dependency processing "magic" is a great example of something
> we don't need for container provided annotations like @JMX. Those
> should all be registered up-front.
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
1:27 p.m.
Ales Justin wrote:
(2) @org.jboss.aop.microcontainer.annotations.DisableAOP
This one instructs MC to ignore transparent AOP usage when handling your
bean.
It will not look for aspect dependencies or try to create an AOP proxy.
It will simply fall back to plain POJO handling.
If you use @JMX or anything similar, this should then *not* be used.
But for anything else it should be good to use it.
Can we fix the @JMX (and other known cases) by deploying them sooner, as
part of the bootstrap for example?
1:36 p.m.
The registration of the @JMX handling is in the bootstrap, in
bootstrap/jmx.xml.
Jason T. Greene wrote:
Ales Justin wrote:
> (2) @org.jboss.aop.microcontainer.annotations.DisableAOP
>
> This one instructs MC to ignore transparent AOP usage when handling
> your bean.
> It will not look for aspect dependencies or try to create an AOP proxy.
> It will simply fall back to plain POJO handling.
>
> If you use @JMX or anything similar, this should then *not* be used.
> But for anything else it should be good to use it.
Can we fix the @JMX (and other known cases) by deploying them sooner, as
part of the bootstrap for example?
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
2:15 p.m.
Ok, so then, why do we need AOPDependencyBuilder to use @JMX? Yes I know
the dep builder allows for users to add aspects after the fact, but this
is a near *useless* feature, especially for our core components.
Brian Stansberry wrote:
The registration of the @JMX handling is in the bootstrap, in
bootstrap/jmx.xml.
Jason T. Greene wrote:
> Ales Justin wrote:
>> (2) @org.jboss.aop.microcontainer.annotations.DisableAOP
>>
>> This one instructs MC to ignore transparent AOP usage when handling
>> your bean.
>> It will not look for aspect dependencies or try to create an AOP proxy.
>> It will simply fall back to plain POJO handling.
>>
>> If you use @JMX or anything similar, this should then *not* be used.
>> But for anything else it should be good to use it.
>
> Can we fix the @JMX (and other known cases) by deploying them sooner,
> as part of the bootstrap for example?
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
2:30 p.m.
I don't think we need AOPBD for this. Kabir?
Hmmm, perhaps something like this should be on the @DisableAOP:
@DisableAOP(allow={INSTANTIATE})
which would mean we don't use AOPDB - since the aspect we expect with
this bean don't have any dependencies,
but we do want AOP proxy instantiation, since we *do* expect the bean to
be aspectized.
Jason T. Greene wrote:
Ok, so then, why do we need AOPDependencyBuilder to use @JMX? Yes I
know
the dep builder allows for users to add aspects after the fact, but this
is a near *useless* feature, especially for our core components.
Brian Stansberry wrote:
> The registration of the @JMX handling is in the bootstrap, in
> bootstrap/jmx.xml.
>
> Jason T. Greene wrote:
>> Ales Justin wrote:
>>> (2) @org.jboss.aop.microcontainer.annotations.DisableAOP
>>>
>>> This one instructs MC to ignore transparent AOP usage when handling
>>> your bean.
>>> It will not look for aspect dependencies or try to create an AOP proxy.
>>> It will simply fall back to plain POJO handling.
>>>
>>> If you use @JMX or anything similar, this should then *not* be used.
>>> But for anything else it should be good to use it.
>>
>> Can we fix the @JMX (and other known cases) by deploying them sooner,
>> as part of the bootstrap for example?
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
2:57 p.m.
If not, that re-opens the discussion as to whether @DisableAOP should be
required, or should be default behavior with an @EnableAOP. Since AFAICT
the thing that made me thing enabling it was required for the common
case was @JMX.
Ales Justin wrote:
I don't think we need AOPBD for this. Kabir?
Hmmm, perhaps something like this should be on the @DisableAOP:
@DisableAOP(allow={INSTANTIATE})
which would mean we don't use AOPDB - since the aspect we expect with
this bean don't have any dependencies,
but we do want AOP proxy instantiation, since we *do* expect the bean to
be aspectized.
Jason T. Greene wrote:
> Ok, so then, why do we need AOPDependencyBuilder to use @JMX? Yes I
> know the dep builder allows for users to add aspects after the fact,
> but this is a near *useless* feature, especially for our core components.
>
> Brian Stansberry wrote:
>> The registration of the @JMX handling is in the bootstrap, in
>> bootstrap/jmx.xml.
>>
>> Jason T. Greene wrote:
>>> Ales Justin wrote:
>>>> (2) @org.jboss.aop.microcontainer.annotations.DisableAOP
>>>>
>>>> This one instructs MC to ignore transparent AOP usage when handling
>>>> your bean.
>>>> It will not look for aspect dependencies or try to create an AOP
>>>> proxy.
>>>> It will simply fall back to plain POJO handling.
>>>>
>>>> If you use @JMX or anything similar, this should then *not* be used.
>>>> But for anything else it should be good to use it.
>>>
>>> Can we fix the @JMX (and other known cases) by deploying them
>>> sooner, as part of the bootstrap for example?
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
3:01 p.m.
Hear hear. Make it disabled by default.
Burn it at the stake!
- DML
On 05/14/2009 02:57 PM, Brian Stansberry wrote:
If not, that re-opens the discussion as to whether @DisableAOP should
be
required, or should be default behavior with an @EnableAOP. Since AFAICT
the thing that made me thing enabling it was required for the common
case was @JMX.
Ales Justin wrote:
> I don't think we need AOPBD for this. Kabir?
>
> Hmmm, perhaps something like this should be on the @DisableAOP:
> @DisableAOP(allow={INSTANTIATE})
> which would mean we don't use AOPDB - since the aspect we expect with
> this bean don't have any dependencies,
> but we do want AOP proxy instantiation, since we *do* expect the bean
> to be aspectized.
>
> Jason T. Greene wrote:
>> Ok, so then, why do we need AOPDependencyBuilder to use @JMX? Yes I
>> know the dep builder allows for users to add aspects after the fact,
>> but this is a near *useless* feature, especially for our core
>> components.
>>
>> Brian Stansberry wrote:
>>> The registration of the @JMX handling is in the bootstrap, in
>>> bootstrap/jmx.xml.
>>>
>>> Jason T. Greene wrote:
>>>> Ales Justin wrote:
>>>>> (2) @org.jboss.aop.microcontainer.annotations.DisableAOP
>>>>>
>>>>> This one instructs MC to ignore transparent AOP usage when
>>>>> handling your bean.
>>>>> It will not look for aspect dependencies or try to create an AOP
>>>>> proxy.
>>>>> It will simply fall back to plain POJO handling.
>>>>>
>>>>> If you use @JMX or anything similar, this should then *not* be used.
>>>>> But for anything else it should be good to use it.
>>>>
>>>> Can we fix the @JMX (and other known cases) by deploying them
>>>> sooner, as part of the bootstrap for example?
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>>
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
3:04 p.m.
No, I think we're still at the level where you agree. :-)
As this "not" can only be applied to AOPDependencyBuilder,
not on the AOPConstructorJoinpoint.
Or I think it's just the other way around. Kabir would know better.
Somewhere AOP does kick in, as it knows how to add AOP's lifecycle
callbacks to ControllerContext.
Brian Stansberry wrote:
If not, that re-opens the discussion as to whether @DisableAOP should
be
required, or should be default behavior with an @EnableAOP. Since AFAICT
the thing that made me thing enabling it was required for the common
case was @JMX.
Ales Justin wrote:
> I don't think we need AOPBD for this. Kabir?
>
> Hmmm, perhaps something like this should be on the @DisableAOP:
> @DisableAOP(allow={INSTANTIATE})
> which would mean we don't use AOPDB - since the aspect we expect with
> this bean don't have any dependencies,
> but we do want AOP proxy instantiation, since we *do* expect the bean
> to be aspectized.
>
> Jason T. Greene wrote:
>> Ok, so then, why do we need AOPDependencyBuilder to use @JMX? Yes I
>> know the dep builder allows for users to add aspects after the fact,
>> but this is a near *useless* feature, especially for our core
>> components.
>>
>> Brian Stansberry wrote:
>>> The registration of the @JMX handling is in the bootstrap, in
>>> bootstrap/jmx.xml.
>>>
>>> Jason T. Greene wrote:
>>>> Ales Justin wrote:
>>>>> (2) @org.jboss.aop.microcontainer.annotations.DisableAOP
>>>>>
>>>>> This one instructs MC to ignore transparent AOP usage when
>>>>> handling your bean.
>>>>> It will not look for aspect dependencies or try to create an AOP
>>>>> proxy.
>>>>> It will simply fall back to plain POJO handling.
>>>>>
>>>>> If you use @JMX or anything similar, this should then *not* be used.
>>>>> But for anything else it should be good to use it.
>>>>
>>>> Can we fix the @JMX (and other known cases) by deploying them
>>>> sooner, as part of the bootstrap for example?
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>>
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
4:19 a.m.
AOPDependencyBuilder:
1) Checks for any dependencies from "normal" aspects requiring a proxy
or weaving
2) Checks for dependencies from aop lifecycle callbacks, and also puts
those in the KernelControllerContext's DependencyInfo. These do not
require a proxy orweaving
AOPConstructorJoinpoint:
Checks for "normal" aspects (1 above) and creates an aop proxy if
those exist
As I mentioned here
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230773#...
, this can be made more fine-grained. We could only check for aop
lifecycle things like JMX in AOPDependencyBuilder and not bother with
all the rest of the "normal" bindings.
On 14 May 2009, at 21:04, Ales Justin wrote:
No, I think we're still at the level where you agree. :-)
As this "not" can only be applied to AOPDependencyBuilder,
not on the AOPConstructorJoinpoint.
Or I think it's just the other way around. Kabir would know better.
Somewhere AOP does kick in, as it knows how to add AOP's lifecycle
callbacks to ControllerContext.
Brian Stansberry wrote:
> If not, that re-opens the discussion as to whether @DisableAOP
> should be required, or should be default behavior with an
> @EnableAOP. Since AFAICT the thing that made me thing enabling it
> was required for the common case was @JMX.
> Ales Justin wrote:
>> I don't think we need AOPBD for this. Kabir?
>>
>> Hmmm, perhaps something like this should be on the @DisableAOP:
>> @DisableAOP(allow={INSTANTIATE})
>> which would mean we don't use AOPDB - since the aspect we expect
>> with this bean don't have any dependencies,
>> but we do want AOP proxy instantiation, since we *do* expect the
>> bean to be aspectized.
>>
>> Jason T. Greene wrote:
>>> Ok, so then, why do we need AOPDependencyBuilder to use @JMX? Yes
>>> I know the dep builder allows for users to add aspects after the
>>> fact, but this is a near *useless* feature, especially for our
>>> core components.
>>>
>>> Brian Stansberry wrote:
>>>> The registration of the @JMX handling is in the bootstrap, in
>>>> bootstrap/jmx.xml.
>>>>
>>>> Jason T. Greene wrote:
>>>>> Ales Justin wrote:
>>>>>> (2) @org.jboss.aop.microcontainer.annotations.DisableAOP
>>>>>>
>>>>>> This one instructs MC to ignore transparent AOP usage when
>>>>>> handling your bean.
>>>>>> It will not look for aspect dependencies or try to create an
>>>>>> AOP proxy.
>>>>>> It will simply fall back to plain POJO handling.
>>>>>>
>>>>>> If you use @JMX or anything similar, this should then *not* be
>>>>>> used.
>>>>>> But for anything else it should be good to use it.
>>>>>
>>>>> Can we fix the @JMX (and other known cases) by deploying them
>>>>> sooner, as part of the bootstrap for example?
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>
>>>>
>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
10:22 a.m.
Just to see how much improvement this brings in to AS boot time and how
much efforts it takes to use the @DisableAOP, i tried a few things on
5_x branch:
1) Since the AOPDependencyBuilder is meant for things like @JMX, i just
searched for the number of files that need this support. In the
"default" profile we have 10 files (ignore deployers.xml and jmx.xml for
now):
./server/default/deploy/remoting-jboss-beans.xml
./server/default/deploy/vfs-jboss-beans.xml
./server/default/deploy/jca-jboss-beans.xml
./server/default/deploy/jbossweb.sar/META-INF/jboss-beans.xml
./server/default/deploy/transaction-jboss-beans.xml
./server/default/deploy/messaging/messaging-jboss-beans.xml
./server/default/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml
./server/default/conf/bootstrap/deployers.xml
./server/default/conf/bootstrap/jmx.xml
./server/default/deployers/jsr77-deployers-jboss-beans.xml
The "all" profile has a few more (in clustering).
So out of all the MC beans that are being deployed (there are a lot)
there's only 10 files (and not all MC beans in this file might need @JMX
support) in the default profile for which the AOPDependencyBuilder
probably makes sense.
2) So the next obviously was to add @DisableAOP to rest of all the
-jboss-beans.xml which don't need the AOPDependencyBuilder. Obviously,
this is not easy since there are a lot. And as and when we start adding
new MC beans there's no guarantee that the developer even "remembers" to
add this @DisableAOP.
3) I decided to instead patch in a code to use a new annotation
@EnableAOP which could be used for beans which need the
AOPDependencyBuilderSupport. So i just have to edit 8 files in the
default profile. The other advantage of this approach is that when a
developer is trying to get the @JMX (or some similar) support working
and if he doesn't get it working then he sure will "remember" to add
@EnableAOP (on the lines of "configuration by exception").
4) Edited 8 files to add @EnableAOP at <deployment> level (i could have
added at a specific MC bean level in that file, but this was just for
testing).
5) Updated the jboss-aop-mc-int.jar in %JBOSS_HOME%/lib to use the
patched code
6) Booted the server. Here are the numbers with and without changes:
*Without* the AOPDependencyBuilder fix - consistently takes *23 seconds*:
20:30:10,457 INFO [AbstractServer] Started:
org.jboss.bootstrap.impl.as.server.JBossASServerImpl@12b7eea in 23s:177ms
*With* the AOPDependencyBuilder fix using @EnableAOP - consistently
takes around *21.5 seconds*
So 1.5 seconds improvement with changing around 10 files. 1.5 seconds
might not sound too big an improvement, but it definitely is an improvement.
So the real question is which is the sensible default -@DisableAOP
(which requires a lot of changes and everyone most of the time needs to
remember they have to disable this support) or is it @EnableAOP (which
makes more sense IMO).
regards,
-Jaikiran
Brian Stansberry wrote:
If not, that re-opens the discussion as to whether @DisableAOP should
be required, or should be default behavior with an @EnableAOP. Since
AFAICT the thing that made me thing enabling it was required for the
common case was @JMX.
Ales Justin wrote:
> I don't think we need AOPBD for this. Kabir?
>
> Hmmm, perhaps something like this should be on the @DisableAOP:
> @DisableAOP(allow={INSTANTIATE})
> which would mean we don't use AOPDB - since the aspect we expect with
> this bean don't have any dependencies,
> but we do want AOP proxy instantiation, since we *do* expect the bean
> to be aspectized.
>
> Jason T. Greene wrote:
>> Ok, so then, why do we need AOPDependencyBuilder to use @JMX? Yes I
>> know the dep builder allows for users to add aspects after the fact,
>> but this is a near *useless* feature, especially for our core
>> components.
>>
>> Brian Stansberry wrote:
>>> The registration of the @JMX handling is in the bootstrap, in
>>> bootstrap/jmx.xml.
>>>
>>> Jason T. Greene wrote:
>>>> Ales Justin wrote:
>>>>> (2) @org.jboss.aop.microcontainer.annotations.DisableAOP
>>>>>
>>>>> This one instructs MC to ignore transparent AOP usage when
>>>>> handling your bean.
>>>>> It will not look for aspect dependencies or try to create an AOP
>>>>> proxy.
>>>>> It will simply fall back to plain POJO handling.
>>>>>
>>>>> If you use @JMX or anything similar, this should then *not* be used.
>>>>> But for anything else it should be good to use it.
>>>>
>>>> Can we fix the @JMX (and other known cases) by deploying them
>>>> sooner, as part of the bootstrap for example?
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>>
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
3:08 p.m.
I'm still not convinced that @EnableAOP is the way to go.
The main problem is the boot, not the user code.
I would let the user have all the goodies by default,
and it's up to us to fix the boot properly.
The fix:
* use On_Demand where it makes sense
* analyze our services, add @MCAnnotations, @DisableAOP({DisableType.?})
* federated resources lookup
** usage of AnnotationEnvironment
** fix Metadata's paradigm
*** only asking for what it needs, not checking all against some constraints
** cache other resources, as we're doing the scanning anyway
** limit what we're scanning
*** jboss-scanning.xml
*** (X) jboss-classloading.xml
* usage of (X) will limit the class sharing/lookup == speed up
* profile service loading profiles on demand
** e.g. usage @MDR enterprise bean triggers JMS profile load
* parallel deployment
* xyz ...
Then it's up to the user to follow the pattern. ;-)
Jaikiran Pai wrote:
Just to see how much improvement this brings in to AS boot time and
how
much efforts it takes to use the @DisableAOP, i tried a few things on
5_x branch:
1) Since the AOPDependencyBuilder is meant for things like @JMX, i just
searched for the number of files that need this support. In the
"default" profile we have 10 files (ignore deployers.xml and jmx.xml for
now):
./server/default/deploy/remoting-jboss-beans.xml
./server/default/deploy/vfs-jboss-beans.xml
./server/default/deploy/jca-jboss-beans.xml
./server/default/deploy/jbossweb.sar/META-INF/jboss-beans.xml
./server/default/deploy/transaction-jboss-beans.xml
./server/default/deploy/messaging/messaging-jboss-beans.xml
./server/default/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml
./server/default/conf/bootstrap/deployers.xml
./server/default/conf/bootstrap/jmx.xml
./server/default/deployers/jsr77-deployers-jboss-beans.xml
The "all" profile has a few more (in clustering).
So out of all the MC beans that are being deployed (there are a lot)
there's only 10 files (and not all MC beans in this file might need @JMX
support) in the default profile for which the AOPDependencyBuilder
probably makes sense.
2) So the next obviously was to add @DisableAOP to rest of all the
-jboss-beans.xml which don't need the AOPDependencyBuilder. Obviously,
this is not easy since there are a lot. And as and when we start adding
new MC beans there's no guarantee that the developer even "remembers" to
add this @DisableAOP.
3) I decided to instead patch in a code to use a new annotation
@EnableAOP which could be used for beans which need the
AOPDependencyBuilderSupport. So i just have to edit 8 files in the
default profile. The other advantage of this approach is that when a
developer is trying to get the @JMX (or some similar) support working
and if he doesn't get it working then he sure will "remember" to add
@EnableAOP (on the lines of "configuration by exception").
4) Edited 8 files to add @EnableAOP at <deployment> level (i could have
added at a specific MC bean level in that file, but this was just for
testing).
5) Updated the jboss-aop-mc-int.jar in %JBOSS_HOME%/lib to use the
patched code
6) Booted the server. Here are the numbers with and without changes:
*Without* the AOPDependencyBuilder fix - consistently takes *23 seconds*:
20:30:10,457 INFO [AbstractServer] Started:
org.jboss.bootstrap.impl.as.server.JBossASServerImpl@12b7eea in 23s:177ms
*With* the AOPDependencyBuilder fix using @EnableAOP - consistently
takes around *21.5 seconds*
So 1.5 seconds improvement with changing around 10 files. 1.5 seconds
might not sound too big an improvement, but it definitely is an
improvement.
So the real question is which is the sensible default -@DisableAOP
(which requires a lot of changes and everyone most of the time needs to
remember they have to disable this support) or is it @EnableAOP (which
makes more sense IMO).
regards,
-Jaikiran
Brian Stansberry wrote:
> If not, that re-opens the discussion as to whether @DisableAOP should
> be required, or should be default behavior with an @EnableAOP. Since
> AFAICT the thing that made me thing enabling it was required for the
> common case was @JMX.
>
> Ales Justin wrote:
>> I don't think we need AOPBD for this. Kabir?
>>
>> Hmmm, perhaps something like this should be on the @DisableAOP:
>> @DisableAOP(allow={INSTANTIATE})
>> which would mean we don't use AOPDB - since the aspect we expect with
>> this bean don't have any dependencies,
>> but we do want AOP proxy instantiation, since we *do* expect the bean
>> to be aspectized.
>>
>> Jason T. Greene wrote:
>>> Ok, so then, why do we need AOPDependencyBuilder to use @JMX? Yes I
>>> know the dep builder allows for users to add aspects after the fact,
>>> but this is a near *useless* feature, especially for our core
>>> components.
>>>
>>> Brian Stansberry wrote:
>>>> The registration of the @JMX handling is in the bootstrap, in
>>>> bootstrap/jmx.xml.
>>>>
>>>> Jason T. Greene wrote:
>>>>> Ales Justin wrote:
>>>>>> (2) @org.jboss.aop.microcontainer.annotations.DisableAOP
>>>>>>
>>>>>> This one instructs MC to ignore transparent AOP usage when
>>>>>> handling your bean.
>>>>>> It will not look for aspect dependencies or try to create an AOP
>>>>>> proxy.
>>>>>> It will simply fall back to plain POJO handling.
>>>>>>
>>>>>> If you use @JMX or anything similar, this should then *not* be
used.
>>>>>> But for anything else it should be good to use it.
>>>>>
>>>>> Can we fix the @JMX (and other known cases) by deploying them
>>>>> sooner, as part of the bootstrap for example?
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>
>>>>
>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
4:22 a.m.
My comment is a bit irrelevant with the technical part of the discussion, but here goes
anyway:
Suppose our user is the average Joe developer. What makes more sense to him? Have a faster
boot time or more features enabled, by default? What setup would be desirable for the 80%
of
use cases?
And when a special configuration is needed, how easy is to find out about it and put it to
use. Is it well documented, is it simple enough?
My feeling is we usually opt for the most complex (possibly powerful) solution, introduce
new config files, etc, while our motto should be keep it simple, stupid (and intuitive).
My 0.2c
/D
Ales Justin wrote:
I'm still not convinced that @EnableAOP is the way to go.
The main problem is the boot, not the user code.
I would let the user have all the goodies by default,
and it's up to us to fix the boot properly.
The fix:
* use On_Demand where it makes sense
* analyze our services, add @MCAnnotations, @DisableAOP({DisableType.?})
* federated resources lookup
** usage of AnnotationEnvironment
** fix Metadata's paradigm
*** only asking for what it needs, not checking all against some
constraints
** cache other resources, as we're doing the scanning anyway
** limit what we're scanning
*** jboss-scanning.xml
*** (X) jboss-classloading.xml
* usage of (X) will limit the class sharing/lookup == speed up
* profile service loading profiles on demand
** e.g. usage @MDR enterprise bean triggers JMS profile load
* parallel deployment
* xyz ...
Then it's up to the user to follow the pattern. ;-)
Jaikiran Pai wrote:
> Just to see how much improvement this brings in to AS boot time and
> how much efforts it takes to use the @DisableAOP, i tried a few things
> on 5_x branch:
>
> 1) Since the AOPDependencyBuilder is meant for things like @JMX, i
> just searched for the number of files that need this support. In the
> "default" profile we have 10 files (ignore deployers.xml and jmx.xml
> for now):
>
> ./server/default/deploy/remoting-jboss-beans.xml
> ./server/default/deploy/vfs-jboss-beans.xml
> ./server/default/deploy/jca-jboss-beans.xml
> ./server/default/deploy/jbossweb.sar/META-INF/jboss-beans.xml
> ./server/default/deploy/transaction-jboss-beans.xml
> ./server/default/deploy/messaging/messaging-jboss-beans.xml
> ./server/default/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml
>
> ./server/default/conf/bootstrap/deployers.xml
> ./server/default/conf/bootstrap/jmx.xml
> ./server/default/deployers/jsr77-deployers-jboss-beans.xml
>
>
> The "all" profile has a few more (in clustering).
>
> So out of all the MC beans that are being deployed (there are a lot)
> there's only 10 files (and not all MC beans in this file might need
> @JMX support) in the default profile for which the
> AOPDependencyBuilder probably makes sense.
>
> 2) So the next obviously was to add @DisableAOP to rest of all the
> -jboss-beans.xml which don't need the AOPDependencyBuilder. Obviously,
> this is not easy since there are a lot. And as and when we start
> adding new MC beans there's no guarantee that the developer even
> "remembers" to add this @DisableAOP.
>
> 3) I decided to instead patch in a code to use a new annotation
> @EnableAOP which could be used for beans which need the
> AOPDependencyBuilderSupport. So i just have to edit 8 files in the
> default profile. The other advantage of this approach is that when a
> developer is trying to get the @JMX (or some similar) support working
> and if he doesn't get it working then he sure will "remember" to add
> @EnableAOP (on the lines of "configuration by exception").
>
> 4) Edited 8 files to add @EnableAOP at <deployment> level (i could
> have added at a specific MC bean level in that file, but this was just
> for testing).
>
> 5) Updated the jboss-aop-mc-int.jar in %JBOSS_HOME%/lib to use the
> patched code
>
> 6) Booted the server. Here are the numbers with and without changes:
>
> *Without* the AOPDependencyBuilder fix - consistently takes *23 seconds*:
>
> 20:30:10,457 INFO [AbstractServer] Started:
> org.jboss.bootstrap.impl.as.server.JBossASServerImpl@12b7eea in 23s:177ms
>
> *With* the AOPDependencyBuilder fix using @EnableAOP - consistently
> takes around *21.5 seconds*
>
> So 1.5 seconds improvement with changing around 10 files. 1.5 seconds
> might not sound too big an improvement, but it definitely is an
> improvement.
>
> So the real question is which is the sensible default -@DisableAOP
> (which requires a lot of changes and everyone most of the time needs
> to remember they have to disable this support) or is it @EnableAOP
> (which makes more sense IMO).
>
> regards,
> -Jaikiran
>
>
>
> Brian Stansberry wrote:
>> If not, that re-opens the discussion as to whether @DisableAOP should
>> be required, or should be default behavior with an @EnableAOP. Since
>> AFAICT the thing that made me thing enabling it was required for the
>> common case was @JMX.
>>
>> Ales Justin wrote:
>>> I don't think we need AOPBD for this. Kabir?
>>>
>>> Hmmm, perhaps something like this should be on the @DisableAOP:
>>> @DisableAOP(allow={INSTANTIATE})
>>> which would mean we don't use AOPDB - since the aspect we expect
>>> with this bean don't have any dependencies,
>>> but we do want AOP proxy instantiation, since we *do* expect the
>>> bean to be aspectized.
>>>
>>> Jason T. Greene wrote:
>>>> Ok, so then, why do we need AOPDependencyBuilder to use @JMX? Yes I
>>>> know the dep builder allows for users to add aspects after the
>>>> fact, but this is a near *useless* feature, especially for our core
>>>> components.
>>>>
>>>> Brian Stansberry wrote:
>>>>> The registration of the @JMX handling is in the bootstrap, in
>>>>> bootstrap/jmx.xml.
>>>>>
>>>>> Jason T. Greene wrote:
>>>>>> Ales Justin wrote:
>>>>>>> (2) @org.jboss.aop.microcontainer.annotations.DisableAOP
>>>>>>>
>>>>>>> This one instructs MC to ignore transparent AOP usage when
>>>>>>> handling your bean.
>>>>>>> It will not look for aspect dependencies or try to create an
AOP
>>>>>>> proxy.
>>>>>>> It will simply fall back to plain POJO handling.
>>>>>>>
>>>>>>> If you use @JMX or anything similar, this should then *not*
be
>>>>>>> used.
>>>>>>> But for anything else it should be good to use it.
>>>>>>
>>>>>> Can we fix the @JMX (and other known cases) by deploying them
>>>>>> sooner, as part of the bootstrap for example?
>>>>>> _______________________________________________
>>>>>> jboss-development mailing list
>>>>>> jboss-development(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
8:09 a.m.
How about giving freedom of choice to the user? @EnableAOP would always
enable AOP and @DisableAOP would always disable AOP. The default could
be specified by the project using MC (via configuration). Beans that
require AOP, can specify @EnableAOP. Customers that want AOP enabled by
default, can change a configuration setting to accomplish that. Some
projects will always default to having AOP enabled and maybe some will
default to AOP disabled.
Ales Justin wrote:
I'm still not convinced that @EnableAOP is the way to go.
The main problem is the boot, not the user code.
I would let the user have all the goodies by default,
and it's up to us to fix the boot properly.
The fix:
* use On_Demand where it makes sense
* analyze our services, add @MCAnnotations, @DisableAOP({DisableType.?})
* federated resources lookup
** usage of AnnotationEnvironment
** fix Metadata's paradigm
*** only asking for what it needs, not checking all against some
constraints
** cache other resources, as we're doing the scanning anyway
** limit what we're scanning
*** jboss-scanning.xml
*** (X) jboss-classloading.xml
* usage of (X) will limit the class sharing/lookup == speed up
* profile service loading profiles on demand
** e.g. usage @MDR enterprise bean triggers JMS profile load
* parallel deployment
* xyz ...
Then it's up to the user to follow the pattern. ;-)
Jaikiran Pai wrote:
> Just to see how much improvement this brings in to AS boot time and
> how much efforts it takes to use the @DisableAOP, i tried a few
> things on 5_x branch:
>
> 1) Since the AOPDependencyBuilder is meant for things like @JMX, i
> just searched for the number of files that need this support. In the
> "default" profile we have 10 files (ignore deployers.xml and jmx.xml
> for now):
>
> ./server/default/deploy/remoting-jboss-beans.xml
> ./server/default/deploy/vfs-jboss-beans.xml
> ./server/default/deploy/jca-jboss-beans.xml
> ./server/default/deploy/jbossweb.sar/META-INF/jboss-beans.xml
> ./server/default/deploy/transaction-jboss-beans.xml
> ./server/default/deploy/messaging/messaging-jboss-beans.xml
> ./server/default/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml
>
> ./server/default/conf/bootstrap/deployers.xml
> ./server/default/conf/bootstrap/jmx.xml
> ./server/default/deployers/jsr77-deployers-jboss-beans.xml
>
>
> The "all" profile has a few more (in clustering).
>
> So out of all the MC beans that are being deployed (there are a lot)
> there's only 10 files (and not all MC beans in this file might need
> @JMX support) in the default profile for which the
> AOPDependencyBuilder probably makes sense.
>
> 2) So the next obviously was to add @DisableAOP to rest of all the
> -jboss-beans.xml which don't need the AOPDependencyBuilder.
> Obviously, this is not easy since there are a lot. And as and when we
> start adding new MC beans there's no guarantee that the developer
> even "remembers" to add this @DisableAOP.
>
> 3) I decided to instead patch in a code to use a new annotation
> @EnableAOP which could be used for beans which need the
> AOPDependencyBuilderSupport. So i just have to edit 8 files in the
> default profile. The other advantage of this approach is that when a
> developer is trying to get the @JMX (or some similar) support working
> and if he doesn't get it working then he sure will "remember" to add
> @EnableAOP (on the lines of "configuration by exception").
>
> 4) Edited 8 files to add @EnableAOP at <deployment> level (i could
> have added at a specific MC bean level in that file, but this was
> just for testing).
>
> 5) Updated the jboss-aop-mc-int.jar in %JBOSS_HOME%/lib to use the
> patched code
>
> 6) Booted the server. Here are the numbers with and without changes:
>
> *Without* the AOPDependencyBuilder fix - consistently takes *23
> seconds*:
>
> 20:30:10,457 INFO [AbstractServer] Started:
> org.jboss.bootstrap.impl.as.server.JBossASServerImpl@12b7eea in
> 23s:177ms
>
> *With* the AOPDependencyBuilder fix using @EnableAOP - consistently
> takes around *21.5 seconds*
>
> So 1.5 seconds improvement with changing around 10 files. 1.5 seconds
> might not sound too big an improvement, but it definitely is an
> improvement.
>
> So the real question is which is the sensible default -@DisableAOP
> (which requires a lot of changes and everyone most of the time needs
> to remember they have to disable this support) or is it @EnableAOP
> (which makes more sense IMO).
>
> regards,
> -Jaikiran
>
>
>
> Brian Stansberry wrote:
>> If not, that re-opens the discussion as to whether @DisableAOP
>> should be required, or should be default behavior with an
>> @EnableAOP. Since AFAICT the thing that made me thing enabling it
>> was required for the common case was @JMX.
>>
>> Ales Justin wrote:
>>> I don't think we need AOPBD for this. Kabir?
>>>
>>> Hmmm, perhaps something like this should be on the @DisableAOP:
>>> @DisableAOP(allow={INSTANTIATE})
>>> which would mean we don't use AOPDB - since the aspect we expect
>>> with this bean don't have any dependencies,
>>> but we do want AOP proxy instantiation, since we *do* expect the
>>> bean to be aspectized.
>>>
>>> Jason T. Greene wrote:
>>>> Ok, so then, why do we need AOPDependencyBuilder to use @JMX? Yes
>>>> I know the dep builder allows for users to add aspects after the
>>>> fact, but this is a near *useless* feature, especially for our
>>>> core components.
>>>>
>>>> Brian Stansberry wrote:
>>>>> The registration of the @JMX handling is in the bootstrap, in
>>>>> bootstrap/jmx.xml.
>>>>>
>>>>> Jason T. Greene wrote:
>>>>>> Ales Justin wrote:
>>>>>>> (2) @org.jboss.aop.microcontainer.annotations.DisableAOP
>>>>>>>
>>>>>>> This one instructs MC to ignore transparent AOP usage when
>>>>>>> handling your bean.
>>>>>>> It will not look for aspect dependencies or try to create an
>>>>>>> AOP proxy.
>>>>>>> It will simply fall back to plain POJO handling.
>>>>>>>
>>>>>>> If you use @JMX or anything similar, this should then *not*
be
>>>>>>> used.
>>>>>>> But for anything else it should be good to use it.
>>>>>>
>>>>>> Can we fix the @JMX (and other known cases) by deploying them
>>>>>> sooner, as part of the bootstrap for example?
>>>>>> _______________________________________________
>>>>>> jboss-development mailing list
>>>>>> jboss-development(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
10:26 a.m.
Ales Justin wrote:
(2) @org.jboss.aop.microcontainer.annotations.DisableAOP
This one instructs MC to ignore transparent AOP usage when handling
your bean.
It will not look for aspect dependencies or try to create an AOP proxy.
It will simply fall back to plain POJO handling.
If you use @JMX or anything similar, this should then *not* be used.
But for anything else it should be good to use it.
How to use this?
(a) either annotate your service/bean classes
(b) simply use xml way of annotating your beans
e.g.
<annotation>(a)org.jboss.beans.metadata.api.annotations.MCAnnotations({org.jboss.beans.metadata.api.annotations.Inject.class})</annotation>
<annotation>(a)org.jboss.aop.microcontainer.annotations.DisableAOP</annotation>
(c) if you know that none of your beans in <deployment> (-beans.xml
file) uses any of the needed features,
you can simply add xml way to the <deployment> element.
This way all beans inherit the annotation from deployment.
Although there wasn't a general consensus on the @DisableAOP, i guess
this is what we are going with now. So if there's no objections to
this, i will be adding this annotation (both programmatic and through
xml) in EJB3 MC deployments https://jira.jboss.org/jira/browse/EJBTHREE-1854
regards,
-Jaikiran
5659
days inactive
5706
days old
jboss-development@lists.jboss.org
32 comments
9 participants
participants (9)
-
Ales Justin -
Brian Stansberry -
David M. Lloyd -
Dimitris Andreadis -
Jaikiran Pai -
Jason T. Greene -
Kabir Khan -
Scott Marlow -
Scott Stark