-
1. Re: javaee5 signature compliance vs. backport portability
heiko.braun Sep 27, 2007 4:57 AM (in response to thomas.diesler)Well, there is a few things to be considered:
* The jax-ws 2.1 additions are not removed, the stack will still be able to consume it
* They moved to a separate jar (JDK 6 endorsed requires it). That means client that rely on 2.1 API need update their class-path
* It breaks compatibility for those client that rely on JAX-WS artifacts that exist in two versions, i.e. Service.
* However this deals with WebServiceFeature and EndpointReference. I don't believe many people used it, since WebServiceFeature was non-functional.
But yes, you are right. It breaks backwards compatibility in a few places. -
2. Re: javaee5 signature compliance vs. backport portability
heiko.braun Sep 27, 2007 5:14 AM (in response to thomas.diesler)Regarding the final packaging: Running with JDK 6 (endorsed mechanism) opposes the biggest problem at the moment. This requires further investigation. The solution I proposed might not be final. I'll keep you posted.
-
3. Re: javaee5 signature compliance vs. backport portability
thomas.diesler Sep 27, 2007 5:46 AM (in response to thomas.diesler)What it boils down to probably is the question whether Service clients generated with >= jbossws-2.0.1 will work with the upcomming jbossws-2.0.2? Will that be the case by default (i.e. without having used a special 2.1 switch)?
In any case we need a jira task that documents this so it actually makes it into the release notes. -
4. Re: javaee5 signature compliance vs. backport portability
heiko.braun Sep 27, 2007 5:58 AM (in response to thomas.diesler)yes, the target switch used by our tools default to 2.0