users@ejb-spec.java.net

[ejb-spec users] [jsr345-experts] Re: Meta-Annotations

From: Reza Rahman <reza_rahman_at_lycos.com>
Date: Thu, 09 Feb 2012 21:52:25 -0500

Responses in-line...

On 2/9/2012 9:19 PM, Marina Vatkina wrote:
> Experts,
>
> If you are confused about the options to vote on, here are the options
> (though I was interested if you support the ideas in this thread in
> general):
>
> A1: Should EJB annotations (all or some) be allowed to be used as CDI
> Stereotypes?
Yes. You meant "in CDI Stereotypes", right?
> A2: Should EJB annotations (all or some) be marked as meta-annotations
> and be allowed to be used to construct other annotations, even if CDI
> is not enabled?
No. Don't see the point really. It would basically duplicate what CDI
stereotypes are intended for. If we feel CDI stereotypes have
shortcomings, let's focus on getting those shortcomings addressed?
>
> If you vote "yes" on either item above,
>
> B1: Can all EJB annotations be used as meta annotations?
> B2: Should component-defining annotations be excluded from the list of
> annotations that can be used as meta annotation?
> B3: Should any other (which ones) annotations be excluded?
> or
> B4: Which EJB annotations should be allowed to be used as meta
> annotation?
If you meant using EJB annotations in CDI stereotypes, I would say all
but @AfterBegin, @AfterCompletion, @BeforeCompletion, @EJB, @EJBs,
@Init, @PostActivate, @PrePassivate and @Remove.
>
> thanks,
> -marina
>
> Marina Vatkina wrote:
>> Experts,
>>
>> Please vote. When you do, please add to your vote, if you think some
>> annotations should be excluded (like component-defining ones -
>> @Stateless etc.).
>>
>> thanks,
>> -marina
>>
>>
>> Pete Muir wrote:
>>> It seems to me there are two action items here:
>>>
>>> 1) Allow EJB annotations to be used as meta annotations when CDI is
>>> turned on. I think this needs to be in the EJB spec, or EJB needs to
>>> define an extension point for this or something. Marina?
>>> 2) Take the general idea to the platform spec. I guess this is for
>>> David?
>>>
>>> On 8 Feb 2012, at 05:46, David Blevins wrote:
>>>
>>>
>>>> On Feb 7, 2012, at 6:40 AM, Pete Muir wrote:
>>>>
>>>>> On 7 Feb 2012, at 02:09, Marina Vatkina wrote:
>>>>>
>>>>>> Returning back to it...
>>>>>>
>>>>>>
>>>>>> Pete Muir wrote:
>>>>>>> On 16 Dec 2011, at 07:41, Marina Vatkina wrote:
>>>>>>>
>>>>>>>
>>>>>>>> I think we need to sort this all out very slowly...
>>>>>>>>
>>>>>>>> Pete Muir wrote:
>>>>>>>>
>>>>>>>>> Possibly I misunderstood you. I meant we would need to specify
>>>>>>>>> that
>>>>>>>>> the annotations to which we add the ANNOTATION_TYPE target
>>>>>>>>> would need
>>>>>>>>> to be specified as usable as meta-annotations,
>>>>>>>>>
>>>>>>>> Isn't an annotation with an ANNOTATION_TYPE target type, a
>>>>>>>> meta-annotation by default? In David's example @Metatype seems
>>>>>>>> to be a marker for the derived annotations (for easier
>>>>>>>> processing?)
>>>>>>>>
>>>>>>> It is, but I think the spec needs to say what annotations can be
>>>>>>> used like this,
>>>>>> Do you mean not only add ANNOTATION_TYPE target, but spell them
>>>>>> out explicitly in the spec?
>>>>> You could say "any annotation which has ANNOTATION_TYPE as a
>>>>> target is a metaannotation" in the spec, but I think the spec
>>>>> needs *some* mention...
>>>> Agreed.
>>>>
>>>>>>> and also require implementations to process this.
>>>>>>>
>>>>>> Do you suggest this feature to be available outside CDI?
>>>>>>
>>>>>> If not, how will the derived annotations be different from the
>>>>>> CDI @Stereotype?
>>>>> I assumed the proposal was for pure EJB.
>>>>>
>>>>> Alternatively, it could be that we simply say that any EJB
>>>>> annotation is allowed on a CDI stereotype.
>>>> Getting change at the EJB-level to support CDI @Stereotype and some
>>>> potential platform-level identical concept would be a great step
>>>> forward. So big +1 from me on that. I had proposed it in EJB 3.1
>>>> and we took a wait-and-see approach to it which was smart. Now is
>>>> a good time to add that.
>>>>
>>>> Beyond that, the conversation likely needs to be moved to the
>>>> platform level or perhaps SE level. There is definitely an obvious
>>>> need for more generic annotation reuse that really has no need to
>>>> be tied to CDI or BeanValidation (or EJB or any other spec tempted
>>>> to introduce reuse concepts). Both those specs have their own,
>>>> nearly identical, but subtly different concepts of annotation
>>>> reuse/inheritance.
>>>>
>>>> In BeanValidation world (implicit approach):
>>>>
>>>> @Pattern(regexp="[0-9]*")
>>>> @Size(min=5, max=5)
>>>> @Constraint(validatedBy = FrenchZipcodeValidator.class)
>>>> @Documented
>>>> @Target({ANNOTATION_TYPE, METHOD, FIELD, CONSTRUCTOR, PARAMETER})
>>>> @Retention(RUNTIME)
>>>> public @interface FrenchZipcode {
>>>> //...
>>>> }
>>>>
>>>> In CDI world that would look like so (explicit approach -- feature
>>>> turned on via @Stereotype):
>>>>
>>>>
>>>> @Pattern(regexp="[0-9]*")
>>>> @Size(min=5, max=5)
>>>> @Stereotype
>>>> @Documented
>>>> @Target({ANNOTATION_TYPE, METHOD, FIELD, CONSTRUCTOR, PARAMETER})
>>>> @Retention(RUNTIME)
>>>> public @interface FrenchZipcode {
>>>> //...
>>>> }
>>>>
>>>> (here I'm just being lazy and don't want to create an entirely
>>>> different set of pretend annotations -- You get the idea :)
>>>
>>> I think if we went this route we could always make @Stereotype
>>> optional in CDI. I don't think this would break backwards compat. I
>>> would want to check with the OpenWebBeans team as to whether this
>>> would affect their performance, but I don't think it's that great a
>>> change from experience with Weld.
>>>
>>>
>>>> Both specs acknowledge the very practical need for annotation
>>>> reuse, unfortunately in a spec-specific way that does not allow for
>>>> reuse to happen between specifications.
>>>>
>>>> Going straight into pretend-land with the following examples :)
>>>>
>>>> Say you have a JAX-RS service:
>>>>
>>>> @GET
>>>> public Person getPerson(@QueryParam("id") String id) {...}
>>>>
>>>> Why not allow this:
>>>>
>>>> @QueryParam("id")
>>>> @TheStandardAndGenericPleaseReuseMyAnnotationsAnnotation
>>>> @Target({PARAMETER})
>>>> @Retention(RUNTIME)
>>>> public @interface Id {
>>>> }
>>>>
>>>> @GET
>>>> public Person getPerson(@Id String id) {...}
>>>>
>>>> And now with some imaginary mixing in of Bean Validation
>>>>
>>>> @Pattern(regexp="[0-9]*")
>>>> @Size(min=5, max=5)
>>>> @QueryParam("id")
>>>> @TheStandardAndGenericPleaseReuseMyAnnotationsAnnotation
>>>> @Target({PARAMETER})
>>>> @Retention(RUNTIME)
>>>> public @interface Id {
>>>> }
>>>>
>>>> Now we've just mixed JAX-RS and Bean Validation on one, reusable,
>>>> annotation.
>>>>
>>>> At best, reusing annotations like this is a design pattern. I
>>>> think we as an industry have learned its simple and powerful value
>>>> and should make steps to adopt it fully.
>>>>
>>>> If it could be slotted in at the SE level under the reflection API,
>>>> you'd not need spec cooperation to have it "enabled". The little
>>>> library I wrote attempts to hide all the plumbing behind
>>>> java.lang.reflect.AnnotatedElement, toying with the concept that
>>>> such a thing could potentially be done.
>>>>
>>>> Short of that, we'd definitely need some platform level of
>>>> cooperation to say "this is possible" and then further cooperation
>>>> from each sub-spec to explicitly list the annotations that can be
>>>> reused in such a fashion.
>>>>
>>>> Either of these two outcomes would be really great.
>>>>
>>>> At this, I'm curious who likes the general idea of more generic
>>>> annotation reuse. Timing and api details aside, it seems like an
>>>> important goal.
>>>>
>>>> I brought it up here as 1) there are definitely EJB
>>>> implications/possibilities and any conversations at platform level
>>>> would be pretty weak without general interest at least here, and 2)
>>>> I figured we could have fun poking at the idea for a while before
>>>> raising it at higher levels :)
>>>>
>>>> The idea has already been tweaked as a result of discussion which
>>>> is pretty cool....
>>>>
>>>>
>>>> -David
>>>>
>>>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1913 / Virus Database: 2112/4799 - Release Date: 02/09/12
>
>