Okay. Just wanted to make sure that we are talking about a work-around
here for something that should behave in a different way.
Werner
Porter, Doug wrote:
Unfortunately Sybase EAServer has a history of strange workarounds being
required to get around classloader type issues.
Doug
-----Original Message-----
From: Werner Guttmann [mailto:[EMAIL PROTECTED]
Sent: Friday, August 31, 2007 2:50 AM
To: [email protected]
Subject: Re: [castor-user] NullPointerException when Marshalling from
inside Application Server
Glad to see that you've got it working. Though I have to say that I
consider the approach taken to be ... well, odd at least.
Werner
Porter, Doug wrote:
I was able to find a resolution to this yesterdaty. I moved the Castor jars
(including my generated classes) into the java/classes folder within EAServer
and explicitly referenced them as part of the application server's
bootclasspath and it started working correctly.
Thanks
Doug
-----Original Message-----
From: Werner Guttmann [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 29, 2007 2:42 PM
To: [email protected]
Subject: Re: [castor-user] NullPointerException when Marshalling from
inside Application Server
Doug,
Can you please file a new Jira issue, and attach all relevant
information to the Jira issue created.
Werner
Porter, Doug wrote:
Using castor 1.1.2.1 I am attempting to marshal an object generated via the
code generator to XML. If I do this withing my IDE it works fine. After
deploying this to our application server (Sybase EAServer 5.3 using Java
1.5.0_09) the same code fails with a NullPointerException. The following stack
trace is generated:
java.lang.NullPointerException
at
org.exolab.castor.xml.util.XMLClassDescriptorResolverImpl$DescriptorCache.loadMapping(XMLClassDescriptorResolverImpl.java:1032)
at
org.exolab.castor.xml.util.XMLClassDescriptorResolverImpl$DescriptorCache.loadPackageMapping(XMLClassDescriptorResolverImpl.java:942)
at
org.exolab.castor.xml.util.XMLClassDescriptorResolverImpl.getDescriptor(XMLClassDescriptorResolverImpl.java:505)
at
org.exolab.castor.xml.util.XMLClassDescriptorResolverImpl.resolve(XMLClassDescriptorResolverImpl.java:171)
at org.exolab.castor.xml.Validator.validate(Validator.java:111)
at org.exolab.castor.xml.Marshaller.validate(Marshaller.java:2527)
at org.exolab.castor.xml.Marshaller.marshal(Marshaller.java:824)
at org.exolab.castor.xml.Marshaller.marshal(Marshaller.java:730)
at com.dac.castorbindings.stp.REQUESTS.marshal(REQUESTS.java:67)
The REQUESTS object is the one I generated using the code generator. It appears that inside the XMLClassDescriptorResolverImpl class the getClassLoader method is returning null, but I am not sure why. This technique worked correctly under castor 0.9.5.3 we are just finally getting around to upgrading.
Correctly marshalled output would look like this:
<?xml version="1.0" encoding="UTF-8"?>
<REQUESTS ActionCode="R">
<ADD>
<REQUEST_TRANSACTIONS PlanID="CAD0000000001"
EmployerIdentificationNumber="12345">
<TRANSACTIONS>
<TRANSACTION PlanID="CAD0000000001"
TransEffectiveDate="2005-01-08">
<TRANSACTION_GENERAL_INFO>
<PlanID>CAD0000000001</PlanID>
<YearEndDate>2005-12-31</YearEndDate>
<ConfirmRequiredCode tc="N" />
<ProcessEligEntrCode tc="Y" />
<ProcessEligCompCode tc="Y" />
<ProcessEligHCECode tc="N" />
<TransEffectiveDate>2005-01-08</TransEffectiveDate>
<TransTypeCode tc="13" />
<PostAllDivisionsCode tc="Y" />
</TRANSACTION_GENERAL_INFO>
</TRANSACTION>
</TRANSACTIONS>
</REQUEST_TRANSACTIONS>
</ADD>
</REQUESTS>
Any ideas?
Thanks,
Doug
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
