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
