On 02/10/2012 03:19 AM, 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.
> 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?
I don't see how we can exclude this option if A1 is enabled. We are only
saying that EJB won't mandate a meta-annotation processing facility. A
vendor is still free to provide one, not?
(Personally I think meta-annotation processing should transcend CDI &
EJB, but that would be opening Pandora's box... ehr... oops. ;-) )
>
> If you vote "yes" on either item above,
>
> B1: Can all EJB annotations be used as meta annotations?
Yes. While some annotations are logically not really usable as such. I
don't think we should dive too deep into figuring out the options.
To provide some examples from Reza's list:
@Stereotype
@Remove(retainIfException=true)
public @interface Dismiss
@Stereotype
@PostActivate
@PostConstruct
public @interface Alive
Carlo
> 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
>>>>
>>>