Nick, if all classes generated from the XML schema happen to live within the same package, Castor should be able to deal with this. As already said, please feel free to create a Jira issue.
Regards Werner Nick Pilch wrote: > Thanks for your reply. I'll play around a bit more. Something that I > probably should have mentioned is that the XML files I have to support > are quite old and don't have any namespace attributes in them. This is > probably why castor can't find castor-generated classes that live in a > particular package. I stepped through the castor sources a bit with a > symbolic debugger, and this seemed to be the case. > > I may be able be able to tell users that they at least have to modify > their XML files to introduce the namespace attribute. > > At 10:35 AM +0100 1/28/07, Werner Guttmann wrote: >> Hi, >> >> I am actually a bit surprised to see that this is not working. Can you >> please create a new issue at http://jira.codehaus.org/browse/CASTOR, and >> attach all relevant files, incl. the XML schema, a test case that >> triggers unmarshalling and two or three sample XML documents. >> >> Having said that, there's one option you migth want to consider. With a >> binding file, it is possible to specify that e.g. particular classes >> that will be generated by the XML code generator will either implement a >> custom interface and/or extend a custom root class. This way, you could >> call the (non-static) >> >> Unmarshaller.unmarshal(Class, Reader) >> >> method, and get yourself working without having to wait for a reply. >> >> Regards >> Werner >> >> Nick Pilch wrote: >>> Hi. I've generated code from a schema and I want to unmarshal. I >>> want to >>> use Unmarshaller.unmarshal(Reader) because the schema does not have >>> just >>> one top level element. I might encounter several different top level >>> elements in the XML files I want to unmarshal. >>> >>> However, when I try this, castor says "The class for the root element >>> 'blahblah' could not be found." Using a mapping file works, but then >>> I'd have to maintain 2 representations of the same data (the generated >>> code and the mapping file). It also works to specify the top-level >>> element using unmarshal(Class, Reader), but only if I know the >>> top-level >>> element ahead of time - but I won't. >>> >>> I've tried using the org.exolab.castor.builder.nspackages property, but >>> this doesn't help and it seems to be for another purpose, anyway. >>> >>> I have to support existing XML files out there, so it's not an >>> option to >>> require the same top-level element in the XML files. >>> >>> Thanks much in advance for any help. >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list please visit: >> >> http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
