I
guess what I'm saying is that I don't think this is a place where there is going
to be any call for pluggability. YAGNI.
--Glen
-----Original Message-----
From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 09, 2002 3:40 PM
To: [EMAIL PROTECTED]
Subject: Re: SerializationContext/DeserializationContext cleanup?
Generally, separating interfaces from implementation is a good thing.
For one, it gives us the opportunity to make this a pluggable piece in the future.
Also it establishes better boundaries between the components. Before I made these changes,
there was a lot of interactions between components using public or package visible fields.
I feel that the Context classes are a lot better off (and remain better organized) now that we have
interfaces. I would vote -1 to removing the interfaces.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
Glen Daniels <[EMAIL PROTECTED]> 05/09/2002 01:51 PM
Please respond to axis-dev
To: "'Axis-Dev (E-mail)'" <[EMAIL PROTECTED]>
cc:
Subject: SerializationContext/DeserializationContext cleanup?
Does anyone (Rich?) have any real reasons why we have SerializationContext and SerializationContextImpl? I know the JAX-RPC SerializationContext is an interface we have to implement, but it seems to me we could just as easily (and much more conveniently) have axis.encoding.SerializationContext be a class instead of introducing yet another interface.
Same holds for DeserializationContext/DeserializationContextImpl.
Do you think these are useful + important points of extensibility? Are there really going to be other implementations?
If we could coalesce these guys, that would make my life a happier place.
--Glen
