Skip to content
This repository has been archived by the owner on Feb 5, 2019. It is now read-only.

multiple namespaces are serialized #103

Open
glassfishrobot opened this issue Oct 18, 2005 · 26 comments
Open

multiple namespaces are serialized #103

glassfishrobot opened this issue Oct 18, 2005 · 26 comments

Comments

@glassfishrobot
Copy link
Contributor

have two separate packages
com.company1.doc
and com.company2.doc

every package contains namespace definition (in package-info.java):
@javax.xml.bind.annotation.XmlSchema(namespace = "http://company1.com/doc")
package com.company1.doc;

and
@javax.xml.bind.annotation.XmlSchema(namespace = "http://company2.com/doc")
package com.company2.doc;

I initialize JAXBContext using JAXBContext.newInstance("com.company1:com.company2");

Then I construct java objects in both packages:

Problem is then I unmarshall documents of one package I see namespace of another
package:

...

Is it possible to avoid printing of unused namespace ?

Environment

Operating System: All
Platform: All

Affected Versions

[2.0 EA1]

@glassfishrobot
Copy link
Contributor Author

Reported by ramazanyich2

@glassfishrobot
Copy link
Contributor Author

Was assigned to snajper

@glassfishrobot
Copy link
Contributor Author

kohsuke said:
Hmm.

Would it be possible for you to try the latest nightly build? I remember fixing
an issue like this some time ago, and I couldn't reproduce the problem with the
current snapshot of the JAXB RI.

If it still doesn't work, please reopen the bug so that it gets our attention.

@glassfishrobot
Copy link
Contributor Author

File: testJaxb.java
Attached By: ramazanyich2

@glassfishrobot
Copy link
Contributor Author

ramazanyich2 said:
Created an attachment (id=57)
test class file which produces output

@glassfishrobot
Copy link
Contributor Author

ramazanyich2 said:
Created an attachment (id=58)
class file for first package

@glassfishrobot
Copy link
Contributor Author

File: TestClass1.java
Attached By: ramazanyich2

@glassfishrobot
Copy link
Contributor Author

ramazanyich2 said:
Created an attachment (id=59)
class file for second package

@glassfishrobot
Copy link
Contributor Author

File: jaxb.index
Attached By: ramazanyich2

@glassfishrobot
Copy link
Contributor Author

ramazanyich2 said:
Created an attachment (id=60)
package info for second package

@glassfishrobot
Copy link
Contributor Author

File: package-info.java
Attached By: ramazanyich2

@glassfishrobot
Copy link
Contributor Author

ramazanyich2 said:
Created an attachment (id=61)
package info for first package

@glassfishrobot
Copy link
Contributor Author

File: package-info.java
Attached By: ramazanyich2

@glassfishrobot
Copy link
Contributor Author

ramazanyich2 said:
Created an attachment (id=62)
result of execution

@glassfishrobot
Copy link
Contributor Author

File: test.xml
Attached By: ramazanyich2

@glassfishrobot
Copy link
Contributor Author

ramazanyich2 said:
I tried it with lates build ( dated by 8 november) but in result I still have
all namespaces.
I attached all files to the issue. Run testJaxb.java and you will have test.xml
as result.
It will have <ns2:test1 xmlns:ns2="http://company1.com"
xmlns:ns3="http://company2.com">
xmlns:ns3="http://company2.com" is unwanted as object TestClass2 was not created.

@glassfishrobot
Copy link
Contributor Author

ktrapszo said:
Using 4/19/2006 build, this is still an issue.

@glassfishrobot
Copy link
Contributor Author

kohsuke said:
This is actually the expected behavior.

In 1.0, we did what ramazanyich2 wanted us to do — namely, declare namespaces
lazily on-demand, only when it's necessary. Often this results in namespaces
declared multiple places in sub-trees, and many people weren't happy with this.

We can't make it any smarter, as in short of traversing the whole object tree,
The marshaller won't be able to discover all the namespaces in use. Such
traversal would be very costly.

So in 2.0 we decided to change the behavior to always declare all the statically
known namespaces upfront. This also made the namespace management inside the
marshaller simpler, contributed to the overall performance improvement.

Given those background, at this point we are not planning to change this behavior.

@glassfishrobot
Copy link
Contributor Author

mindchi said:
I'm requesting that this issue be reopened as having the extraneous namespaces
causes problems when using JAXB as the data binding framework for CXF. Firstly,
I think it is unacceptable to have a solution which changes your data. If I
take an XML file read it in and write it back out, I should end up with exactly
the same file. Not a file that has extra stuff in it. This reason alone should
be enough to warrant a fix.

I am writing some web service code using CFX and JAXB. I check my code all the
way to the point where I include it as an element of a larger document that
gets passed into CFX framework for handling web service processing. When it
comes out, it has extra tags in it. It is sent to publish and subscribe server.
When I try to read the data when I retrieve it from the server, CXF produces a
SAX parse exception due to one of the extraneous namespaces which it wasn't
expecting. Now, it may be possible for me to intercept the data and remove the
extranuous namespace definitions, but this is an enterprise system, and I
cannot expect every other application to do this. Up until this point, my
experience with JAXB has been good. I like the performance, however, this issue
basically renders JAXB useless to me on this project. I would like to continue
to use JAXB, however, I don't expect this to be fixed anytime soon, so I will
need to look into using some other data binding framework, perhaps XMLBeans
with CXF.

Please consider correcting this problem so I can continue using JAXB in
conjunction with CXF.

@glassfishrobot
Copy link
Contributor Author

aempinheiro said:
Referring to the comment before, altering the existing xml means that, if I open a signed xml jaxb will change it and its' signature won't be valid anymore.

This means that this issue represents quite a big problem.

@glassfishrobot
Copy link
Contributor Author

rustamabd said:
I disagree with the reasoning provided by 'kohsuke', performance can have different meaning, for some users network throughput has higher importance than CPU cycles. For example take small secured services, these have lots of OASIS headers and small payloads. Unnecessary namespace overhead in these is big, while the overhead of traversing a dozen nodes would be negligible.

I propose to have an optional feature (with a possibility to turn it on and off) to traverse the tree and eliminate unnecessary namespace declarations. This can be made even smarter; e.g. stop traversing after reaching 100th node.

@glassfishrobot
Copy link
Contributor Author

thst said:
I am wondering why it would not be possible to keep a list of used namespaces during production and add them in a second step to the final dom. This way there is no need to traverse the whole tree a second time, only a visit in the documentroot as a last step.

I understand that this would not work on a streaming output, but treewalking would have the same issue.

@glassfishrobot
Copy link
Contributor Author

ajsmen said:
@kohsuke:

In 1.0, we did what ramazanyich2 wanted us to do — namely, declare namespaces
lazily on-demand, only when it's necessary. Often this results in namespaces
declared multiple places in sub-trees, and many people weren't happy with this.

What about lazily on-demand add namespaces to some sort of set during document creation and at the end append all of them to the root element?

@glassfishrobot
Copy link
Contributor Author

This issue was imported from java.net JIRA JAXB-103

@rhdsmnd
Copy link

rhdsmnd commented Sep 7, 2017

What's the consensus around adding a setting that has the marshaller run an extra pass through the document and eliminate unused namespaces?

@epochcoder
Copy link

We are in a process of converting of converting a lot of legacy code that was using Apache XMLBeans to JAXB, this was a feature provided there OOB; and is stopping us from doing a (clean) migration.

We now have workarounds to only create a JAXBContext for the classes involved in (un)marshalling;

Providing a feature toggle for this new functionality would be great

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants