|
Replies:
17
-
Last Post:
Aug 23, 2006 9:44 PM
by: kohsuke
|
|
|
|
|
|
|
Problem with New 2.0.1 M1 Release
Posted:
Aug 17, 2006 11:43 PM
|
|
|
I am publishing an endpoint using the built-in HTTP server. My code works fine with JAX-WS 2.0, but in trying the new 2.0.1 M1 version I get the following errors (among others). Any ideas?
java.lang.NoSuchMethodError: com.sun.xml.bind.api.Bridge.unmarshal(Lorg/w3c/dom/Node;Ljavax/xml/bind/attachment/AttachmentUnmarshaller;)Ljava/lang/Object;
at com.sun.xml.ws.message.saaj.SAAJMessage.readPayloadAsJAXB(SAAJMessage.java:227)
at com.sun.xml.ws.server.sei.EndpointArgumentsBuilder$Body.readRequest(EndpointArgumentsBuilder.java:406)
at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:239)
at com.sun.xml.ws.server.sei.SEIInvokerPipe.process(SEIInvokerPipe.java:97)
at com.sun.xml.ws.handler.HandlerPipe.process(HandlerPipe.java:107)
at com.sun.xml.ws.handler.HandlerPipe.process(HandlerPipe.java:107)
at com.sun.xml.ws.protocol.soap.ServerMUPipe.process(ServerMUPipe.java:62)
at com.sun.xml.ws.server.WSEndpointImpl$1.process(WSEndpointImpl.java:139)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:151)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:223)
at com.sun.xml.ws.transport.http.server.WSHttpHandler.handleExchange(WSHttpHandler.java:101)
at com.sun.xml.ws.transport.http.server.WSHttpHandler.handle(WSHttpHandler.java:78)
|
|
|
|
|
|
|
Re: Problem with New 2.0.1 M1 Release
Posted:
Aug 17, 2006 11:49 PM
in response to: zmonster
|
|
|
Note that I am using the recently released JAXB 2.0.2. I am referencing the jaxb-impl.jar that is included with the JAXB release, NOT the jaxb-impl.jar that is included with the JAX-WS release (I have no idea why JAX-WS has it's own JAXB jar). Evidently the two jaxb-impl.jar releases are out of sync. Can this be fixed quickly? I mean, should both JAXB and JAX-WS define a jaxb-impl.jar? I would really rather only have to reference a single jar.
|
|
|
|
|
|
|
|
|
Re: Problem with New 2.0.1 M1 Release
Posted:
Aug 18, 2006 6:13 PM
in response to: zmonster
|
|
|
The JAXB implementation in JAX-WS 2.0.1 m1 is newer than JAXB 2.0.2. That's why you have this problem.
I guess the JAXB project needs to release 2.0.3.
|
|
|
|
|
|
|
|
|
Re: Problem with New 2.0.1 M1 Release
Posted:
Aug 18, 2006 6:16 PM
in response to: kohsuke
|
|
|
Can anyone from the JAXB project comment on a pending 2.0.3 release?
Is the JAXWS M1 release considered production ready, or should I continue to use 2.0.0 for production?
|
|
|
|
|
|
|
|
|
Re: Problem with New 2.0.1 M1 Release
Posted:
Aug 18, 2006 6:19 PM
in response to: zmonster
|
|
|
I was hoping to release 2.0.3 with the same bits that I deliver to JDK6, when it ships.
I can tell you that the JAXB implementation in JAX-WS 2.0.1 m1 is as good and stable as JAXB 2.0.2. Do you still need a official version number for that?
I believe JAX-WS 2.0.1 m1 is still considered early access quality (although I believe our tests show that it's doing quite good.)
|
|
|
|
|
|
|
|
|
Re: Problem with New 2.0.1 M1 Release
Posted:
Aug 18, 2006 6:25 PM
in response to: kohsuke
|
|
|
Why does JAX-WS have a jaxb jar in the first place? I have a project that uses both jaxb and jax-ws. When I configure applications I want to be able to reference the jaxb jar in one place. I don't think JAXWS should include the JAXB jars. I think the user should download JAXB separately. That is my take on it.
|
|
|
|
|
|
|
|
|
Re: Problem with New 2.0.1 M1 Release
Posted:
Aug 18, 2006 6:58 PM
in response to: zmonster
|
|
|
Wait a minute. Something just occurred to me. Why is JAXWS calling a method that does not exist in JAXB? If you inspect the stack trace I posted above:
java.lang.NoSuchMethodError: com.sun.xml.bind.api.Bridge.unmarshal(Lorg/w3c/dom/Node;Ljavax/xml/bind/attachment/AttachmentUnmarshallerLjava/lang/Object;
at com.sun.xml.ws.message.saaj.SAAJMessage.readPayloadAsJAXB(SAAJMessage.java:227)
you see that SAAJMessage is calling a method that does not exist in JAXB 2.0.2. I thought JAXB was a final spec? Why does the JAXB included with JAXWS have a different public API from JAXB 2.0.2? The more I think about this, the more it seems like a bug. JAXWS appears to be calling an undefined JAXB method.
|
|
|
|
|
|
|
|
|
Re: Problem with New 2.0.1 M1 Release
Posted:
Aug 19, 2006 9:46 PM
in response to: zmonster
|
|
|
[Re: bundling]
I think a lot of users appreciate a convenience that all they need to download is the JAX-WS RI. If we ask them to additionally download the JAXB RI, the SAAJ RI, SJSXP, and then FastInfoset, then I'm sure it will turn off a lot of people.
[Re: undefined method]
The JAX-WS RI uses some private API of the JAXB RI. We've added a few since JAXB RI 2.0.2. So when you use JAX-WS 2.0.1 m1 and JAXB RI 2.0.2, then you get this kind of LinkageError, because JAX-WS 2.0.1 m1 expects new additions that are not in JAXB RI 2.0.2.
When X depends on Y, and you use the version of Y earlier than what's required by X, then this error happens. People tend to consider this as a deployment issue, not a "bug" per se. If your application requires JDK5, and if one of users run it on JDK1.4, then it's going to break. Is that a "bug"?
By the way, the missing method is on the RI, not on the API. Yes, both the JAXB API and the JAX-WS API are final, and they haven't changed at all since 2.0.
|
|
|
|
|
|
|
|
|
Re: Problem with New 2.0.1 M1 Release
Posted:
Aug 20, 2006 2:34 PM
in response to: kohsuke
|
|
|
Kohsuke says: "By the way, the missing method is on the RI, not on the API."
I don't think that JAX-WS should be calling a method that is not present on the JAXB API. This makes JAX-WS incompatible with other implementations of JAXB. What if someone had their own JAXB implementation, or wanted to use a non-Sun solution? They would not be able to use JAX-WS without having to reference the jaxb jar included with JAX-WS, and that would cause all kinds of problems.
Does anyone agree that JAX-WS should not reference non-standard JAXB API? I hope others agree because I would like to see a quick patch to JAX-WS that fixes the problem I outlined above.
|
|
|
|
|
|
|
|
|
Re: Problem with New 2.0.1 M1 Release
Posted:
Aug 21, 2006 5:09 PM
in response to: zmonster
|
|
|
I agree that breaking the API between different sub-point-point releases is, to put it frankly, Ass.
However, you have a fix. Why not just use the JAXB included inside JAX-WS 2.0.1???
How much effort would it take to throw out JAXB 2.0.2 anyway? Why are you so attached to it? Just use the newer one, nuke the older one, and move on.
|
|
|
|
|
|
|
|
|
Re: Problem with New 2.0.1 M1 Release
Posted:
Aug 21, 2006 8:33 PM
in response to: rickcarson
|
|
|
Why not use the newer JAXB? Because I have a deployment environment where some projects depend on the JAXB, and other projects depend on both JAX-WS and JAXB. I want to reference a single JAXB jar and I don't want the JAXB-only projects to have to depend on anything included with JAX-WS. It's a dependency separation issue. I do not think JAXB should be included with JAX-WS, nor do I think JAX-WS should call private JAXB API. JAX-WS should require users to download the separate JAXB jar. I do not understand why JAXB is repacked with JAX-WS.
|
|
|
|
|
|
|
|
|
Re: Problem with New 2.0.1 M1 Release
Posted:
Aug 21, 2006 9:55 PM
in response to: zmonster
|
|
|
I still don't understand the problem. So you don't want to deploy JAX-WS with projects that only need JAXB?
It sounds more like a philosophical objection, than a practical one? What do you mean by 'deployment environment'?
If you're worried about consuming too much hard drive or download bandwidth or something like that (hence not wanting to deploy JAX-WS instead of JAXB), then why can't you just pull out the JAXB classes from the JAX-WS, and rebundle that as JAXB 2.0.3, and then all your projects will be using exactly the same version of JAXB, and your badnwidth type resources will be conserved? (I presume different versions of JAXB was causing the original bug, two different projects trying to talk to each other, but with different versions of JAXB)
We had a similar problem at work recently. Oracle had implemented their own javax classes, and they'd done it badly enough that it stuffed up our JAX-WS Web services in strange and unusual ways.
My solution was to take out the config files in the jar which specified using Oracle's classes. Now this was perceived as 'non optimal' in the long term, because it was not reproducible with an automated (build) process.
Whereas that is such an abstract concern that I'm ignoring that. If they want to have Ant download the file from Oracle, remove the config etc every time that they do a build... then they've passed 'sub optimal' a long way back, and they're going in the wrong direction.
|
|
|
|
|
|
|
|
|
Re: Problem with New 2.0.1 M1 Release
Posted:
Aug 21, 2006 10:35 PM
in response to: rickcarson
|
|
|
You are totally missing my point. Why does a JAXB jar even get distributed with JAX-WS? JAXB is it's own project. JAX-WS should depend on the separate jar so that everything stays in sync and we don't run into problems like this. JAX-WS should not be calling undefined methods in the first place. There are numerous problems here that I hope get addressed. I am done with this thread. Nobody seems to get it.
|
|
|
|
|
|
|
|
|
Re: Problem with New 2.0.1 M1 Release
Posted:
Aug 22, 2006 6:25 PM
in response to: zmonster
|
|
|
In the ideal world, a JAX-WS implementation should talk to a JAXB implementation only through the JCP-defined JAXB API. That would be nice for all the obvious reasons. However, in practice, there's a very high cost in defining a JCP API and maintaining compatibility forever after. So the reality often necessitates some private interactions, which is much cheaper to developm, maintain, and change.
We do realize that such private interaction could potentially lead to a problem. One such ugly case would be for a newer version of the JAXB RI to stop working with the current version of the JAX-WS RI. This is ugly because someone might need the bug fix in the newer JAXB RI, yet the same person might also need to use the JAX-WS RI. We try hard to avoid this.
But the problem we have here is not that ugly. We try to make our point releases (2.0.x) backward compatible with each other. So if you has been using 2.0.2, then you should be able to upgrade to any 2.0.x (with X>2) without serious hesitation. While the JAXB RI version bundled with JAX-WS doesn't have the official JAXB version number, it's as stable as 2.0.2, and so you can swap that into anywhere where you've been using 2.0.2, and it will work fine. I have a pretty high confidence that it will work.
Also notice that this kind of version conflict resolutions are done commonly. One of your library uses commons-logging 1.0.2 and another is using commons-logging 1.0.3? Just use commons-loggin 1.0.3. Again, some projects don't take backward compatibility too seriously so this breaks, but trust me, we do take the backward compatibility very seriously.
That said, I agree with you in essence that if some public versions of JAX-WS, Glassfish, JDK6, and whatnot bundles a version of the JAXB RI, then that JAXB RI should better have some version number with it. For example, that would allow you to correlate the JAXB bug database with bugs you found in Glassfish.
But the other side of this is to avoid creating too many versions. We don't want to end up releasing new 2.0.x every week, for example, because there's cost associated with doing so both for us and for our users. In JAXB, we are still trying to find the right balance. Since this JAX-WS 2.0.1 m1 is really just a milestone release, I thought I could skip this one.
We definitely plan to release the corresponding JAXB RI when, say, JAX-WS releases 2.0.1, or Glassfish releases 9.1, or JDK6 is released, etc.
Finally, I've already responded to your bundling question. In the ideal world, or in a world where everyone uses Maven, there's no need for bundling. But the reality is that not everyone is using Maven, and we have many users that find bundling convenient. So in all likelihood we'll keep bundling the JAXB RI to the JAX-WS RI.
|
|
|
|
|
|
|
|
|
Re: Problem with New 2.0.1 M1 Release
Posted:
Aug 23, 2006 2:21 PM
in response to: kohsuke
|
|
|
I have to agree with zmonster here, most strenuously. The problem is not so much versions of jar files or having multiple jar files for projects. The problem is you have a project that is dependant on JAXB and, even though JAXB has a specification, you are not using JAXB according to its specification. Instead you are calling private methods found only in Sun's version of JAXB. When you say JAX-WS depends on JAXB, most developers would assume that you mean it depends on ANY implementation of the specification, not a specific implementation. If Apache, for instance, were to write a JAXB implementation, JAX-WS should work with it. What's the point of the JAXB spec if you are going to make things easier/better/faster (whatever) by calling methods that aren't in the spec...
Don
|
|
|
|
|
|
|
|
|
Re: Problem with New 2.0.1 M1 Release
Posted:
Aug 23, 2006 6:46 PM
in response to: kohsuke
|
|
|
> Also notice that this kind of version conflict
> resolutions are done commonly. One of your library
> uses commons-logging 1.0.2 and another is using
> commons-logging 1.0.3?
{hani mode=on}
With respect, this is equivalent to arguing that pooping on the sidewalk is okay, because at least your shit isn't as smelly as someone elses.
It is still shit.
{hani mode=off}
The commons-X libraries are about as bad an example as I have ever run into of bad coding practices by breaking reverse compatibility in the Java world. Setting them as your standard sets the standard too low.
|
|
|
|
|
|
|
|
|
Re: Problem with New 2.0.1 M1 Release
Posted:
Aug 23, 2006 9:44 PM
in response to: rickcarson
|
|
|
When you have transitive dependencies to two versions of the same library, the common practice is to pick the newer version of two. That is what I meant.
That is the solution I proposed to zmonster, and that works just fine for the JAXB RI. "commons-logging" could have been anything else. It was just a noun to make it more concrete than, say, "library X".
|
|
|
|
|
java.net RSS
