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