| From | Sent On | Attachments |
|---|---|---|
| Eddie O'Neil | Jul 23, 2006 9:40 pm | |
| Craig McClanahan | Jul 25, 2006 2:06 pm | |
| Eddie O'Neil | Jul 25, 2006 2:17 pm | |
| Craig McClanahan | Jul 25, 2006 2:22 pm | |
| Eddie O'Neil | Jul 25, 2006 2:30 pm |
| Subject: | Re: altering jsr defined api classes | |
|---|---|---|
| From: | Craig McClanahan (crai...@apache.org) | |
| Date: | Jul 25, 2006 2:06:54 pm | |
| List: | org.apache.legal-discuss | |
On 7/23/06, Eddie O'Neil <ekon...@gmail.com> wrote:
All--
Now that the subject has your attention: :)
The Axis and Beehive communities need clarification on an issue that hopefully has an obvious answer. The issue is related to changing the "shape" of an API that is defined in a JSR. To date, it seems clear that such changes would be illegal when shipping implementations of said JSR. For example, it would be illegal to alter the name, parameters, or return type of a method -- ie Tomcat wouldn't have this liberty with classes in "javax.servlet".
The question is whether it's legal to amend _annotation_ interfaces defined by a JSR with new, additive annotations (meta-metadata, if you will). Specifically, one proposed design for a JSR-181 implementation in Axis2 requires amending classes in the "javax.jws" package with additional metadata to support Annogen and thus the 1.4 and 1.5 JVMs. This would require adding something like:
@AnnogenInfo(annoBeanClass=" org.apache.axis.metadata.annogen.WebServiceAnnoBean")
to javax.jws.WebService. So, is it legal to *add* metadata to a JCP defined API?
My gut feeling is that this is illegal and could be easily enforced by the JCP via an API compliance tool that enforces a fixed set of metadata; however, IA(obviously)NAL and wouldn't be surprised if I was missing something here. This seems like an issue that's worth clarifying as it's likely to come up as annotations proliferate.
Thanks for any comments.
You'll want to contact the spec lead on JSR-181 for a definitive answer, but all the JSR TCKs I am familiar with (not all of them by any means, but a pretty broad brush) do indeed include signature tests that enforce the rules about not changing API classes. Adding a new annotation in a javax.* package would in fact be adding a new public class, so it is the kind of thing that would be likely to get caught; hence, your gut feeling is likely to be accurate.
You could, of course, consider providing such an add-on annotation in an implementation-specific package rather than the standard one. Using it would tie your users to your implementation ... but of course that would be true even if the annotation were in the javax namespace since it would not be part of the standard and would therefore not be portable anyway.
Eddie
Craig
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational only. Statements made on this list are not privileged, do not constitute legal advice, and do not necessarily reflect the opinions and policies of the ASF. See <http://www.apache.org/licenses/> for official ASF policies and documents. --------------------------------------------------------------------- To unsubscribe, e-mail: lega...@apache.org For additional commands, e-mail: lega...@apache.org





