"Eran Chinthaka (JIRA)" <[EMAIL PROTECTED]> wrote on 17/08/2006 14:48:15:
> I'd like to keep it as it is and rather than implementing toOM and
> fromOM inside that, we can do the same using one of the following
> options, without touching the EPR class.
>
> 1. Extending from EPR class, we can have two different sub classes
> for two specs. But this must make sure that EPR class can be used as
> it is without its sub classes for some users, who do not want to
> worry abt the WS-A spec.
>
> 2. Delegate to a helper class for fromOM and toOM.
> AddressingHelper.toOM(epr, addressingNamespace)
> AddressingHelper.fromOM(omElement)
>
In order to move this forward, I propose that we do the following:
1. Change the signature of the helper methods to the following,
AddressingHelper.toOM(epr, qname, addressingNamespace)
AddressingHelper.fromOM(omElement, addressingNamespace)
AddressingHelper.fromOM(omElement)
The qname, passed to the toOM() method, is the name of the element that will contain the EndpointRefereneceType. The addressingNamespace, passed to the fromOM() method, is used to explicitly specify which namespace to use for the deserialization. If the namespace of the omElement EndpointReferenceType did not match this namespace then that would be a fault.
2. Deprecate, or remove, toOM() and fromOM() from EndpointReference
3. Deprecate, or remove, setName() and getName() from EndpointReference
Does this sound reasonable?
Cheers
Brian DePradine
Web Services Development
IBM Hursley
External +44 (0) 1962 816319 Internal 246319
If you can't find the time to do it right the first time, where will you find the time to do it again?
