Thanks for the reply. I can guarantee that this *was* an issue in our
production environment and i also agree that this "shouldn't" have been
a problem. We have an automated build sequence which checks out from
svn our entire project, builds it, wars, it and then we ship it to our
app server manually via scp... pretty 'simple' stuff... it's hard for it
to 'go wrong'. in fact - it hasn't "gone wrong" for quite some time...
so - here's our exact scenario...
- source compiled with jdk 5 on solaris 9
- a 'generated classes' jar file compiled with jdk 6 on win xp
- war 'built' on solaris 9 with jdk 5 (not that it should
matter)
i build the 'generated classes'.jar file (compiled with jdk 6) and
committed to svn. the automated build process checked out all the .java
files, compiled them, and warred them and the 'library' jars together.
the very next day we were seeing messages qualified with the ns2:
namespace...
i agree with you that the namespace "usually" doesn't matter. i say
"usually" because in this case the system at the other end was an ESB of
sorts and doesn't actually marshall the message into objects but instead
was looking for the root element to be in a certain namespace. for many
of the messages - this worked quite fine. the xml looked something
like:
<ns2:myElement xmlns:ns2="some
uri"><blah/><blah/><blah/></ns2:myElement>
this is perfectly valid xml as you said... (more on that to follow
though)
however - every once in a while we'd see messages like:
<someOtherElement xmlns:ns2="some
uri"><blah/><blah/><blah/></ns2:someOtherElement>
in the above case the 'someOtherElement' namespace is the 'local'
namespace but the ESB is looking for a root element qualified in the
"some uri" namespace... so this indeed caused problems...
as for the 'user misunderstood the XML namespace recommendation' - this
was a problem for the ESB in question (not our problem) but it
'transitively' became our problem... they couldn't do something - which
meant we couldn't do something - which meant i needed to be involved...
that's REALLY why i made this post...
thanks for the reply though - let me know if that doesn't clarify things
enough...
-Clint
-----Original Message-----
From: Kohsuke Kawaguchi [mailto:Kohsuke.Kawaguchi_at_Sun.COM]
Sent: Tuesday, January 16, 2007 5:48 PM
To: users_at_jaxb.dev.java.net
Subject: Re: ns2 issue
Hi,
As long as all the JAXB implementations involved (be it one in JDK6, the
JAXB RI, or a JAXB implementation from some other vendors) implement
JAXB 2.0, you should be able to use one for development for another for
deployment.
This is particularly true between JDK6 and the JAXB RI, because they are
essentially derived from the same codebase. So I doubt if that's really
the root cause of the issue.
JAXB using "ns2" as the namespace prefix by itself is not a bug.
Prefixes are just proxies, and machines don't care whether prefixes have
any relation to English words or not at all. They are just the same.
If you'd like JAXB to use more human-friendly prefixes, however, we let
you do so, too. Just look at the namespace-prefix sample in the JAXB RI
distribution.
You haven't gave us the exact nature of the "misqualifying" problem, so
I can't say what might be causing it. However, often the perceived
problem is simply that the user misunderstood the XML namespace
recommendation. I'm not saying you are, but I'm just saying in general
it's the #1 "cause" of this issue. For this, I recommend
http://www.jclark.com/xml/xmlns.htm
If you still experience problems, please explain more details about the
problem. We are happy to help.
Dovholuk, Clint wrote:
> Hello all,
>
> I'm sending this email to the distribution list in hopes that someone
> else who has a problem with jaxb qualifying the root element with
"ns2"
> (or sometimes MIS-qualifying it) has the same problem we have and as a
> general fyi to the community.
>
> In our scenario this was not a bug with JAXB (well - at least I don't
> "think" so). We use jaxb to generate class files to consume POX
> services. Those class files are compiled into a jar and included with
> our war. During the last release cycle - the compiled jar file was
> compiled with java 6, but we were still using java 5 for production.
> As such, the compiled class files were compiled with a different
> version of jaxb (due to inclusion with java 6).
>
> These classes would "pretty much" work in production but the xml would
> either be wrong or entirely qualified with ns2.
>
> I just wanted to share this to the distro to give other people out
> there who run into similar issues one more thing to "rule out".
>
> Thanks,
> -Clint
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com