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