It is a bit of a pain, but I do know that the newest version of Axis does have a castor deserializer/serializer ..I think. I just havent looked into it too much because the way that Axis is integrated into ColdFusion I can not just drop the latest version in there (another reason why I went with a different package for my attachments). But look into that. Another option is to write your own deserializer/serializer context impl. Most of the logic would be the same as the existing one except for the envelope dependencies. All you need to do is make sure that it extends the sax lexical handler i think..... I think you need to write a factory as well. I battled with that for a while so I don't remember it all (I try to forget the pain ;-) )
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 2:33 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: serializer.serialize() and org.xml.sax.Attributes More specifically, my JavaBean uses the BeanSerializer. It is dying on line 143 of BeanSerializer with a NullPointerException: 143> String encodingStyle = context.getMessageContext().getEncodingStyle (); Which would certainly imply that the serialization framework cannot be used outside of the context of a SOAP message and would concur with your findings. So, now I guess I go back to something like JiBX to (un)marshal my JavaBeans outside the context of a SOAP message, and bring the Axis jars along for the ride since the WSDL2Java sticks Axis metadata and serialization code at the bottom of JavaBeans. I suppose, however, that I'm going to have to put up with that if I want the deserialized JavaBean coming in from a SOAP request to be the same JavaBean that is passed as a parameter to a Local SessionBean interface. <sigh/> It just seems like a shame that the web service will use one type mapping facility, and then a different one has to be used externally. Cheers Steve Maring
