Sounds good to me.
I can see the point that the "deserializer" must extend SOAPHandler, so
perhaps the Deserializer interface that we currently have is not
appropriate. But on the other hand I would like a little flexibility
here...and the fact that the "Deserializer Impl" is both a base class and
is not abstract (and is constructed) makes me a little queasy.
So perhaps something like the following is more appropriate.
class abstract Deserializer implements JAX-RPC Deserializer
...
class DeserializerBase extends Deserializer
this contains the stuff in DeserializerImpl
class BeanDeserializer extends DeserializerBase
I do think that organizing this stuff into interfaces and providing methods
and comments has made this section of the code easier to improve and
maintain. So perhaps moving from a Deserializer interface to a
Deserializer abstract class is appropriate.
Thanks,
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
Glen Daniels
<gdaniels@macrome To: "'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]>
dia.com> cc:
Subject: RE: cvs commit:
xml-axis/java/test/encoding DataDeser.java DataDe
05/24/2002 10:45 serFactory.java DataSerFactory.java
TestDOM.java TestDeser.java TestHref
PM s .java TestSer.java
Please respond to
axis-dev
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
<gdaniels@macromed To: "'[EMAIL PROTECTED]'"
ia.com> <[EMAIL PROTECTED]>
cc:
Subject: RE: cvs commit:
05/24/2002 01:24 xml-axis/java/test/encoding DataDeser.java DataDe
PM serFactory.java DataSerFactory.java TestDOM.java
Please respond to TestDeser.java TestHrefs .java TestSer.java
axis-dev
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
