cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: <jaxws:client> createdFromAPI attribute
Date Tue, 08 May 2007 16:14:25 GMT
Lets say I do:

<jaxws:endpoint id="abstractendpoint">
  <jaxws:features>
    <wsa:addressing/>
  </jaxws:features>
</jaxws:endpoint>

<jaxws:endpoint id="myEndpoint" parent="abstractendpoint" address="..."
implementor="...">

If we automatically appended .jaxws-endpoint to ids, the parent attribute on
the endpoint would no longer be relavent as it would have to be
abstractendpoint.jaxws-endpoint. It was also be very confusing to spring
users to have their id changing on them I think.

- Dan

On 5/8/07, Tully, Gary <Gary.Tully@iona.com> wrote:
>
>
> Hi Dan,
> Apologies for coming late to this but could you expand on:
>
> > 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?!?!").
>
> I must be missing something here but why is the parent child
> relationship relevant to beans that are auto-generated from features? In
> the normal spring case the equivalent auto-generated beans would not
> exist without the suffixes.
>
> Thanks for your time,
> Gary.
>
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 24 April 2007 17:41
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: <jaxws:client> createdFromAPI attribute
> >
> > Hiya,
> >
> > 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 solutions.
> >
> > 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 <eoghan.glynn@iona.com> 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
> > http://envoisolutions.com | http://netzooid.com/blog
> >
>



-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

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