[jboss-dev] jbossas -beans.xml opt

Thu May 28 16:08:37 EDT 2009

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
> 