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
>>
>>
>
>