[jboss-dev] jbossas -beans.xml opt

[Ales Justin]

> 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-same-time/)

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>@org.jboss.beans.metadata.api.annotations.MCAnnotations({org.jboss.beans.metadata.api.annotations.Inject.class})</annotation> 
>>>>
>>>> <annotation>@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 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
> 
>