Re: [sca-j] JAVA-129: Proposed resolution

[Simon Nash <oasis@cjnash.com>]

I am attaching an updated proposal to resolve this issue.  This takes
into account our directional resolutions for JAVA-98:
   1. to not follow the JSR 250 guideline about method annotations
      cancelling the effect of class-level annotations of the same type.
   2. to not use @Inherited for intent annotations.

   Simon

David Booz wrote:
> Thanks for the table, it's very illustrative. This is one reason why I 
> think working with examples is helpful. Can I go on record now 
> expressing strong dislike of the JSR250 rules?
> 
> While the example is contrived and artificial to illustrate the effects 
> of JSR250 works, it none-the-less shows the complexities. One aspect in 
> particular that really jumps out is the effect of a method level 
> annotation on other methods, producing side effects that will be easily 
> overlooked.
> 
> Let's look at the helloThere method. Suppose the helloThere method was 
> added to the HelloChildService and the implementation simply delegated 
> to the super class. The table shows that there is a significant 
> difference between helloThere as it exists in the HelloService and this 
> new helloThere which is essentially the same service method! The changes 
> occur simply due to collocation of the new helloThere method with other 
> methods in HelloChildService. Ouch!
> 
> I'm now strongly reconsidering whether we should support any annotation 
> inheritance.
> 
> 
> 
> Dave Booz
> STSM, BPM and SCA Architecture
> Co-Chair OASIS SCA-Policy TC and SCA-J TC
> "Distributed objects first, then world hunger"
> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> e-mail:booz@us.ibm.com
> 
> Inactive hide details for Simon Nash ---03/17/2009 05:49:14 AM---After 
> considering various approaches to fixing the listing in Simon Nash 
> ---03/17/2009 05:49:14 AM---After considering various approaches to 
> fixing the listing in example 2b, I decided that replacing i
> 
> 
> From:	
> Simon Nash <oasis@cjnash.com>
> 
> To:	
> OASIS Java <sca-j@lists.oasis-open.org>
> 
> Date:	
> 03/17/2009 05:49 AM
> 
> Subject:	
> [sca-j] JAVA-129: Proposed resolution
> 
> ------------------------------------------------------------------------
> 
> 
> 
> After considering various approaches to fixing the listing
> in example 2b, I decided that replacing it by a table would be
> the simplest way to present this information.
> 
> While going through the effective annotations for the methods
> shown in the example, I realised that some of them are not
> correct according to the JSR-250 rules.  The problems relate to
> the (somewhat counterintuitive) JSR-250 rule that method-level
> annotations have the effect of removing class-level annotations
> of the same type from all methods of the class.
> 
> The attached proposal corrects this and points out the places
> where this rule changes the effective annotation.
> 
> The attached Word document is intended as a complete replacement
> for section 7.3.1.  It is based on the JavaCAA draft that we
> adopted to resolve JAVA-104.
> 
>   Simon
> 
> /(See attached file: 
> Issue129Proposal.doc)/---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Issue129Proposal2.doc