Sun sometimes allows implementations to certify using a newer api
then was in required by the original JEE specification. My guess is
that the next version of Glassfish uses these apis, so hopefully if
we ask, they'll give us new signature files or a patched TCK.
Anyway, to find out someone will have to ask on the Apache open-jcp
list, and that person will have to commit to hounding that list until
we get an up or down response. It is a lot of work and can take
weeks/months to get a response, so I suggest you don't agree to take
on this task unless you are going to have the time and commitment.
-dain
On Mar 1, 2007, at 10:24 AM, Jeff Genender wrote:
AFAICT...the TCK for JAXB appears to be for 2.0.:
https://jaxb.dev.java.net/tck.html
and it appears that particular TCK is open to all ;-)
On that web site it clearly states:
**************************************************
Compatibility artifacts are available as follows:
* The JAXB 2.0 PFD specification.
**************************************************
We probably need to kick this up to Sun, but for safety, I would stick
with 2.0 until we hear back from them.
Thoughts?
Jeff
David Blevins wrote:
On Mar 1, 2007, at 9:42 AM, Dan Diephouse wrote:
I think we are all open to input on this particular point. Is there
any way we can figure out what the JEE5 requirements are though?
Assuming 2.1 is backward compatible to 2.0 the only real
limitation can
see is that often when testing the api libraries themselves (in this
case the jaxb api), the requirements often follow a "no more and no
less" policy. Which means that say we wanted to start
implementing the
new imaginary EJB 3.1 and it added two new methods on the
InvocationContext interface, it would fail JEE5 certification.
I don't know what the case is for apis associated with jaxb 2.1 vs
jaxb
2.0 or jax-ws 2.1 vs jax-ws 2.0. Someone needs to look at the tck to
know for sure.
-David
Thanks,
- Dan
On 3/1/07, Jeff Genender <[EMAIL PROTECTED]> wrote:
Jarek Gawor wrote:
Oh... I didn't even realize you guys are targeting JAX-WS 2.1. Now,
I'm not sure how that affects things.
If the JavaEE5 TCK is only JAX-WS 2.0 compliant, this may be a
problem.
Jarek
On 3/1/07, Dan Diephouse <[EMAIL PROTECTED]> wrote:
I'm happy to revert the change, but I think that we ultimately
need
it. I
believe we're targeting JAX-WS 2.1 (we switched the API jar the
other
day),
and that requires JAXB 2.1. There are many benefits from a user
perspective
in 2.1 . For isntance it has a lot better functionality for things
like
WS-A
and also makes it easier for people to use substitution types,
which
requires all sorts of hacks right now.
Is Geronimo just looking to release JAX-WS 2.0 support or 2.1? Any
idea if
its possible to certify Geronimo with 2.1? Or does certification
require 2.0?
I'm not sure what the status is of the JAX-WS 2.1 TCK either.
- Dan
(I CC'd [EMAIL PROTECTED] in, hope thats ok)
On 2/28/07, Jarek Gawor <[EMAIL PROTECTED]> wrote:
Hi again,
CXF code was recently upgraded to JAXB 2.1 and so I tired to
figure
out what sort of implications that might have on Geronimo.
First of
all, JAXB is one of those libraries that is shared by all
applications
in the Geronimo server. We also have a bunch of different
components
using JAXB to do deployment descriptor parsing, etc. So if we
upgrade
JAXB in G, we have to retest all these subcomponents to make sure
they
are ok. And I think in general that should be ok but potentially
time
consuming. Another potential issue that somebody raised was TCK
testing. We don't know what happens if for example TCK expects
JAXB
2.0 API but gets JAXB 2.1 API/implementation. Maybe nothing (as
things
supposed to be backwards compatible) but maybe it blows up.
That's
another thing for us to worry about.
So, if this JAXB upgrade is not a critical issue for CXF would
it be
possible to switch back to JAXB 2.0?
Thanks,
Jarek
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
--Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
