ComplexType consisting only of sequence results in empty object

[MarkSRobinson]

ComplexType consisting only of sequence results in empty object

[dmak]

That is interesting catch. Certainly there is a bug in library, as it dot handle Java reserved word return. Could you handle the situation by applying JAXB customization for this property?

[dmak]

Unfortunately, I cannot reproduce the issue. Are you using version 1.1 of the plugin? If yes, could you please provide more verbose XSD or create a small project that demonstrates the problem (based on any from samples)? I am pretty sure that version 1.0 of plugin has certain problems.

I have added another Unit test in commit 5f0a6be, which shows that reserved Java words are processed correctly.

[dmak]

Thanks for creating pull request. I think I have clean idea about was is happening. Unfortunately it is not possible to determine that given type is used as root type, that is why the given candidate is removed. Additional check to be added should be the following:

• If candidate class was never substituted, it should not be removed (perhaps is root type).

In your case ListRequest is empty, as described by XSD, and ListResponse is gone :( So in your original bug report NotifyRequest should be empty as expected, and NotifyResponse is removed and causes a compilation error – am I right?

Log information:

[INFO] Candidates:
[DEBUG] Candidate found: org.jvnet.jax_ws_commons.test.ListResponse [private List<String> items]
[INFO]  [!]: (default): org.jvnet.jax_ws_commons.test.ListResponse
[INFO]  1 candidate(s) being considered.
[INFO]
[INFO] Modifications:
[INFO]  0 modification(s) to original code.
[INFO]
[INFO] Deletions:
[INFO]  Removing method org.jvnet.jax_ws_commons.test.ListResponse createListResponse() from org.jvnet.jax_ws_commons.test.ObjectFactory
[INFO]  Removing class org.jvnet.jax_ws_commons.test.ListResponse from package org.jvnet.jax_ws_commons.test
[INFO]  2 deletion(s) from original code.

[svaor]

I'm not an author of the original bug report. I googled this bug because it's reproduced in my project. So I decided to attach SSCCE that illustrate original problem. My sample project is not the same as a original "notifyResponse" sample.

[dmak]

The problem is clear and there is in general no golden bullet solution. In principle certain types can be used as part of other types and as root types as well. To repliably fight against false deletions one should use -Xxew:exclude filename (put fully qualified classes into that plain text file, separated by newline).

[dmak]

Ah, I found another problem: the documentation is not in line with code. v1.1 of the plugin requires -Xxew:excludeFile filename, but it should fail in case the argument is not recognized.