[jboss-dev] jbossas -beans.xml opt

Fri May 29 05:22:04 EDT 2009

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 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