javaee / jaxb-v2

Other
211 stars 99 forks source link

passing episode file to xjc api creates incorrect Model #514

Open glassfishrobot opened 16 years ago

glassfishrobot commented 16 years ago

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

Environment

Operating System: All Platform: All

Affected Versions

[2.1.7]

glassfishrobot commented 16 years ago

Reported by ramapulavarthi

glassfishrobot commented 16 years ago

ramapulavarthi said: Created an attachment (id=254) testcase

glassfishrobot commented 16 years ago

ramapulavarthi said: Created an attachment (id=255) Updated testcase

glassfishrobot commented 15 years ago

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

glassfishrobot commented 15 years ago

@pavelbucek said: 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.

glassfishrobot commented 15 years ago

@pavelbucek said: marking as incomplete

glassfishrobot commented 15 years ago

@pavelbucek said: Closing as invalid. Feel free to reopen with additional info.

glassfishrobot commented 15 years ago

ramapulavarthi said: 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.

glassfishrobot commented 15 years ago

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

glassfishrobot commented 15 years ago

@pavelbucek said: 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">

glassfishrobot commented 15 years ago

ramapulavarthi said: 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

glassfishrobot commented 15 years ago

fribeiro@java.net said: Any update yet?

glassfishrobot commented 15 years ago

@pavelbucek said: 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).

glassfishrobot commented 15 years ago

euxx@java.net said: 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.

glassfishrobot commented 15 years ago

fribeiro@java.net said: Any update yet?

glassfishrobot commented 15 years ago

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

glassfishrobot commented 15 years ago

snajper said: 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.

glassfishrobot commented 15 years ago

snajper said: 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.

glassfishrobot commented 15 years ago

fribeiro@java.net said: Thanks for the update.

glassfishrobot commented 14 years ago

fribeiro@java.net said: Any update yet?

glassfishrobot commented 14 years ago

fribeiro@java.net said: Any update yet?

glassfishrobot commented 12 years ago

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

glassfishrobot commented 12 years ago

cedric.vidal said: I'm also interested for an update on this.

glassfishrobot commented 11 years ago

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

glassfishrobot commented 11 years ago

yaroska said: 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

glassfishrobot commented 11 years ago

rcardillo said: 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).

glassfishrobot commented 10 years ago

michael-o said: Any update on this? I wasted an entire day to figure out that this is actually a bug!

glassfishrobot commented 10 years ago

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

glassfishrobot commented 10 years ago

michael-o said: 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!

glassfishrobot commented 9 years ago

bdrx said: 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?

glassfishrobot commented 9 years ago

michael-o said: The status is just in pretense only. Nothing has changed for month.

glassfishrobot commented 7 years ago

bdrx said: Any status on this 8 years later?

glassfishrobot commented 15 years ago

File: jaxb_episode.zip Attached By: ramapulavarthi

glassfishrobot commented 16 years ago

File: jaxb_episode.zip Attached By: ramapulavarthi

glassfishrobot commented 16 years ago

File: jaxb_episode.zip Attached By: ramapulavarthi

glassfishrobot commented 16 years ago

Was assigned to yaroska

glassfishrobot commented 7 years ago

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

Naht commented 7 years ago

Any updates on this? Affects not only wsimport but also apache cxf wsdl2java. This issue is 9 years old, any WA would be good at this point.

bertramn commented 6 years ago

For anyone who is looking for an answer to this one, the exact cause about this issue is discussed here and at least for CXF codegen we are trying to develop a fix (despite being ugly) under CXF-7289. TLDR; XJC compiler does not have an interface to extract ALL known binding types (including ones that are imported from episodes). We really need a patch for XJC to a) collect the episodes mappings and b) make it available via a method of the com.sun.tools.xjc.api.S2JJAXBModel and com.sun.tools.xjc.model.Model interface.