Agreed ... but consider situations (posted by several users on this
list - and encountered by me) where you want to pass Java Object around
but are limited by the Java<>XML serialization support. I find the
existing serialization support to go only as far as the simple types.
I think my approach can lead to a more general purpose
(de)serialization mechanism - based on the existing Java Serializable
framework. I am curious if it has been thought of before and rejected
for some reason.
JavaObjectBase64Serializer
JavaObjectBase64SerializerFactory
JavaObjectBase64Deserializer
JavaObjectBase64DeserializerFactory
Regards...
Milind Gadre
VP Product Development
ecPlatforms, Inc
901 Mariner's Island Blvd, Suite 565
San Mateo, CA 94404
C: 510.919.0596
E: [EMAIL PROTECTED]
----- Original Message -----
From: "Paul Andrews" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "'Milind Gadre'"
<[EMAIL PROTECTED]>
Sent: Monday, March 10, 2003 2:11 PM
Subject: RE: Simple little trick for easing (de)serialization issues
> Which will only work if both ends are using Java *and* you have
access
> to the same classes.
>
> > -----Original Message-----
> > From: Milind Gadre [mailto:[EMAIL PROTECTED]
> > Sent: Monday, March 10, 2003 4:20 PM
> > To: [EMAIL PROTECTED]
> > Subject: Simple little trick for easing (de)serialization issues
> >
> >
> >
> > Bill, here is a quick fix to your problem.
> >
> > 1. Perform a JAVA Object Serialization of your Object(s) into a
> > ByteArrayOutputStream wrapped in a ObjectOutputStream.
> > Remember to have
> > your objects implement java.io.Serializable.
> > 2. Base64.encode the resulting byte[]
> > 3. Send that String to the end-point.
> > 4. At the end-point, Base64.decode the String into a byte[], and
> > perform a JAVA Object Deserialization.
> > 5. Do the same for the returned JAVA object.
> >
> > The biggest advantages of this little trick are
> >
> > 1. No need to define and configure custom (de)serializers
> > 2. Simplified API.
> >
> > Potential downside - handling large objects and attachments.
> >
> > Hope this helps - comments/flames from Axis experts welcome.
> >
> > Regards...
> >
> > Milind Gadre
> > VP Product Development
> > ecPlatforms, Inc
> > 901 Mariner's Island Blvd, Suite 565
> > San Mateo, CA 94404
> > C: 510.919.0596
> > E: [EMAIL PROTECTED]
> >
> > ----- Original Message -----
> > From: "Bill Pfeiffer" <[EMAIL PROTECTED]>
> > To: "Axis-User" <[EMAIL PROTECTED]>
> > Sent: Monday, March 10, 2003 1:12 PM
> > Subject: Help on ArrayList, java.sql.Date classes
> >
> >
> > > I've posted previously on this just a short while ago, but was
> > wondering if
> > > someone could help me a bit further.
> > >
> > > I need serializers/des for ArrayList, and java.sql.Date. I'm
fine
> > with them
> > > going to normal SOAP array and SOAP date.
> > >
> > > If someone has already written and successfully tested, could you
> > post code?
> > >
> > > If not, is there a getting started on writing these things? The
> > example
> > > referenced in the docs seems pretty inadequate for what I
> > want to do.
> > >
> > > Background:
> > >
> > > What I am trying to do is expose some large grained
> > SessionBean calls
> > that
> > > pass a data object model around. The model is composed of java
beans
> > > containing other java beans as well as collections of
> > javabeans. The
> > java
> > > beans work fine, the collections and the java.sql.Dates choke on
the
> > WSDL
> > > generation.
> > >
> > > I have successfully deployed the service and called with my
custom
> > coded
> > > client that has access to my data model. I now want to use the
WSDL
> > to
> > > generate the java to make the call. This is where the
> > collections/sql Dates
> > > are tripping me up.
> > >
> > > Thanks for any pointers here.
> > >
> > > Bill Pfeiffer
> > >
> > >
> > >
> >
> >
>
>
>
