On Nov 2, 2011, at 2:26 AM, Adam Bien wrote:
> @Metatype is very similar to @Stereotype - isn't it?
Very, though more generic and not restricted to annotations that can be applied to other annotations.
So for example, @Stereotype as it is currently defined is not compatible with say @Schedule. One or the other would have to change; either @Schedule would have to change so it can target ANNOTATION_TYPE, or the design of @Schedule would have to change to facilitate annotations that haven't been "prepared" for @Stereotype usage.
I'm still not sure how best to properly propose it and where. Seems it would be more of a Java SE thing, but maybe not. Definitely the concept needs more documentation before it can go anywhere, so I've been trying to do that.
-David
> On 01.10.2011, at 08:35, David Blevins wrote:
>
>>
>> On Sep 30, 2011, at 9:16 PM, Marina Vatkina wrote:
>>
>>> Yes, let's discuss this after J1.
>>>
>>> Do we want to look at moving contexts that can be useful in other components to some common location? (I know, we are still trying to figure out where that common location will be and how it will be organized...)
>>
>> I suppose it depends in if we want to bury the "javax.ejb" package.
>>
>> I have to admit, I'm a little bit looking forward to people's reactions when the see "@javax.ejb.Schedule" or "@javax.ejb.Asynchronous" on a Servlet. Sort of like, hey developer how badly do you want to hate "ejb" :) Bad enough that you aren't going to use it? Really hard to turn down good functionality that's just one little teeny tiny annotation away and you still get to call your component a Servlet.
>>
>> That said, if we wanted to go away from it, we can, it's just not as fun :)
>>
>>> (It's unfortunate that annotations do not support inheritance...).
>>
>> Presenting something along these lines on Monday at JavaOne. The "EJB with Meta-Annotations" talk. An experimental idea that allows you to basically rewrap the standard annotations and have them still mean the same thing, just named and grouped as you like.
>>
>> So instead of using @java.ejb.AccessTimeout you can use something like this:
>>
>> import javax.ejb.AccessTimeout;
>> import java.lang.annotation.ElementType;
>> import java.lang.annotation.Retention;
>> import java.lang.annotation.RetentionPolicy;
>> import java.lang.annotation.Target;
>>
>> @Metatype
>> @Retention(RetentionPolicy.RUNTIME)
>> @Target(ElementType.METHOD)
>>
>> @AccessTimeout(-1)
>> public @interface AwaitForever {
>> }
>>
>> As well as make them simply easier to type:
>>
>> @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
>> @Metatype
>> @Target({ElementType.METHOD, ElementType.TYPE})
>> @Retention(RetentionPolicy.RUNTIME)
>> public static @interface TxRequiresNew {
>> }
>>
>>
>> Or perhaps to make them a little more honest:
>>
>> @TransactionAttribute(TransactionAttributeType.REQUIRED)
>> @Metatype
>> @Target({ElementType.METHOD, ElementType.TYPE})
>> @Retention(RetentionPolicy.RUNTIME)
>> public static @interface LazilyIntitializedTransaction {
>> }
>>
>>
>> Users could essentially redesign 100% of our annotations to their liking. So rather than make a complete mess out of our own packages by duplicating things or splitting them oddly, we let user's do it.
>>
>> I proposed something along these lines in EJB 3.1 but it was a bit late to really consider.
>>
>>
>> -David
>>
>
>