You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cxf.apache.org by Dan Diephouse <da...@envoisolutions.com> on 2007/04/11 20:53:44 UTC
Client & Endpoint Config [was Re: Generic client config]
On 4/11/07, Dan Diephouse <da...@envoisolutions.com> wrote:
>
> Hiya
>
> On 4/11/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
> >
> > 1. How does the <jaxws:client> id attribute relate to the target port
> > name? e.g. id="MyPort", or id="MyService/MyPort", or
> > id="{http://myNamespace}MyService/MyPort ", or some wildcarded variant,
> > or something else entirely?
>
>
> It pulls out the <jaxws:client> config by the port name.
>
> From the ServiceImplTest/soapServiceConfig.xml:
>
> <jaxws:client id="{ http://apache.org/hello_world_soap_http}SoapPort<http://apache.org/hello_world_soap_http%7DSoapPort>"
> abstract="true">
> <jaxws:properties>
> <entry key="foo" value="bar"/>
> </jaxws:properties>
> </jaxws:client>
>
I'm just thinking through this some more...
I think this is liable not to work if we have both an <endpoint> and
<client> defined in the same context as Spring will create the same ids for
them. Therefore when we do configureObject() its liable to get confused and
not work.
What do people think of requiring that people add ".client" or ".endpoint"
to the ids? Maybe I'm missing something, but that might be the only way to
get this to work.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Client & Endpoint Config [was Re: Generic client config]
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> Regex's are of course another story. If multiple
> configurations are candidates, that should throw an error I
> think. However to even get to that stage, someone needs to
> add support for matching the Service/Port syntax.
Would anyone in the community care to volunteer to take on the above
task?
Cheers,
Eoghan
Re: Client & Endpoint Config [was Re: Generic client config]
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 4/12/07, Polar Humenn <ph...@iona.com> wrote:
>
>
>
> I would also recommend adding the service name to the configuration name.
>
> I would also like these questions answered
>
> 1. Without even concerning regex matching). If there are two
> configurations of the same name:
> (a) in the same file, which one gets applied?
> (b) in different files, which one gets applied?
>
> If you call that a configuration error. That's great, throw an exception
> and stop the show.
> But when you start using regex situations (a) and (b) become very real.
I don't think you can have two spring beans with the same id, so
theoretically Spring should throw an error on startup. Although I haven't
personally verified this.
Regex's are of course another story. If multiple configurations are
candidates, that should throw an error I think. However to even get to that
stage, someone needs to add support for matching the Service/Port syntax.
I can also see the potential to have "base" configurations with
> "overrides". How will that be handled, if handled at all?
>
> Spring has the concept of parent beans...
<bean id="parentBean" abstract="true">
... some properties for everything that inherits from this
</bean>
<bean id="my.first.endpoint" parent="parentBean">
.. properties specific to this endpoint
</bean>
The parent stuff may not 100% work yet with our custom xml syntax though. I
would probably need to add explicit support for this inside the
AbstractBeanDefinitionParser.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Client & Endpoint Config [was Re: Generic client config]
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 4/12/07, Polar Humenn <ph...@iona.com> wrote:
>
>
>
> I would also recommend adding the service name to the configuration name.
>
> I would also like these questions answered
>
> 1. Without even concerning regex matching). If there are two
> configurations of the same name:
> (a) in the same file, which one gets applied?
> (b) in different files, which one gets applied?
>
> If you call that a configuration error. That's great, throw an exception
> and stop the show.
> But when you start using regex situations (a) and (b) become very real.
I don't think you can have two spring beans with the same id, so
theoretically Spring should throw an error on startup. Although I haven't
personally verified this.
Regex's are of course another story. If multiple configurations are
candidates, that should throw an error I think. However to even get to that
stage, someone needs to add support for matching the Service/Port syntax.
I can also see the potential to have "base" configurations with
> "overrides". How will that be handled, if handled at all?
>
> Spring has the concept of parent beans...
<bean id="parentBean" abstract="true">
... some properties for everything that inherits from this
</bean>
<bean id="my.first.endpoint" parent="parentBean">
.. properties specific to this endpoint
</bean>
The parent stuff may not 100% work yet with our custom xml syntax though. I
would probably need to add explicit support for this inside the
AbstractBeanDefinitionParser.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Client & Endpoint Config [was Re: Generic client config]
Posted by Polar Humenn <ph...@iona.com>.
Glynn, Eoghan wrote:
>
>
>
>> -----Original Message-----
>> From: Dan Diephouse [mailto:dan@envoisolutions.com]
>> Sent: 11 April 2007 19:54
>> To: cxf-dev@incubator.apache.org
>> Cc: cxf-commits@incubator.apache.org
>> Subject: Client & Endpoint Config [was Re: Generic client config]
>>
>> On 4/11/07, Dan Diephouse <da...@envoisolutions.com> wrote:
>>
>>> Hiya
>>>
>>> On 4/11/07, Glynn, Eoghan <eo...@iona.com> wrote:
>>>
>>>
>>>> 1. How does the <jaxws:client> id attribute relate to the target
>>>> port name? e.g. id="MyPort", or id="MyService/MyPort", or
>>>> id="{http://myNamespace}MyService/MyPort ", or some wildcarded
>>>> variant, or something else entirely?
>>>>
>>> It pulls out the <jaxws:client> config by the port name.
>>>
>>> From the ServiceImplTest/soapServiceConfig.xml:
>>>
>>> <jaxws:client id="{
>>>
>> http://apache.org/hello_world_soap_http}SoapPort<http://apache
>> .org/hello_world_soap_http%7DSoapPort>"
>>
>>> abstract="true">
>>> <jaxws:properties>
>>> <entry key="foo" value="bar"/>
>>> </jaxws:properties>
>>> </jaxws:client>
>>>
>>>
>> I'm just thinking through this some more...
>>
>> I think this is liable not to work if we have both an
>> <endpoint> and <client> defined in the same context as Spring
>> will create the same ids for them. Therefore when we do
>> configureObject() its liable to get confused and not work.
>>
>> What do people think of requiring that people add ".client"
>> or ".endpoint"
>> to the ids? Maybe I'm missing something, but that might be
>> the only way to get this to work.
>>
>
>
> Well I guess the ".client" suffix would line up with the ".http-conduit"
> style used elsewhere.
>
> Which I guess brings us rounf to the "what if the same port name is used
> in multiple services" question brought up by Fred recently in relation
> to the http-conduit config.
>
> The consensus on that seemed to be that it would be a good idea to add
> the service name into the bean ID in order to distinguish between the
> similarly named ports, and to use a regex-based wild-carding scheme to
> support semantics like "http://myNamespace}ServiceA/.*" meaning "all
> ports associated with ServiceA" or "http://myNamespace}.*/Http.*"
> meaning "any port name starting with Http" etc. Probably a good idea to
> have the same flexibility with the <jaxws:client> config.
>
>
I would also recommend adding the service name to the configuration name.
I would also like these questions answered
1. Without even concerning regex matching). If there are two
configurations of the same name:
(a) in the same file, which one gets applied?
(b) in different files, which one gets applied?
If you call that a configuration error. That's great, throw an exception
and stop the show.
But when you start using regex situations (a) and (b) become very real.
I can also see the potential to have "base" configurations with
"overrides". How will that be handled, if handled at all?
Cheers,
Polar
> Cheers,
> Eoghan
>
>
>
RE: Client & Endpoint Config [was Re: Generic client config]
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 11 April 2007 19:54
> To: cxf-dev@incubator.apache.org
> Cc: cxf-commits@incubator.apache.org
> Subject: Client & Endpoint Config [was Re: Generic client config]
>
> On 4/11/07, Dan Diephouse <da...@envoisolutions.com> wrote:
> >
> > Hiya
> >
> > On 4/11/07, Glynn, Eoghan <eo...@iona.com> wrote:
> >
> > >
> > > 1. How does the <jaxws:client> id attribute relate to the target
> > > port name? e.g. id="MyPort", or id="MyService/MyPort", or
> > > id="{http://myNamespace}MyService/MyPort ", or some wildcarded
> > > variant, or something else entirely?
> >
> >
> > It pulls out the <jaxws:client> config by the port name.
> >
> > From the ServiceImplTest/soapServiceConfig.xml:
> >
> > <jaxws:client id="{
> http://apache.org/hello_world_soap_http}SoapPort<http://apache
> .org/hello_world_soap_http%7DSoapPort>"
> > abstract="true">
> > <jaxws:properties>
> > <entry key="foo" value="bar"/>
> > </jaxws:properties>
> > </jaxws:client>
> >
>
>
> I'm just thinking through this some more...
>
> I think this is liable not to work if we have both an
> <endpoint> and <client> defined in the same context as Spring
> will create the same ids for them. Therefore when we do
> configureObject() its liable to get confused and not work.
>
> What do people think of requiring that people add ".client"
> or ".endpoint"
> to the ids? Maybe I'm missing something, but that might be
> the only way to get this to work.
Well I guess the ".client" suffix would line up with the ".http-conduit"
style used elsewhere.
Which I guess brings us rounf to the "what if the same port name is used
in multiple services" question brought up by Fred recently in relation
to the http-conduit config.
The consensus on that seemed to be that it would be a good idea to add
the service name into the bean ID in order to distinguish between the
similarly named ports, and to use a regex-based wild-carding scheme to
support semantics like "http://myNamespace}ServiceA/.*" meaning "all
ports associated with ServiceA" or "http://myNamespace}.*/Http.*"
meaning "any port name starting with Http" etc. Probably a good idea to
have the same flexibility with the <jaxws:client> config.
Cheers,
Eoghan
RE: Client & Endpoint Config [was Re: Generic client config]
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 11 April 2007 19:54
> To: cxf-dev@incubator.apache.org
> Cc: cxf-commits@incubator.apache.org
> Subject: Client & Endpoint Config [was Re: Generic client config]
>
> On 4/11/07, Dan Diephouse <da...@envoisolutions.com> wrote:
> >
> > Hiya
> >
> > On 4/11/07, Glynn, Eoghan <eo...@iona.com> wrote:
> >
> > >
> > > 1. How does the <jaxws:client> id attribute relate to the target
> > > port name? e.g. id="MyPort", or id="MyService/MyPort", or
> > > id="{http://myNamespace}MyService/MyPort ", or some wildcarded
> > > variant, or something else entirely?
> >
> >
> > It pulls out the <jaxws:client> config by the port name.
> >
> > From the ServiceImplTest/soapServiceConfig.xml:
> >
> > <jaxws:client id="{
> http://apache.org/hello_world_soap_http}SoapPort<http://apache
> .org/hello_world_soap_http%7DSoapPort>"
> > abstract="true">
> > <jaxws:properties>
> > <entry key="foo" value="bar"/>
> > </jaxws:properties>
> > </jaxws:client>
> >
>
>
> I'm just thinking through this some more...
>
> I think this is liable not to work if we have both an
> <endpoint> and <client> defined in the same context as Spring
> will create the same ids for them. Therefore when we do
> configureObject() its liable to get confused and not work.
>
> What do people think of requiring that people add ".client"
> or ".endpoint"
> to the ids? Maybe I'm missing something, but that might be
> the only way to get this to work.
Well I guess the ".client" suffix would line up with the ".http-conduit"
style used elsewhere.
Which I guess brings us rounf to the "what if the same port name is used
in multiple services" question brought up by Fred recently in relation
to the http-conduit config.
The consensus on that seemed to be that it would be a good idea to add
the service name into the bean ID in order to distinguish between the
similarly named ports, and to use a regex-based wild-carding scheme to
support semantics like "http://myNamespace}ServiceA/.*" meaning "all
ports associated with ServiceA" or "http://myNamespace}.*/Http.*"
meaning "any port name starting with Http" etc. Probably a good idea to
have the same flexibility with the <jaxws:client> config.
Cheers,
Eoghan