Thanks for that - I totally understand. In the grand scheme of things,
its not a major issue. I've just found myself wanting to access the
single QName thats associated with a particular Java type and to ensure
that the namespaces in my code and the generated POJOs keep in sync.
(e.g. if I switch XSD/WSDL, the internal QNames get auto-generated, but
because I'm pulling the QName instance out of the generated code
somehow I can relax and not worry about it rather than trawl around the
code which uses the referenced POJOs and makes its own QNames with
possibly different namespace definitions.
Now I'm more than happy to not have any of this stuff in the spec or RI
by default - I was just wondering if we could have an extension option
we can turn on.
e.g. here's a typical generated POJO (from WS-Addresssing)
@XmlAccessorType(value = AccessType.FIELD)
@XmlType(name = "Relationship", namespace =
"
http://schemas.xmlsoap.org/ws/2003/03/addressing")
public class Relationship {
...
}
what'd be really handy would be an extension option you can enable to
generate something like this...
@XmlAccessorType(value = AccessType.FIELD)
@XmlType(name = "Relationship", namespace =
"
http://schemas.xmlsoap.org/ws/2003/03/addressing")
public class Relationship {
public static final QName QNAME = new
QName("
http://schemas.xmlsoap.org/ws/2003/03/addressing",
"Relationship");
...
}
So there's a real simple way to extract the QName that a type is bound
to. Then there's no issue on how many QNames there are in the schema;
its only the top level QNames we keep around as a reference.
Not a huge issue though - I'm sure you've more important things to work
on - just something that'd be handy down the line.
On 5 May 2005, at 23:27, Kohsuke Kawaguchi wrote:
> jastrachan_at_mac.com wrote:
>> I'd find it quite handy to be able to refer to QName constants inside
>> the ObjectFactory generated from an XSL/WSDL. Right now they are
>> private and have a mangled name; any chance of either making the
>> fields public, or creating a little static getter method to return
>> them? Or is there a good reason to keep them hidden?
>
> In some of the big schemas people use, there are too many QNames and
> they actually go beyond the limit of the static initializer (for the
> code that creates QName gets bigger than 64K.)
>
> The RI currently stops generating QName constants before it hits this
> limit as a stop-gap measure. We were too lazy to work around this
> issue properly.
>
> Another issue is the possibility of the collision between the
> generated constant names. If the spec is going to talk about the
> public QNames, it needs to define the collision resolution rules and
> etc.
>
> Considering all those aspects, we felt that there are more important
> issues we could spend our time on. And if the spec is not going to
> talk about it, then the RI can't make them public, because our TCK
> people wouldn't let us do it.
>
> So that's how things came to the current state.
>
> Do you feel strongly that we should make QNames public? Now that we
> have your input, I guess we should probably revisit this issue...
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems kohsuke.kawaguchi_at_sun.com
>
James
-------
http://radio.weblogs.com/0112098/