You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Fred Dushin <fr...@dushin.net> on 2007/08/28 20:51:44 UTC
Bus Features [was: Logging ...]
On Aug 24, 2007, at 11:36 AM, Daniel Kulp wrote:
> <cxf:bus>
> <cxf:features>
> <cxf:logging/>
> </cxf:features>
> </cxf:bus>
How do Bus-level features interact with endpoint- or client-level
features? For example, if I have
{{{
<cxf:bus>
<cxf:features>
<cxf:foo/>
</cxf:features>
</cxf:bus>
<jaxws:endpoint name="{http://foo.bar.com}FUBAR">
<cxf:features>
<cxf:foo/>
</cxf:features>
</jaxws:endpoint>
}}}
and a servant is instantiated under the WSDL Port {http://foo.bar.com}
FUBAR, is a feature instantiated twice, once for the Bus, qua
InterceptorProvider, and once for the Endpoint, qua InterceptorProvider?
If it's instantiated twice, is there any way a feature implementor to
traverse the interceptors on each InterceptorProvider, to see if a
feature has been installed, or are these interceptor lists
independent of one another?
(The reason I ask is, there might be a tendency to think of the
feature config on the Bus as a kind of default, such that if a
feature is defined at endpoint granularity, that feature is the
effective feature in config, whereas if there is no such config at
endpoint granularity, the runtime would fall back to the Bus config.
But I'm guessing that's really not the behavior here, is it?)
Thanks!
-Fred
Re: Bus Features [was: Logging ...]
Posted by Sergey Beryozkin <se...@iona.com>.
Hi,
"I wonder can this be done through WS-Policy? I.e., I can make some assertions like this: " I want to apply this feature to endpoint
A and B" or "I want this feature applied to all my endpoints by default if there is no overridden feature defined for the individual
endpoint". Thoughts?"
CXF supports an external WS-Policy attachment mechanism, which should suffice...
It's briefly described here :
http://cwiki.apache.org/CXF20DOC/how-it-works.html
Using this approach you can apply a policy expression to one or more domain expressions, for ex, to EndpointReferences...There's an
rm_external.xml file in a ws_policy system test, it shows how WS-Addresing and WS-RM policies are applied to a given endpoint...
Cheers, Sergey
----- Original Message -----
From: "Liu, Jervis" <jl...@iona.com>
To: <cx...@incubator.apache.org>
Sent: Wednesday, August 29, 2007 7:17 AM
Subject: RE: Bus Features [was: Logging ...]
Hi Fred, I recalled we had a similar discussion before. In your code snippet below, the logging interceptors will be installed
twice. I wont say <cxf:bus> is a root scope configuration as there is no hierarchy relationships among bus, endpoints and bindings.
Bus, endpoints and bindings are just individual components that can contribute interceptors, some times a same bus instance can be
shared by multiple services but this wont necessarily make it a root configuration. Bindings can be shared by multiple services as
well. What you required, "if a feature is defined at endpoint granularity, that feature is the effective feature in config,
whereas if there is no such config at endpoint granularity, the runtime would fall back to the Bus config", is really a scope-based
configuration. This is no such thing existing yet in CXF. I wonder can this be done through WS-Policy? I.e., I can make some
assertions like this: " I want to apply this feature to endpoint A and B" or "I want this feature applied to all my endpoints by
default if there is no overridden feature defined for the individual endpoint". Thoughts?
Jervis
> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net]
> Sent: 2007?8?29? 2:52
> To: cxf-user@incubator.apache.org
> Subject: Bus Features [was: Logging ...]
>
>
>
> On Aug 24, 2007, at 11:36 AM, Daniel Kulp wrote:
>
> > <cxf:bus>
> > <cxf:features>
> > <cxf:logging/>
> > </cxf:features>
> > </cxf:bus>
>
> How do Bus-level features interact with endpoint- or client-level
> features? For example, if I have
>
> {{{
> <cxf:bus>
> <cxf:features>
> <cxf:foo/>
> </cxf:features>
> </cxf:bus>
>
> <jaxws:endpoint name="{http://foo.bar.com}FUBAR">
> <cxf:features>
> <cxf:foo/>
> </cxf:features>
> </jaxws:endpoint>
> }}}
>
> and a servant is instantiated under the WSDL Port
> {http://foo.bar.com}
> FUBAR, is a feature instantiated twice, once for the Bus, qua
> InterceptorProvider, and once for the Endpoint, qua
> InterceptorProvider?
>
> If it's instantiated twice, is there any way a feature
> implementor to
> traverse the interceptors on each InterceptorProvider, to see if a
> feature has been installed, or are these interceptor lists
> independent of one another?
>
> (The reason I ask is, there might be a tendency to think of the
> feature config on the Bus as a kind of default, such that if a
> feature is defined at endpoint granularity, that feature is the
> effective feature in config, whereas if there is no such config at
> endpoint granularity, the runtime would fall back to the Bus
> config.
> But I'm guessing that's really not the behavior here, is it?)
>
> Thanks!
> -Fred
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
RE: Bus Features [was: Logging ...]
Posted by "Liu, Jervis" <jl...@iona.com>.
Hi Fred, I recalled we had a similar discussion before. In your code snippet below, the logging interceptors will be installed twice. I wont say <cxf:bus> is a root scope configuration as there is no hierarchy relationships among bus, endpoints and bindings. Bus, endpoints and bindings are just individual components that can contribute interceptors, some times a same bus instance can be shared by multiple services but this wont necessarily make it a root configuration. Bindings can be shared by multiple services as well. What you required, "if a feature is defined at endpoint granularity, that feature is the effective feature in config, whereas if there is no such config at endpoint granularity, the runtime would fall back to the Bus config", is really a scope-based configuration. This is no such thing existing yet in CXF. I wonder can this be done through WS-Policy? I.e., I can make some assertions like this: " I want to apply this feature to endpoint A and B" or "I want this feature applied to all my endpoints by default if there is no overridden feature defined for the individual endpoint". Thoughts?
Jervis
> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net]
> Sent: 2007?8?29? 2:52
> To: cxf-user@incubator.apache.org
> Subject: Bus Features [was: Logging ...]
>
>
>
> On Aug 24, 2007, at 11:36 AM, Daniel Kulp wrote:
>
> > <cxf:bus>
> > <cxf:features>
> > <cxf:logging/>
> > </cxf:features>
> > </cxf:bus>
>
> How do Bus-level features interact with endpoint- or client-level
> features? For example, if I have
>
> {{{
> <cxf:bus>
> <cxf:features>
> <cxf:foo/>
> </cxf:features>
> </cxf:bus>
>
> <jaxws:endpoint name="{http://foo.bar.com}FUBAR">
> <cxf:features>
> <cxf:foo/>
> </cxf:features>
> </jaxws:endpoint>
> }}}
>
> and a servant is instantiated under the WSDL Port
> {http://foo.bar.com}
> FUBAR, is a feature instantiated twice, once for the Bus, qua
> InterceptorProvider, and once for the Endpoint, qua
> InterceptorProvider?
>
> If it's instantiated twice, is there any way a feature
> implementor to
> traverse the interceptors on each InterceptorProvider, to see if a
> feature has been installed, or are these interceptor lists
> independent of one another?
>
> (The reason I ask is, there might be a tendency to think of the
> feature config on the Bus as a kind of default, such that if a
> feature is defined at endpoint granularity, that feature is the
> effective feature in config, whereas if there is no such config at
> endpoint granularity, the runtime would fall back to the Bus
> config.
> But I'm guessing that's really not the behavior here, is it?)
>
> Thanks!
> -Fred
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland