Hi,
why are you calling XMLContext.addPackage() at all. Castor XML is
perfectly capable to use classes as generated with the XML source
generator (from your XML schema) as long as ....
a) those classes (POJOs as well as descriptor classes) are available on
the classpath.
b) the .castor.cdr files are available as well.
Can you please try this again, making sure that conditions a) and b) are
met.
Regards
Werner
enterpriseseven wrote:
> I have a test app that creates an instace of the message, marshalls it and
> then unmarshalls it. That works fine. The Marshalling process seems to add
> something to the environment...maybe a class loader...that allows
> unmarshalling to work. However, the live code I use to unmarshall messages
> received via OpenMQ only does an unmarshall step. I have tested my test app
> without the marshalling process and the unmarshalling fails. The following
> is my unmarshal code in my live code:
>
> public Serializable unmarshall(String xmlString)
> {
> StringReader reader = new StringReader(xmlString);
> Object unmarshalledObject = null;
> try {
> unmarshalledObject = unmarshaller.unmarshal(reader);
> } catch (MarshalException ex) {
> ex.printStackTrace();
> } catch (ValidationException ex) {
> ex.printStackTrace();
> }
> if(unmarshalledObject instanceof Serializable)
> {
> return (Serializable)unmarshalledObject;
> }
> else
> {
> return null;
> }
> }
>
> The "xmlString" variable is retrieved from the payload (text field) of a
> TextMessage that was sent via OpenMQ. The unmarshall function above lives
> in a "JMessenger" class that I have written and the initialization code is
> as follows:
>
> xmlCtx = new XMLContext();
> try {
> xmlCtx.addPackage(MESSAGES_NAMESPACE);
>
> } catch (ResolverException ex) {
> System.out.println(ex);
> }
> marshaller = xmlCtx.createMarshaller();
> marshaller.setSuppressNamespaces(true);
> unmarshaller = xmlCtx.createUnmarshaller();
>
> xmlCtx is a org.exolab.castor.xml.XMLContext
> MESSAGES_NAMESPACE = "com.lmco.dogpatch.messaging.messages"
>
> Thanks,
> Mike
>
>
>
> Werner Guttmann-6 wrote:
>> That should work our of the box. What does your code look like that you
>> use to actually unmarshal your XML document instance ?
>>
>> Regards
>> Werner
>>
>> enterpriseseven wrote:
>>> Hey,
>>> - I am using Castor 1.3
>>> - Schema is as follows:
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
>>> <xsd:element name="FindFileRequestMessage">
>>> <xsd:complexType>
>>> <xsd:sequence>
>>> <xsd:element name="fileID" type="xsd:long"/>
>>> </xsd:sequence>
>>> </xsd:complexType>
>>> </xsd:element>
>>> </xsd:schema>
>>>
>>> Thanks,
>>> Mike
>>>
>>>
>>>
>>> Werner Guttmann wrote:
>>>> Hi,
>>>>
>>>> you should not have to alter the .castor.cdr files at all after source
>>>> generation.
>>>>
>>>> A few general questions:
>>>>
>>>> - What version of Castor are you using ?
>>>> - What does the XML schema fragment look like for these XML artefacts ?
>>>>
>>>> Regards
>>>> Werner
>>>>
>>>> enterpriseseven wrote:
>>>>> I am trying to unmarshal this:
>>>>>
>>>>> <FindFileRequestMessage>
>>>>> <fileID>12</fileID>
>>>>> </FindFileRequestMessage>
>>>>>
>>>>> The CDR file has this mapping:
>>>>>
>>>>> com.lmco.dogpatch.messaging.messages.FindFileRequestMessage=com.lmco.dogpatch.messaging.messages.descriptors.FindFileRequestMessageDescriptor
>>>>>
>>>>> When I unmarshal I get "FindFileRequestMessage" not found. But, if I
>>>>> change
>>>>> the CDR mapping to this:
>>>>>
>>>>> FindFileRequestMessage=com.lmco.dogpatch.messaging.messages.descriptors.FindFileRequestMessageDescriptor
>>>>>
>>>>> Then it unmarshalls perfectly (removed package name on the left). But,
>>>>> I
>>>>> have to hack the CDR file to do this. Is there a way to get the
>>>>> SourceGenerator to do this for me? Or am I doing it wrong?
>>>>>
>>>>> Thanks,
>>>>> Mike
>>>> ---------------------------------------------------------------------
>>>> 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
