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
|
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
