[Axis2] Re: [jira] Commented: (AXIS2-993) org.apache.axis2.addressing.EndpointReference should explicitly save the WS-Addressing namespace

[Brian De Pradine]

Hello all,

Eran suggested that we move this discussion
to the axis-dev list. Please find my comments below.

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?


"Eran Chinthaka (JIRA)" <[EMAIL PROTECTED]>
wrote on 17/08/2006 14:48:15:

>     [ http://issues.apache.org/jira/browse/AXIS2-993?
> page=comments#action_12428656 ] 
>             
> Eran Chinthaka commented on AXIS2-993:
> --------------------------------------
> 
> Brian,
> 
> This is one of the problems I've been looking at for some time. IMO,
> EndpointReference class better be independent of WS-A. We got the

> attributed of the EPR class by looking at 2005/08 spec, but after

> that it had nothing to do with that. 

Why does the EndpointReference class need to be independent
of the WS-Addressing
namespace? This is the aspect of this discussion that
I haven't understood yet.
Considering that in axis2 ALL EPRs are represented
using instances of this class
it seems to me that the addressing namespace is an
important attribute to capture.

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

EndpointReference is currently used to represent EPRs
for both specs, and
I believe that this works well. The change that I
am proposing would 
preserve this without the need for subclassing, which
just adds complexity
for no extra benefit, in this case.

> 2. Delegate to a helper class for fromOM and toOM. 
> AddressingHelper.toOM(epr, addressingNamespace)
> AddressingHelper.fromOM(omElement)
> 

I think that we are probably in agreement that having
methods to correctly
serialize/deserialize EPRs are a good thing. I believe
that we differ on
where this code should live. I believe that this code
should be in the
EndpointReference class, rather than some helper class,
as this leads to
better encapsulation, and ultimately code that is
easier to understand.

> For further discussions, if required, lets move this to axis-dev 
> mailing list. 
> 
> -- Chinthaka
> 
> > org.apache.axis2.addressing.EndpointReference should explicitly

> save the WS-Addressing namespace
> > 
> ------------------------------------------------------------------------------------------------
> >
> >                 Key:
AXIS2-993
> >                 URL:
http://issues.apache.org/jira/browse/AXIS2-993
> >             Project: Apache Axis
2.0 (Axis2)
> >          Issue Type: Improvement
> >          Components: Addressing
> >            Reporter: Brian DePradine
> >         Attachments: newerpatch.txt, newpatch.txt,
patch.txt
> >
> >
> > Currently, the EndpointReference class always assumes that it
is a
> representation of endpoint references based on the WS-Addressing 
> 2005/08 (final) spec. However, this class is also used to represent

> endpoint references based on the 2004/08 (submission) spec. The 
> problem is that the methods toOM() and fromOM() only work correctly

> in the former case. If the EndpointReference class is modified to

> explicitly save the WS-Addressing namespace then these methods can

> be made to work correctly for both specs. Patch to follow.
> 
> -- 
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:

> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
> 
>         
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>