Hi Christian, Vincent, Daan, Erik and castor fans, Here is some update on the problem reported concerning namespace: Castor wasn't able to find the correct ClassDescriptor when marshalling and we also faced a namespace setting problem in the generated descriptors. The <any> support has been modified slightly to reflect the namespace information as well as the particle information:
- Though the support for namespace in wildcard is quite limited, Castor is now outputting the correct information and can validate this information only if the <any> declaration contains only one declared namespace. I mean that validation is not provided for: <any namespace="##other|list of URIs"/> - If maxOccurs is set to one, an <any> will be reflected by an object in the generated classes and not anymore by a collection. Collections are used only if maxOccurs > 1 - Concerning the namespace - package mapping, the binding file will provide a deeper support by allowing to declare a mapping for a java package based on the targetNamespace schema or the schemaLocation information. Since the binding file support an 'include' mechanism, it will be possible to separate all package mapping declarations from the actual binding information. So roughly speaking, you can update the CVS, re-run the SourceGenerator and your examples and yell at me if the problem is not fixed...the next step is to wait for the binding file ;+), Thanks, Arnaud > -----Original Message----- > From: Christian Bj�rnbak [mailto:cb@;touristonline.dk] > Sent: Friday, October 18, 2002 9:03 AM > To: [EMAIL PROTECTED] > Subject: Re: [castor-dev] SourceGenerator on multiple namespaces > > 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.xmld > sig, > > \ > > > > > > http://www.w3.org/1999/xlink=to.integration.ebxml.message.xlink,\ > > > > > http://schemas.xmlsoap.org/soap/envelope/=to.integration.ebxml.messa > ge.e > > nve > > > > >lope,\ > > > > > http://www.w3.org/XML/1998/namespace=to.integration.ebxml.message.xm > l > > > > > 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 ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
