Hey
Rich:
Sorry
about that. I'm rolling this change back, but I won't be around Tuesday,
as I'll be in Montreal until Wednesday evening. Will be reading email very
sporadically over the weekend, but probably not from Mon afternoon to
Wed.
My
rationale for the change was explained in the message. I'd like to
understand what you're doing with it that couldn't be accomplished by extending
a Deserializer class. We can discuss it next week.
--Glen
-----Original Message-----
From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 24, 2002 7:47 PM
To: [EMAIL PROTECTED]
Subject: RE: cvs commit: xml-axis/java/test/encoding DataDeser.java DataDe serFactory.java DataSerFactory.java TestDOM.java TestDeser.java TestHrefs .java TestSer.java
Thanks for the heads up, Glen. Oops I guess you didn't give me a heads up. We need this to be put back in immediately.
Letting me know after the fact is not an appropriate way to make a point.
Please take out your changes and we can discuss this on the Tuesday chat. Or are conceeding that no else's opinion matters.
Thank you and have a good weekend.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
Glen Daniels <[EMAIL PROTECTED]> 05/24/2002 01:24 PM
Please respond to axis-dev
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: cvs commit: xml-axis/java/test/encoding DataDeser.java DataDe serFactory.java DataSerFactory.java TestDOM.java TestDeser.java TestHrefs .java TestSer.java
While I was working on this stuff, I noticed the
org.apache.axis.encoding.Deserializer interface had been introduced, I
assume as another point of extensibility(?), during Rich's revamp of the
encoding framework. I have removed this interface, and renamed the
DeserializerImpl class to Deserializer, as it was before. The reason for
this is as follows: before Rich's modification, Deserializer extended
SOAPHandler directly, so it was clear that all Deserializers WERE
in fact SOAPHandlers. Afterwards, there were a number of places where we
needed to do a manual cast of a Deserializer to a SOAPHandler deep in the
deserialization code. This worked, because every Deserializer
implementation we currently had extended SOAPHandler (b/c DeserializerImpl
did). However, there is no requirement that someone wouldn't try to
build another Deserializer implementation which didn't extend SOAPHandler,
and break the system. These kinds of cross-casts are really bad ideas.
The code is now less prone to breakage, and easier to understand.
Note that we DO still implement the JAX-RPC Deserializer interface, which
is the one that really needs to be an interface.
--Glen
