www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <dava...@gmail.com>
Subject Can changing class loader behavior in Ant can violate Java SE license
Date Mon, 12 Feb 2007 18:09:07 GMT

Does anyone know of a clause in a Java SE license that we would
violate if we change class loading behavior in our code? Case in
point, Sun forced an version of JAXWS RI implementation into
JDK1.6/Mustang. Which is in fact brain dead and out-dated that the Sun
team is asking users to drop in JAXWS-RI 2.1 [1] if folks run into
problems. But the endorsed mechanism override mentioned in [1]
possible works because of a special hack [2]. So when i brought it up
and Steve sensed possible problems with Ant and how it could be
tackled, we get a reply back (see enclosed email) stating " it might
be prudent to make sure that it does not violate the Java SE license"

So here i am asking, Can changing class loader behavior in Ant can
violate Java SE license? Just to cover the base, Another question
would be can we implement the same behavior as [2] in Axis2 to get
things running under JDK1.6?


PS: All the discussion is on public soapbuilders mailing list on yahoo groups.

[1] http://weblogs.java.net/blog/vivekp/archive/2007/01/running_jaxws_2.html
[2] http://weblogs.java.net/blog/kohsuke/archive/2007/02/howitworks_runn.html
---------- Forwarded message ----------
From: Doug Kohlert <Doug.Kohlert@sun.com>
Date: Feb 12, 2007 11:06 AM
Subject: Re: [soapbuilders] [ANN]JAX-WS 2.1 FCS released
To: Steve Loughran <steve.loughran@gmail.com>
Cc: dims@apache.org

Thanks for your explanation of how Kohsuke's solution might be a problem
for ant.  I am adding him to this thread.
I think your proposed solution to ant might be beneficial, however, it
might be prudent to make sure that it does not violate the Java SE
license.  I will raise the interop testing suggestion internally.


Steve Loughran wrote:
>> From: Doug Kohlert <doug.kohlert@sun.com>
>> Date: Feb 9, 2007 11:59 PM
>> Subject: Re: [soapbuilders] [ANN]JAX-WS 2.1 FCS released
>> To: soapbuilders@yahoogroups.com
>> Thanks Steve,
>> I will bring this up internally and get back to you next week.
> Doug,
> 1. I think the main concern of the Ant team would be that you don't
> leak classloaders over time, not because they care about memory
> leakage, but because it really upsets the IDE teams downstream. They
> want IDEs to run for weeks without problems, and complain when ant
> builds cause problems. I think tasks probably get cleanup for free if
> they are all loaded under an AntClassLoader, but if any class loaded
> in a subsidiary classloader is somehow retained in any form, the
> custom classloader will hang around with corresponding consequences.
> 2. I've proposed a declarative away to manipulate which classes get
> passed down from the Ant classloader:
> http://www.1060.org/blogxter/publish/5
> there'd be an API way that could be used, including over reflection
> (useful for tasks that want to run on versions  of ant before this
> patch goes in)
> 3. On the subject of testing, here's a video on how I interop tested
> my WSRF impl with others:
>  http://smartfrog.org/autolinks/googleLTAC06.htm
> that was a few months ago; were I to do it now, I'd consider hosting
> on amazon EC2. dirt cheap, good bandwidth and better availability than
> a laptop in a room in my house.
> The axis team have been hinting they'd like to do more classic
> SOAPBuilder style interop testing, and there's nothing to stop all the
> OSS soap stacks from being built together and tested against each
> other on a daily basis. It's purely engineering effort, rather than
> legal issues.
> This would be a good incentive for the glassfish team to implement
> smartfrog deployment components; so far we've focused on tomcat and
> jboss.
> -steve

Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers

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

View raw message