On Dec 15, 2011, at 4:25 AM, Carlo de Wolf wrote:
> I would say only @Metatype, because the various options it opens up are unlimited! :-)
>
> Maybe let it ride the waves for a while and do an EJB 3.2 bonus pack after EE 7 with some common extensions.
>
> The one thing I don't get is why @Metatype is a meta annotation in itself. If it where I would expect it to be present when I query the annotations. Given that it is a chicken/egg annotation, I did some fiddling to come up with: https://github.com/dblevins/metatypes/pull/1/files#L9R38 vs https://github.com/dblevins/metatypes/pull/1/files#L3R147.
Pulled in that request, thank you!
The "annotate @Metatype with @Metatype" is likely not worth explaining. I presented this at JavaOne and didn't want to make-up 'javax.annotation.Metatype' class and mislead anyone. So that "must be called Metatype and must be annotated with itself" rule felt like a nice and conservative and low risk way to allow people to create their own @Metatype without any reasonable chance of conflict with any pre-existing "Metatype" annotations.
For standardization purposes, we would want a standard annotation and wouldn't need that business. I've gone ahead and update the github project so it uses a @javax.annotation.Metatype annotation.
-David
> On 12/15/2011 03:51 AM, Marina Vatkina wrote:
>> Do you mean various synonims or the @Metatype?
>>
>> Pete Muir wrote:
>>> Surely to give users that option in a portable fashion, we need to spec it?
>>>
>>> On 14 Dec 2011, at 04:37, Marina Vatkina wrote:
>>>
>>>> We can add ANNOTATION_TYPE (to all or to a subset of annotations). I think we shouldn't spec such meta-annotations, but rather give users an option to add annotations if they like it that way.
>>>>
>>>> But the "simplified" @Schedule versions can be confusing though, e.g. @Daily or @Yearly will need more details, like time of the day or day of the year, in which case they wont be shorter than the original - @Schedule() is daily at midnight, and @Schedule(dayOfMonth="1", month="1") is yearly on Jan 1st...
>>>>
>>>> My $.02. What do others think?
>>>>
>>>> Best,
>>>> -marina
>>>>
>>>> David Blevins wrote:
>>>>> I think this is too big for this spec round, but here is the idea in more clear terms.
>>>>>
>>>>> Yes, it is very much like CDI stereotypes. It's also very much like Bean Validation's ability to reuse annotations. It's also like CDI @InterceptorBinding and @Qualifier which also have "meta" effects associated with them -- i.e. annotations that use them effectively become @InterceptorBindings and @Qualifiers.
>>>>>
>>>>> We're doing this all over the place really. It's not entirely CDI or Bean Validation specific. It's not EJB specific either, so let's try not to look at it and get distracted with the whole align EJB and CDI initiative.
>>>>>
>>>>> The twist here is that you can "reuse" annotations which aren't designed to be applicable to @Target(ANNOTATION_TYPE). The syntax for it is IMO ugly but effective. If we don't want that twist, we can easily go simpler.
>>>>>
>>>>> This is really a design pattern and not specification specific. If there is an idea of specification, it would be a Java SE -- it would be quite handy to be able inherit annotations in this fashion at a language level and not need the cooperation of specific apis.
>>>>>
>>>>> For our purposes, we could just as easily decide to add ANNOTATION_TYPE to all our current annotations and make a simple rule that "annotations with the ANNOTATION_TYPE can be used as meta-annotations" and just leave it at that.
>>>>>
>>>>> Without something like "@Metatype" that model doesn't become recursive, but maybe that's good enough. The "@Metatype" concept is a simple statement of "carry these annotations forward". A simple and explicit statement of how far you want the recursion to go.
>>>>>
>>>>> So here is an exploration of how meta-annotations (annotation reuse) could be applied to EJB:
>>>>>
>>>>> https://github.com/dblevins/metatypes/tree/master/metatype-ejb/src/main/java/javax/ejb/meta
>>>>>
>>>>> The above is a list of "built-in" meta-annotations we might consider delivering out of the box. I've put them in a theoretical "javax.ejb.meta" package to make it clear that all the annotations there are simply repackaged versions of the actual annotations.
>>>>>
>>>>> Plummed this into a patched version of CXF's JAX-RS support and it's proving to be quite fun there as well:
>>>>>
>>>>> @GET
>>>>> @Path("/customers/{id}/")
>>>>> public Customer getCustomer(@Id String id) {
>>>>> }
>>>>>
>>>>> The applicability to other specs is that part that gives me most pause. It certainly belies the need for a more generic form of annotation reuse that isn't specific to a domain like EJB, CDI, Bean Validation, etc. We keep creating domain-specific annotations to drive this form of recursion or reuse and really we just need one for the whole language.
>>>>>
>>>>> It's interesting and fun, but perhaps too young for inclusion. Or not.
>>>>>
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>
>