Agreed, naming a package annotation is not that useful ;-)
On 8 Oct 2011, at 18:04, David Blevins wrote:
> I wish we had never allowed any "annotation" packages to be created. It seemed like a good idea at the time, but its leading us into incredibly limited and awkward choices.
>
> Say we did split out a "SecurityContext" interface to house the "getCallerPrincipal()" and "isCallerInRole(String)" methods. Are we supposed to stick with convention and make:
>
> - javax.interface.security.SecurityContext
>
> Throw in the related exceptions we have and it gets even more awkward (i.e. javax.exception.security.AccessException?)
>
> Tough nut to crack.
>
>
> -David
>
> On Oct 8, 2011, at 1:45 PM, Antonio Goncalves wrote:
>
>> I would like to have common location for this kind of services. We have javax.annotation, javax.enterprise so what about mixing both and having such common services into javax.enterprise.annotation (or javax.annotation.enterprise). Ot, it might seem a bit extreme, but why not having them simply into javax.annotation ? We already have ManagedBean, PostConstruct, PreDestroy, Resource ? Or under a different package like DenyAll, PermitAll, RolesAllowed, RunAs under javax.annotation.security ?
>>
>> My 2 cents
>>
>> Antonio
>>
>> On Sat, Oct 1, 2011 at 08:35, David Blevins <david.blevins_at_gmail.com> 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
>>
>>
>>
>>
>> --
>> Antonio Goncalves
>> Software architect and Java Champion
>>
>> Web site | Twitter | Blog | LinkedIn | Paris JUG
>