https://github.com/OpenNMS/opennms/pull/2016

As discussed with @j-white: we will just update the documentation.

@agalue, @j-white,

I looked into the issue and found the following:

It seems (like @agalue wrote already) the way to attach namespaces to the XML generation is on the package level. However it is also possible to override that on a type (class) or field (property) level, see: http://www.eclipse.org/eclipselink/documentation/2.5/moxy/type_level002.htm

I tried to set the namespace only on the class level but that showed no effect in the generation (no schema was attached)

 resulted in:

However when I set the namespace on the package level

AND the class level, I got:

=> we have 2 namespaces: the one from the package level and the one from the class level.

Now, what do we do with these findings?
I see different roads we could go (sorted by difficulty / effort), although there might be more:

1. do nothing

and update the documentation as @agalue suggested

2. have two namespaces

If we are happy with the 2 namespaces we could stick a default one at the package level and one at the class level

3. move classes to different packages

This is probably the cleanest way of doing it and it can be done incrementally.

4. rewrite xml on the fly

Use a javax.ws.rs.ext.WriterInterceptor or a similar mechanism to alter the generated XML after the marshalling, before it's send to the client. I am not very much in favor of this solution (because it is not the standard way and not very transparent) but I added it for completeness.

What do you guys think? How shall i proceed?

In case there are technical issues that prevents us to fix this issue, we should update the documentation, to explicitly mention that the XML output doesn't return the namespace on any end-point.

The problem seems to be related with Eclipse MOXy (the library we use to marshal/unmarshal XML documents).

It seems like the solution is to properly setup the XmlSchema annotations on the package-info.java files with the expected schema (or set of schemas if apply). The problem is that this might require lots of changes to re-organize all the classes associated with a specific schema into a separate and dedicated package, and SnmpInfo is an example for this.