www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eddie O'Neil" <ekon...@gmail.com>
Subject Re: altering jsr defined api classes
Date Tue, 25 Jul 2006 21:18:09 GMT
Craig--

  Yeah, that is pretty much what I expected and thanks for the
response -- there are clearly some interesting annotations that could
be added to Axis that would be useful, and we would presumably add
those to an org.apache.axis package.

  That being said, I didn't explain the question effectively, though I
expect the answer to be the same.  Basically, a proposal was floated
to add a new _annotation_ onto an existing annotation defined in 181.
This would be something like this:

<snip>
package javax.jws.WebService;

@org.codehaus.annogen.generate.AnnogenInfo(...)
@Retention(value = RetentionPolicy.RUNTIME)
@Target(value = ElementType.TYPE)
public @interface WebService {
    ...
}
</snip>

where "@AnnogenInfo" is the new meta-metadata.  :)  I expect that this
is still illegal.

  FWIW, I think we've got a workaround for this, though it's worth
clarifying the point as new annotations proliferate from specs.

  So, what do you think about this case?  :)

Eddie



On 7/25/06, Craig McClanahan <craigmcc@apache.org> wrote:
> On 7/23/06, Eddie O'Neil <ekoneil@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:
> legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
>
>

---------------------------------------------------------------------
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: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message