How should I fix the autoRewriteSoapAddress/Spring issue (CXF-2770)?

[Jim Talbut <jt...@spudsoft.co.uk>]

Hi,

Summary of the issue: it's not possible to set autoRewriteSoapAddress on 
a CXF endpoint using Spring because all the Spring properties are set on 
the Endpoint, not the EndpointInfo.
https://issues.apache.org/jira/browse/CXF-2770

I'd like to write a patch for this, but I'd like to get a pointer as to 
the preferred solution.
Options I've come up with include:
1. Apply all properties to both Endpoint and EndpointInfo.
2. Provide a way to identify an EndpointInfo property by key value 
("EndpointInfo:autoRewriteSoapAddress").
3, Have a list of named properties that go on the EndpointInfo.
4. Have a separate element (a twin to jaxws:properties) for the 
EndpointInfo properties.
5. Have the check for autoRewriteSoapAddress look at the Endpoint (not 
sure there is an Endpoint at the right time, so this may not be feasible)
Give me a pointer for the preferred approach and I'll knock it up.

There doesn't seem to be much point in waiting for anyone else to 
produce a fix for it, given that noone else seems to be interested in it 
at all, I guess others are lucky to have clients who are slightly more 
competent than mine :)

Thanks.

Jim

Re: How should I fix the autoRewriteSoapAddress/Spring issue (CXF-2770)?

[Daniel Kulp <dk...@apache.org>]

On Sunday 13 June 2010 2:09:34 am Jim Talbut wrote:
> Hi,
> 
> Summary of the issue: it's not possible to set autoRewriteSoapAddress on
> a CXF endpoint using Spring because all the Spring properties are set on
> the Endpoint, not the EndpointInfo.
> https://issues.apache.org/jira/browse/CXF-2770
> 
> I'd like to write a patch for this, but I'd like to get a pointer as to
> the preferred solution.
> Options I've come up with include:
> 1. Apply all properties to both Endpoint and EndpointInfo.

Hmmm...  not sure what this would break.  Might be worth trying to see what 
happens.    I think if this works, it might be preferred.   It may be as 
simple as overriding the get/setProperty calls on Endpoint to forward into 
EndpointInfo so there aren't any properties on Endpoint.    That may be able 
to simplify the message.getContextualProperty call as well.

> 2. Provide a way to identify an EndpointInfo property by key value
> ("EndpointInfo:autoRewriteSoapAddress").

I'd be OK with this.  Seems kind of hacky though as it kind of exposes some 
internal structure things, but would avoid breaking anything that (1) might.   

> 3, Have a list of named properties that go on the EndpointInfo.

Ick.

> 4. Have a separate element (a twin to jaxws:properties) for the
> EndpointInfo properties.

Like (2), exposes some internal things, but I'd be OK with it.

> 5. Have the check for autoRewriteSoapAddress look at the Endpoint (not
> sure there is an Endpoint at the right time, so this may not be feasible)
> Give me a pointer for the preferred approach and I'll knock it up.

I really don't think this is feasible.  The URL handler things only get the 
EndpointInfo passed in, not the Endpoint.   Thus, to accomplish this would 
involve breaking the API's to pass the Endpoint instead.   I think the only 
way to do this would be to have  the EndpointInfo hold a pointer to the 
Endpoint (likely as a property) which the handler could check for.   MIGHT be 
doable.  Not really sure.

> There doesn't seem to be much point in waiting for anyone else to
> produce a fix for it, given that noone else seems to be interested in it
> at all, I guess others are lucky to have clients who are slightly more
> competent than mine :)
> 
> Thanks.

I would say attempt #1, but if a bunch of tests fail, fallback to 2 or 5.   


-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog