Very much so!! /Christian Bj�rnbak
On Thursday 17 October 2002 16:14, [EMAIL PROTECTED] wrote: > Vincent wrote: > >> I also agree with you it would be really nice if > >> org.exolab.castor.builder.nspackages property worked at runtime. > > I have implemented this functionality on my own copy of castor. > However, we keep the namespace/package mapping in a classpath > loaded xml file instead of the Castor's Java system property. > We load the mapping at system start up. > > If people are interested, I could post this to the group. > > > -----Original Message----- > > From: Figari, Vincent [mailto:vincent.figari@;sap.com] > > Sent: Thursday, October 17, 2002 7:53 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [castor-dev] SourceGenerator on multiple namespaces > > > > > > Hi Christian, > > > > I believe Castor instantiates AnyNode after failing to derive > > a proper class name from the mapping file (if any) or from the > > ClassDescriptor resolver. It also looks like the mapping file > > is an "all or nothing" strategy so I have not been digging > > much farther in that direction (although there might be tricks > > I am not aware of). > > > > I also agree with you it would be really nice if > > org.exolab.castor.builder.nspackages property worked at runtime. > > > > So currently I provide the unmarshaller with a custom > > CD resolver > > which extends > > org.exolab.castor.xml.util.ClassDescriptorResolverImpl > > The method I override is: > > public XMLClassDescriptor resolve(String className, > > ClassLoader loader); > > Basically, if the className is not a soap class, I instantiate > > the classDescriptor corresponding to the className with a > > Class.forName(), hard-coding the package name from where to get > > the classDescriptor definition, and return it. > > > > The custom CD resolver is also a useful approach for extending > > the castor-generated classes and still loading the > > generated descriptors. > > > > Hope this helps, > > > > Vincent > > > > > > -----Original Message----- > > From: Christian Bj�rnbak [mailto:cb@;touristonline.dk] > > Sent: Thursday, October 17, 2002 2:27 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [castor-dev] SourceGenerator on multiple namespaces > > > > > > Hi Vincent > > > > I have now succesfully generated the classes, thanks.. > > > > When I do Unmarshaller.unmarshal I now get Envelope > > object containing a Body > > element and a Header object within these the ebXML > > objects are substituted > > with AnyNode objects. > > > > So on to the next problems. You say there are 3 ways to > > solve the mapping. > > > > 1) Map all the namespaces to the same java package.. > > Not nice since a have > > > 100 classes - very messy... > > > > 2) Write a ClassDescriptor Resolver. Is there anywhere > > I can find an example > > implementation af a ClassDescriptor resolver?? > > > > 3) If I do the mapping file do I have to do a complete > > mapping or only a > > partial mapping around the namespace changes (from > > envelope.xsd to > > msg-header...xsd)? > > > > Note to the castor developers: This would be much > > easier if the > > org.exolab.castor.builder.nspackages property also > > worked runtime... > > > > /Christian Bj�rnbak > > > > On Thursday 17 October 2002 09:30, Figari, Vincent wrote: > > > Hi Christian, > > > > > > About your questions: > > > > > > 1) I use the "type" generation option with the same > > > > soap xsd file > > > > > that you are using and have no problem. I guess the > > > > default "element" > > > > > generation is not adequate for this kind of xsd. > > > > > > 2) Personally I instantiate a Unmarshaller object and > > > > feed it with > > > > > the FileReader. This looks a more flexible approach, > > > > specially for > > > > > setting-up the Unmarsahller with your own > > > > ClassDescriptor resolver. > > > > > 3) If you use a mapping file, you can explicitly map > > > > the xml names > > > > > unmarshalled from under the soap <body> to your Java > > > > class names. > > > > > If you do not use one, Castor will attempt to derive a default > > > class name from the xml name, and find the class in > > > > the same package > > > > > as the generated soap Body class. This is where the > > > > custom ClassDescriptor > > > > > mentioned above is a very convenient way of helping > > > > Castor to locate > > > > > the classes among different packages. > > > > > > Finally there seems to be a name space problem when > > > marshalling a soap message (cf > > > > http://www.mail-archive.com/castor-dev@;exolab.org/msg095 > > 62.html ). I hope > > > > > to hear from Arnaud on this one, I am still a bit new > > > > to Castor source code > > > > > to investigate it myself ;-) > > > > > > Hope this helps, > > > > > > Vincent > > > > > > > > > > > > -----Original Message----- > > > From: Christian Bj�rnbak [mailto:cb@;touristonline.dk] > > > Sent: Thursday, October 17, 2002 8:39 AM > > > To: [EMAIL PROTECTED] > > > Subject: [castor-dev] SourceGenerator on multiple namespaces > > > > > > > > > This is a confirmation of an earlier question > > > > including two questions. > > > > > First some background: > > > > > > I'm trying to convert an ebXML message which is > > > > contained in a SOAP message > > > > > into Java using castor. > > > > > > An ebXML message instance looks like: > > > > > > <?xml version="1.0" encoding="utf-8"?> > > > <SOAP-ENV:Envelope > > > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" > > > xmlns:eb="http://www.ebxml.org/namespaces/messageHeader" > > > xmlns:xlink="http://www.w3.org/1999/xlink"> > > > <SOAP-ENV:Header> > > > <eb:MessageHeader SOAP-ENV:actor="1" version="1.0"> > > > <eb:From> > > > > <eb:PartyId>mailto:queryresponse@;companyb.com</eb:PartyId> > > > > > </eb:From> > > > <eb:To> > > > > <eb:PartyId>mailto:query@;companya.com</eb:PartyId> > > > > > </eb:To> > > > <eb:CPAId>NULL</eb:CPAId> > > > > <eb:ConversationId>[EMAIL PROTECTED]</eb:Co > > nversationId> > > > > > <eb:Service > > > > eb:type="OTA">HotelBooking</eb:Service> > > > > > <eb:Action>OTA_HotelAvailNotifRQ</eb:Action> > > > <eb:MessageData> > > > > <eb:MessageId>[EMAIL PROTECTED]</eb: > > MessageId> > > > > <eb:Timestamp>2001-07-20T9:31:12Z</eb:Timestamp> > > > > > </eb:MessageData> > > > <eb:QualityOfServiceInfo > > > > eb:deliverySematics="BestEffort"/> > > > > > </eb:MessageHeader> > > > </SOAP-ENV:Header> > > > <SOAP-ENV:Body> > > > <eb:Manifest> > > > <eb:Reference > > > > xlink:href="cid:transfer1@;companya.com" > > > > > xlink:type="simple"> > > > <eb:Description>Hotel Availability > > > > Notification > > > > > Request</eb:Description> > > > </eb:Reference> > > > </eb:Manifest> > > > </SOAP-ENV:Body> > > > </SOAP-ENV:Envelope> > > > > > > Here it's the <SOAP-ENV:Envelope> which is the root, > > > > but in the schemas it > > > > > the ebXML schema which imports the rest. > > > > > > The top of the ebXML schema looks like this: > > > > > > <schema > > > > targetNamespace="http://www.oasis-open.org/committees/eb > > xml-msg/schema/msg- > > > > >header-2_0.xsd" > > > > xmlns:xml="http://www.w3.org/XML/1998/namespace" > > > > xmlns:tns="http://www.oasis-open.org/committees/ebxml-ms > > g/schema/msg-header > > > > >-2_0.xsd" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" > > > xmlns:xlink="http://www.w3.org/1999/xlink" > > > xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" > > > xmlns="http://www.w3.org/2001/XMLSchema" > > > > elementFormDefault="qualified" > > > > > attributeFormDefault="qualified" version="2.0"> > > > <import namespace="http://www.w3.org/2000/09/xmldsig#" > > > > schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsi > > g-core-schema.xsd"> > > > > ></import> <import namespace="http://www.w3.org/1999/xlink" > > > > schemaLocation="http://www.oasis-open.org/committees/ebx > > ml-msg/schema/xlink > > > > >.xsd"></import> <import > > > namespace="http://schemas.xmlsoap.org/soap/envelope/" > > > > schemaLocation="http://www.oasis-open.org/committees/ebx > > ml-msg/schema/envel > > > > >ope.xsd"></import> <import > > > > namespace="http://www.w3.org/XML/1998/namespace" > > > > > schemaLocation="http://www.w3.org/2001/03/xml.xsd"></import> > > > > > > I've added the following namespace mapping into > > > > castorbuilder.properties: > > > org.exolab.castor.builder.nspackages=\ > > > > http://www.oasis-open.org/committees/ebxml-msg/schema/ms > > g-header-2_0.xsd=to > > >.integration.ebxml.message,\ > > http://www.w3.org/2000/09/xmldsig#=to.integration.ebxml.message.xmldsig, > \ > > > http://www.w3.org/1999/xlink=to.integration.ebxml.message.xlink,\ > > http://schemas.xmlsoap.org/soap/envelope/=to.integration.ebxml.message.e > nve > > >lope,\ > > http://www.w3.org/XML/1998/namespace=to.integration.ebxml.message.xml > > > Now to the questions: > > > > 1) When I generate the classes for the SOAP envelope schema (which is > > attached) the SourceGenerator first generates a non-abstract class and > > then > > > asks to overwrite it with an abstract class... What's going on?? > > > > 2) When I want to unmarshal the ebXML message I do a > > to.integration.ebxml.message.envelope.Envelope envelope = > > to.integration.ebxml.message.envelope.Envelope.unmarshal(new > > FileReader(file)); - Right? > > > > 3) In the SOAP Envelope schema the schema type "any" are used > > everywhere > > > ebXML tags should be inserted. How does castor know where to find the > > ebXML > > > classes when unmarshalling e.g. SOAP Header element??? > > > > /Christian Bj�rnbak > > > > ----------------------------------------------------------- > > If you wish to unsubscribe from this mailing, send mail to > > [EMAIL PROTECTED] with a subject of: > > unsubscribe castor-dev > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
