[JAXB-514] passing episode file to xjc api creates incorrect Model Created: 11/Jun/08  Updated: 24/Nov/14

Status: Open
Project: jaxb
Component/s: xjc
Affects Version/s: 2.1.7
Fix Version/s: not determined

Type: Improvement Priority: Critical
Reporter: ramapulavarthi Assignee: Iaroslav Savytskyi
Resolution: Unresolved Votes: 22
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Attachments: Zip Archive jaxb_episode.zip     Text File jaxb_episode.zip     Text File jaxb_episode.zip    
Issuezilla Id: 514


Attached is the testcase which simulates the way wsimport invokes xjc.
Passing episode works when directly used with xjc ant task. But wsimport uses
xjc api.
This is required for https://jax-ws.dev.java.net/issues/show_bug.cgi?id=368

Comment by ramapulavarthi [ 11/Jun/08 ]

Created an attachment (id=254)

Comment by ramapulavarthi [ 11/Jun/08 ]

Created an attachment (id=255)
Updated testcase

Comment by ramapulavarthi [ 08/Jan/09 ]

Another bug is filed on jax-ws
(https://jax-ws.dev.java.net/issues/show_bug.cgi?id=690) on the same note.

Comment by Pavel Bucek [ 16/Jan/09 ]

I've tried xjc with episodes from command line and via com.sun.tools.xjc.api.XJC
and both ways are working fine.

My code:

SchemaCompiler sc = XJC.createSchemaCompiler();

InputSource file = new
InputSource episode = new

// sc.getOptions().scanEpisodeFile(new
File("/Users/pavel/jaxb/bugs/514/tryout2/a.jar")); // works too

S2JJAXBModel model = sc.bind();

JCodeModel jcm = model.generateCode(null, null);

It is working even with xsd and episode you've provided with testcase (after
fixed typos in file wrap.xsd (complesElement and AbstrcatType).

In uploaded testase you're checking for Hello class but it's already present in
episode file so xjc won't generate it. I'm not sure if I understood this
correctly so please reply if I'm missing something.

Comment by Pavel Bucek [ 04/Mar/09 ]

marking as incomplete

Comment by Pavel Bucek [ 19/Mar/09 ]

Closing as invalid. Feel free to reopen with additional info.

Comment by ramapulavarthi [ 20/Mar/09 ]

Reopening the issue.
Please see the testcase. As in the testcase, JAX-WS tries to get Element Mapping
from the model. Although the model has proper schema information,
model.get(QName) is not returning anything. I think there is some problem in
populating the JAXBModelImpl.byXmlName map.

Also, please use the newly attached testcase to reproduce the issue.

Comment by ramapulavarthi [ 20/Mar/09 ]

Created an attachment (id=301)
New testcase with the reopened issue.

Comment by Pavel Bucek [ 24/Mar/09 ]

Can you provide file common-targets.xml, please?

– removing incomplete keyword

– ant output:
$ ant
Buildfile: build.xml
/Users/pavel/jaxb/config/common-targets.xml could not be found

java.io.FileNotFoundException: /Users/pavel/jaxb/config/common-targets.xml (No
such file or directory)

– build.xml:
$ cat ./build.xml | grep common-targets
<!ENTITY commonTargets SYSTEM "../../../../config/common-targets.xml">

Comment by ramapulavarthi [ 24/Mar/09 ]

The common-targets does not have much other than setting up the classpath for
xjc and defining xjc task.

Your earlier test case should suffice for reproducing the problem, just check
the model (model.get(QName)), if it can give info about the elements defined in

Comment by fribeiro [ 14/Apr/09 ]

Any update yet?

Comment by Pavel Bucek [ 16/Apr/09 ]

We have a workaround.

After short brainstorming session with snajper we've discovered that the easiest
way to support this is do two models - one with episode file included and one
without it (so first will be used to generate java classes and second for
mapping check).

We are aware of performance loss in this case but this isn't used in runtime so
it shouldn't be a major issue.

Please, let us know if this is acceptable (at least for now).

Comment by euxx [ 12/May/09 ]

Is there an update on this?

This issue is very critical for us, we have a common schema and number of
extensions that should reuse the same binding files. So, without this fix the
wsimport can produce a conflicting code that fails at the runtime. Thanks.

Comment by fribeiro [ 08/Sep/09 ]

Any update yet?

Comment by Martin Grebac [ 11/Sep/09 ]

Pavle, did you contact Rama/Jitu about this one?

Comment by Martin Grebac [ 17/Sep/09 ]

Adding an evaluation here such that I don't forget again. Also setting target

The reason why JAXB standalone testcase works and why wsimport fails is the very
basic definition of episode files - JAXB ignores types specified in episode
files in it's processing. It doesn't have enough info to create a model from
them. However, wsimport is requesting this information - it requests Mapping
instance from model.get(QName) call. That includes Type and Annotation info.

One possibility to fix this would be to make a place in episode files to provide
such info. Better solution I think is this:

When wsimport requests information for a qname which is not found in the model,
jaxb would look up the episode file, find a corresponding classname; it will
load the class from classpath, read the annotation/type info using reflection
and return it back to jax-ws in mapping instance.

There's a risk in this however: we don't know yet what other information jax-ws
would require from the model, so this fix could be just a beginning and could
uncover more hidden issues. I'll check with Jitu/Rama about what info is
required in the model. Pavel will look into this for 2.2 release.

Comment by Martin Grebac [ 27/Oct/09 ]

This is not really a bug in JAXB, it's an enhancement, so updating the issue. We'll target this one for 2.2.1
as it requires larger changes than we expected. We made several enhancements, but it requires more work
since JAX-WS requires a lot more information to be present from the classes.

Comment by fribeiro [ 02/Nov/09 ]

Thanks for the update.

Comment by fribeiro [ 25/Jan/10 ]

Any update yet?

Comment by fribeiro [ 04/Oct/10 ]

Any update yet?

Comment by marcelcasado [ 24/Nov/11 ]

Any update ? Which version will be this available? Is there a work around? Thanks

Comment by cedric.vidal [ 08/Jun/12 ]

I'm also interested for an update on this.

Comment by RyanCarpenter [ 06/Mar/13 ]

I also appear to be running into this issue and would appreciate an update, if one is available. Thanks

Comment by Iaroslav Savytskyi [ 07/Mar/13 ]


To be honest now we have quite a lot of BUGs to be closed. But the light became visible in the end of the tunnel. So I hope I'll be able to start working with this in 1-2 months.


Comment by rcardillo [ 19/Jul/13 ]

Some people (myself included) have been waiting years for this. Any update on where this is going? I mean, we cannot really use episode files with wsimport effectively without this fix.

Can you at least provide a list of known workarounds that should be considered? I've been finding it difficult to workaround because in a project that uses episode files to make XML binding libraries, it's also really easy to get something generated that fails at runtime (e.g., multiple ObjectFactories that support the same element cause JAXBContext issues at runtime).

Comment by Michael Osipov [ 25/Feb/14 ]

Any update on this? I wasted an entire day to figure out that this is actually a bug!

Comment by jahutton [ 14/Mar/14 ]

Any update? without this fixed it kind of makes jaxws generation useless.

Comment by Michael Osipov [ 14/Mar/14 ]

I second jahutton's statement. Without decoupling the model from the SEI, it is impossible to support separation of concerns. Iaroslav Savytskyi, an entire year has passed without any progress. Please act!

Comment by bdrx [ 10/Nov/14 ]

Is this issue actually 'IN PROGRESS' meaning is someone actively working on this? Is there an estimated/target release for this? Is there any jaxb/xjc development happening period? What would one need to do to contribute to this project and/or get this moving?

Comment by Michael Osipov [ 10/Nov/14 ]

The status is just in pretense only. Nothing has changed for month.

Generated at Sun Apr 26 22:58:47 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.