Hi again, Jayaraman, Kannan wrote: > Werner, > Thanks for your response, I agree, however, it is the API (after the > fact that those descriptors are generated either ways, using a mapping > or a binding file), which I have questions on. The comments you have > given below (for binding file to switch over to the API's similar for > the mapping ones, I get runtime errors (as below), ...
Which I would expect, as you have to make a difference between domain classes for which you define a mapping and domain classes for which there exists a descriptor class (as a result of code generation). Let's step back a bit, and have a look at this in more detail. Castor internally (sic!) uses descriptor classes to define the binding between a java domain object and its XML binding. Now where does Castor obtain descriptor classes from ) a) class mapping from a mapping file. Each class mapping defined in a mapping file is internally converted to a class descriptor. b) From the class loader (as it loads class descriptors as generated during code generation). c) Introspection. What does this imply to you ? You have to configure Castor (e.g. through XMLContext with castor 1.2) to let Castor know where to find those descriptors required. Does this make sense ? Werner > as there are no > mapping files created, in case if I use the binding.xml's.) > Thanks > Kannan > > > Exception in thread "main" java.lang.NullPointerException > at > org.exolab.castor.mapping.Mapping.loadMapping(Mapping.java:279) > at > org.exolab.castor.mapping.Mapping.loadMapping(Mapping.java:262) > at > com.citi.test.CastorTest.unMarshallXMLToCastorUsingMapping(CastorTest.ja > va:160) > at > com.citi.test.CastorTest.getCreditBureauData(CastorTest.java:86) > at com.citi.test.CastorTest.main(CastorTest.java:47) > > > -----Original Message----- > From: Werner Guttmann [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 22, 2008 3:28 PM > To: dev@castor.codehaus.org > Cc: [EMAIL PROTECTED] > Subject: Re: [castor-dev] Common way to unmarshall using mapping and > binding files > > Hi, > > just to add a bit more clarity before trying to address your question. > When you use the Castor XML code generator to generate Java source files > from an XML schema, you'll see that an additional set of classes will be > generated, i.e. the descriptor classes. It's those files that completely > replace a mapping file during XML data binding. > > So for the remainder of this, let's use the term 'descriptor classes': > > > > Jayaraman, Kannan wrote: >> >> Is there a common way to marshall and unmarshall (Java to XML and >> vice-versa), using either binding or mapping files created with Castor >> source generator. I've it working using the following 2 different > API >> calls (one for binding vs another for mapping)), but I'm looking to >> have one single way independent of whether it used binding or mapping >> files to generate the Castor source java files. We are using Castor v > >> 1.0.5, but also invite your inputs to any version which has such a > feature. >> >> Thanks >> Kannan >> >> >> Using binding files: >> Response.unmarshal(new StringReader(inputStr)) > It's not that you have to use this method for unmarshalling. Why not > switch to the same method as highlighted below for the mapping ? You can > even turn off generation of the marshalling methods completely. >> >> >> Using mapping files: >> >> MappingLoader mappingLoader = >> mappingUnmarshaller.getMappingLoader(mapping, BindingType.XML); >> >> classDescriptorResolver.setMappingLoader(mappingLoader); >> >> Unmarshaller unmar = new Unmarshaller(response); >> >> unmar.setResolver((XMLClassDescriptorResolver)classDescriptorResolver) >> ; >> >> unmar.setWhitespacePreserve(true); >> >> unmar.setIgnoreExtraElements(true); >> >> retObj = (Object) unmar.unmarshal((Element) payload); >> >> >> >> > > > --------------------------------------------------------------------- > 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 > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
