Reza Rahman wrote:
> 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?
Right. Thanks for catching.
>> 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
>>
>>
>