Open glassfishrobot opened 16 years ago
Reported by ramapulavarthi
ramapulavarthi said: Created an attachment (id=254) testcase
ramapulavarthi said: Created an attachment (id=255) Updated testcase
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.
@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.
@pavelbucek said: marking as incomplete
@pavelbucek said: Closing as invalid. Feel free to reopen with additional info.
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.
ramapulavarthi said: Created an attachment (id=301) New testcase with the reopened issue.
@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">
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
fribeiro@java.net said: Any update yet?
@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).
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.
fribeiro@java.net said: Any update yet?
snajper said: Pavle, did you contact Rama/Jitu about this one?
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.
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.
fribeiro@java.net said: Thanks for the update.
fribeiro@java.net said: Any update yet?
fribeiro@java.net said: Any update yet?
marcelcasado said: Any update ? Which version will be this available? Is there a work around? Thanks
cedric.vidal said: I'm also interested for an update on this.
ryancarpenter said: I also appear to be running into this issue and would appreciate an update, if one is available. Thanks
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
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).
michael-o said: Any update on this? I wasted an entire day to figure out that this is actually a bug!
jahutton said: Any update? without this fixed it kind of makes jaxws generation useless.
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!
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?
michael-o said: The status is just in pretense only. Nothing has changed for month.
bdrx said: Any status on this 8 years later?
File: jaxb_episode.zip Attached By: ramapulavarthi
File: jaxb_episode.zip Attached By: ramapulavarthi
File: jaxb_episode.zip Attached By: ramapulavarthi
Was assigned to yaroska
This issue was imported from java.net JIRA JAXB-514
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.
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.
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]