here's a curious cat.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:Erik.Ostermueller@;alltel.com]
> Sent: Thursday, October 17, 2002 4:14 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [castor-dev] SourceGenerator on multiple namespaces
>
>
>
> 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.messag
> e.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
