[jboss-dev] jbossas -beans.xml opt

Thu Jun 4 09:09:23 EDT 2009

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 at 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 - at 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 at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>>
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development