axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Pfeiffer" <wspli...@tampabay.rr.com>
Subject Re: Simple little trick for easing (de)serialization issues
Date Tue, 11 Mar 2003 03:43:11 GMT
RE: Simple little trick for easing (de)serialization issuesI can write a client program that
calls the web service just fine following the examples in the user guide as a template but
using my object model.  Yes, the Date and ArrayList items work fine there.  The problem is
that the WSDL that gets generated fails on the Wsdl2Java task because the ArrayList and Date
are not defined in the WSDL generated.  

Is this just a bug in the WSDL generator?  I need to send the WSDL to one of our business
partners and have them call my services.  I can't dictate their choice of web service calling
mechanism so I need to WSDL to be correct.  

After restating the problem, it sounds like more of a WSDL generation issue than ser/deser
problem.  I think I saw someone post a similar problem after 1.1 RC1 came out.

Ideas?  


Bill
  ----- Original Message ----- 
  From: Anecito, Anthony (HQP) 
  To: 'Bill Pfeiffer' ; axis-user@ws.apache.org 
  Sent: Monday, March 10, 2003 6:30 PM
  Subject: RE: Simple little trick for easing (de)serialization issues


  Hi Bill, 

  Sorry to step in but why are you writing serializers/deserializers? I am using Axis and
have no problems with java.sql.Date and java.util.Vector on the server side. I was passing
strings/dates/vector in a java bean type class. My issue was the client side where I wanted
a light client and ran the risk of writing my own serializer/deserializer. So far for my application
WingFoot library for j2se solved my issue. But if you can use the Axis beanserializer on the
server side I certainly would use it.

  Hope I was of some help. Hate to see others suffer some pain like I did. 

  -Tony 

  -----Original Message----- 
  From: Bill Pfeiffer [mailto:wsplist1@tampabay.rr.com] 
  Sent: Monday, March 10, 2003 3:22 PM 
  To: axis-user@ws.apache.org 
  Subject: Re: Simple little trick for easing (de)serialization issues 



  Steve, 

  I have bought into the interop thing because there's an extremely good 
  chance that my future clients (Insurance inducstry) will be using .NET and 
  Java.  So I have one choice and that is to make interop work.  Now reality 
  sets in.  My data model contains java.sql.Date and ArrayList.  I have no 
  problem with (the idea of) marshelling these to the least common denominator 
  of the SOAP types.  Why not?  SOAP supports arrays and datetimes.  That's 
  what these things are when it comes down to it. 

  My original question stands.  How do I write the serializers for these for 
  the server side.  Yes I will have to make assumptions, but I own the data 
  model and can do that (Soap array is an ArrayList, Soap Datetime is 
  java.sql.date).  Is this possible?  Has anyone done? Have examples? 



  Bill 
  ----- Original Message ----- 
  From: "Steve Loughran" <steve_l@iseran.com> 
  To: <axis-user@ws.apache.org> 
  Sent: Monday, March 10, 2003 5:58 PM 
  Subject: Re: Simple little trick for easing (de)serialization issues 



  > 
  > ----- Original Message ----- 
  > From: "Milind Gadre" <milind@ecplatforms.com> 
  > To: "Paul Andrews" <paandrew@cisco.com> 
  > Cc: <axis-user@ws.apache.org> 
  > Sent: Monday, March 10, 2003 14:24 
  > Subject: Re: Simple little trick for easing (de)serialization issues 
  > 
  > 
  > > 
  > > 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... 
  > 
  > If you look at the continual problem, yes people on this list are 
  constantly 
  > trying to send Objects over, File objects, HashMaps and complaining that 
  > Axis bails out. And no doubt the .NET support groups get calls saying 'we 
  > cant send System.Util.HashTable over the wire", or "Why cant I send 
  > System.Object" instances out. 
  > 
  > Both these problems stem from the same underlying cause: you cannot 
  achieve 
  > interop without sacrificing seamless marshalling of all data you can have 
  in 
  > a complex language. Or as I put in in my presentation: 
  > 
  > http://www.iseran.com/Steve/papers/interop/ 
  > 
  > Naiive and unrealistic expectations are a recurring interop issue. User 
  > education -that's you finding out you cant send stuff out. is the first 
  step 
  > to addressing interop. 
  > 
  > At the same time, Web Services built on SOAP+XSD can improve interop. Axis 
  > needs better DataSet handling, everyone needs to agree on standards for 
  > hashtable, list, and other core collection types that can be mapped to 
  java, 
  > .NET, C++ STL and Perl. 
  > 
  > Until then: stop trying to send stuff over SOAP that doesnt work in 
  language 
  > s other than Java. Any quick hacks to support Java only (or indeed .NET, 
  C++ 
  > or Perl) throw away a key benefit of the technology: you dont need to care 
  > what language the caller is using. Once you throw that away, what are you 
  > left with? A distributed messaging protocol that is slow, inefficient and 
  > incomplete -something not worth using 
  > 
  > -steve 
  > 

Mime
View raw message