The idea that "Apache SOAP forces you to be explicit about type" is a barrier in good system design. This breaks abstraction. I should be able to use a serializer for HashMap class where a serializer for Map is expected. Some runtime interaction causes search for Map serializer. If there is one -- good, use it. If there is none for Map, but one for HashMap -- ok use it.
I would not allow such behavior in my O-O program -- "Liskov Substitution principle is lost". Somewhere in Apache serialization design this OO principle is lost. Just my opinion, I could be wrong on design philosophy. In CORBA such issues are not there -- all the time I deal with OO programming language types whose semantics extend to wireline protocol (via code generation and inheritance). I am having problem to understand why Apache SOAP would not allow such facility to OO programnmers -- why the abstraction is suddenly breaking (and discussion taking place on serilizers). Soumen Sarkar. -----Original Message----- From: Scott Nichol [mailto:[EMAIL PROTECTED]] Sent: Monday, July 01, 2002 8:06 PM To: [EMAIL PROTECTED] Subject: Re: Confusing issue on Maps ----- Original Message ----- From: "Niclas Hedhman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 01, 2002 10:26 PM Subject: Re: Confusing issue on Maps > On Tuesday 02 July 2002 10:00, Scott Nichol wrote: > > It is "inherent", but only for an exact match of the type Map. When the > > Parameter instance is created, the type specified there is used to > > determine the serializer. Specifying the type using HashMap.class does not > > match the serializer for Map, which is registered using Map.class. > > > Alternatively, you can specify HashMap.class when instantiating the > > Parameter, but then you must add a mapping using > > SOAPMappingRegistry#mapTypes for HashMap. > > I don't call either way "inherent". > > Inherent means to me; "I need to do nothing and it will work". > > Map.class is meaningless as "exact match". There is nothing that returns a > "class java.util.Map" for getClass(), if that is what you mean. Here's how I see it. 1. MapSerializer is registered by Apache SOAP as a serializer and deserializer for the Java type Map. You do not need to call mapTypes to get this functionality. To me, that is "inherent". 2. When you create a Parameter, you specify the Java type as which you want it to be serialized. Having this flexibility is extremely important. What if Apache SOAP always did a getClass() on the value you specified for the parameter? In that case, you could never serialize by interface. 3. You may want to ignore the freedom of #2 by always specifying the Java type as value.getClass(). Since this type chooses the serializer, however, you may not get the result you intended. In your case, you would specify a Java type of TreeMap or HashMap, but want to serialize as a Map. Unfortunately, Apache SOAP is not clairvoyant ;-). I supposed that if Apache SOAP did not find a match for the specified class, it could try to find serializer matches for superclasses and/or implemented interfaces, but in the case of multiple matches, which would it use? Instead, the code forces you to be explicit about the type. > > Parameter types are typically not a problem, since they are pretty much under > control and can be modified for the occassion. It is the content of objects > that really is annoying. > > > Don't get me wrong. I like SOAP and I like the Apache SOAP implementation. We > have used it in three parts of our system. A Login service, a business logic > service, and a File System that can be plugged into NetBeans. Only the > business logic is giving us a hard time, since we are dealing with objects > instead of primitives. Indeed, this is where SOAP becomes less simple. One project I worked on about 2 years ago that was using Microsoft's SOAP Toolkit was abandoned after a programmer revolt: no one wanted to write and debug the serializers and deserializers for all the custom types. Up the chain of command it was agreed that SOAP "had too much baggage", the project was killed, SOAP was removed from the architectural direction, and my contract with the company was terminated. Forunately, not everyone has such a reaction to a little grunt work. Scott Nichol -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
