Issue Details (XML | Word | Printable)

Key: JAXB-514
Type: Improvement Improvement
Status: In Progress In Progress
Priority: Critical Critical
Assignee: Iaroslav Savytskyi
Reporter: ramapulavarthi
Votes: 20
Watchers: 11
Operations

If you were logged in you would be able to see more operations.
jaxb

passing episode file to xjc api creates incorrect Model

Created: 11/Jun/08 07:14 PM   Updated: 14/Mar/14 11:00 PM
Component/s: xjc
Affects Version/s: 2.1.7
Fix Version/s: not determined

Time Tracking:
Not Specified

File Attachments: 1. Zip Archive jaxb_episode.zip (4 kB) 20/Mar/09 05:32 PM - ramapulavarthi
2. Text File jaxb_episode.zip (3 kB) 11/Jun/08 07:25 PM - ramapulavarthi
3. Text File jaxb_episode.zip (4 kB) 11/Jun/08 07:15 PM - ramapulavarthi

Environment:

Operating System: All
Platform: All


Issuezilla Id: 514
Tags:
Participants: cedric.vidal, euxx, fribeiro, Iaroslav Savytskyi, jahutton, marcelcasado, Martin Grebac, Michael Osipov, Pavel Bucek, ramapulavarthi, rcardillo and RyanCarpenter


 Description  « Hide

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



ramapulavarthi added a comment - 11/Jun/08 07:15 PM

Created an attachment (id=254)
testcase


ramapulavarthi added a comment - 11/Jun/08 07:25 PM

Created an attachment (id=255)
Updated testcase


ramapulavarthi added a comment - 08/Jan/09 12:06 PM

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


Pavel Bucek added a comment - 16/Jan/09 05:32 AM

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("/Users/pavel/jaxb/bugs/514/tryout2/b.xsd");
InputSource episode = new
InputSource("/Users/pavel/jaxb/bugs/514/tryout2/a.episode");

sc.parseSchema(file);
sc.getOptions().addBindFile(episode);
// 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);
jcm.build(sc.getOptions().createCodeWriter());

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.


Pavel Bucek added a comment - 04/Mar/09 05:05 AM

marking as incomplete


Pavel Bucek added a comment - 19/Mar/09 07:09 AM

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


ramapulavarthi added a comment - 20/Mar/09 05:31 PM

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.


ramapulavarthi added a comment - 20/Mar/09 05:32 PM

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


Pavel Bucek added a comment - 24/Mar/09 04:44 AM

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

BUILD FAILED
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">


ramapulavarthi added a comment - 24/Mar/09 09:09 AM

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
hello.xsd


fribeiro added a comment - 14/Apr/09 05:31 PM

Any update yet?


Pavel Bucek added a comment - 16/Apr/09 01:13 AM

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).


euxx added a comment - 12/May/09 09:07 AM

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.


fribeiro added a comment - 08/Sep/09 07:45 PM

Any update yet?


Martin Grebac added a comment - 11/Sep/09 01:50 AM

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


Martin Grebac added a comment - 17/Sep/09 09:01 AM

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

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.


Martin Grebac added a comment - 27/Oct/09 08:25 AM

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.


fribeiro added a comment - 02/Nov/09 07:54 PM

Thanks for the update.


fribeiro added a comment - 25/Jan/10 05:41 AM

Any update yet?


fribeiro added a comment - 04/Oct/10 12:59 PM

Any update yet?


marcelcasado added a comment - 24/Nov/11 02:09 AM

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


cedric.vidal added a comment - 08/Jun/12 09:34 AM

I'm also interested for an update on this.


RyanCarpenter added a comment - 06/Mar/13 08:55 PM

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


Iaroslav Savytskyi added a comment - 07/Mar/13 01:13 PM

Hi,

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.

Iaroslav


rcardillo added a comment - 19/Jul/13 02:35 PM

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).


Michael Osipov added a comment - 25/Feb/14 09:34 PM

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


jahutton added a comment - 14/Mar/14 02:36 PM

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


Michael Osipov added a comment - 14/Mar/14 11:00 PM

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!