cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject Re: <jaxws:client> createdFromAPI attribute
Date Tue, 24 Apr 2007 16:40:46 GMT

In one of my previous commit messages I detailed this change and why it
needed to be done. In essence if you have a <jaxws:client> and a
<jaxws:endpoint> with the same id, they conflict. In essence there were two

1. Change the bean definitions parsers to automatically append
".jaxws-client" and ".jaxws-endpoint" to the bean names
2. Force people to append those to the ID themselves.

As appending .jaxws-client to each ID seemed rather redundant, I opted for
choice #1. From here there were two choices:
1. Automatically change the id if abstract=true
2. Create some other mechanism to automatically change the id - i.e.
createdFromAPI = true

If we went with #1 this would break parent/child relationships for the
normal spring case ("why isn't my ID what I specified it to be?!?!"). So I
opted for solution #2.

createdFromAPI simply means that the user created that bean using our APIs -
i.e. Endpoint.publish or Service.getPort. If you have better suggestions, I
would welcome them - I asked for some in my commit message.

I updated all the tests to use createdFromAPI and also all the demos. the
coloc demo was added after these changes, so I did not review that one.

- Dan

On 4/24/07, Glynn, Eoghan <> wrote:
> Folks,
> After tearing my hair out for the last hour as to why some
> <jaxws:client> config seemed no longer to be working as before, it looks
> like the abstract="true" attribute on this element needs to be replaced
> by createdFromAPI="true".
> What does createdFromAPI mean in this context? That the proxy is created
> via Service.getPort(), or?
> Also is this the only change required to restore the previous semantics?
> Whoever made the change, probably a good idea to also update any system
> tests and/or demos that use this config, prior to the release. A quick
> grep suggests this applies to the coloc demo and system tests at least,
> maybe others too.
> Cheers,
> Eoghan

Dan Diephouse
Envoi Solutions |

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message