cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Smyth <>
Subject Re: Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Date Tue, 08 May 2007 17:40:35 GMT
Dan Diephouse wrote:

> Hi Eoghan
> On 5/8/07, Glynn, Eoghan <> wrote:
>> Folks,
>> I'd like to customize the behavior of a ServerLifeCycleListener on the
>> basis of the features applied to the corresponding endpoint.
>> Now the problem is how to determine which features have been applied to
>> the endpoint in question.
Is it not a bit dangerous to assume an endpoint provides a certain type 
of functionality because a feature has been applied to it?
Everything that can be achieved by applying a feature can also be 
achieved programatically or by low level configuration, why should a 
server care about how it got to the point of offering e.g. reliability?
And there is no mechanism that prevents a feature from being removed 
programatically - by that I don't mean Seamus vision of toggling 
features but the manual approach of removing interceptors previously 
added by applying the feature.

>> The problem sortta boils down to the way the feature mechanism is
>> specific to JAX-WS, as opposed to being common to all frontends. If I
>> could assume the endpoint was published via JAX-WS (as opposed to say
>> the simple frontend), then you'd think it would just be a simple case
>> of:
> How is it specific to JAX-WS?  ClientFactoryBeans and ServerFactoryBeans
> support features as well (get/setFeatures)
> I'm guessing that you are referring to the fact that get/setFeature is on
> EndpointImpl and thus it hangs around even after Server/Client creation.
> Whereas in the simple frontend we simply discard the *factorybeans which
> hold the features. The reason EndpointImpl is like this is because we 
> needed
> a way to set the features before doing a publish. So someone can 
> create an
> endpoint, set the features, then publish it.
> Public class FeatureAwareServerLifecycleListener
>>     implements ServerLifecycleListener {
>>     public void startServer(Server server) {
>>         List<AbstractFeature> appliedFeatures =
>> ((org.apache.cxf.jaxws.EndpointImpl)server.getEndpoint()).getFeatures();
>>         //...
>>     }
>>     //...
>> }
>> Apart from the cast above being ugly and error-prone, it doesn't seem to
>> give me what I need anyway, as this endpoint is an instance of
>> (which doesn't expose the
>> applied Features) as opposed to org.apache.cxf.jaxws.EndpointImpl (which
>> does).
>> I guess I could add something like
>> JaxWsEndpointImpl.setFrontendEndpoint() so as to allow navigation
>> between the two Endpoint impls, but this approach is beginning to look
>> really messy, not least because JaxWsEndpointImpl is used on the
>> client-side also.
>> So it would seem more logical that the feature mechanism be made
>> independent of JAX-WS, so we wouldn't have to resort to the above
>> hoop-jumping (as the applied features would then presumably be available
>> from org.apache.cxf.endpoint.EndpointImpl, or maybe via the Server
>> instance directly instead).
>> So is there any reason why the <jaxws:endpoint> should be specific to
>> JAX-WS?
> Well jaxws:endpoint is specific to jaxws because it produces a
> bean. The simple frontend would no doubt have a
> <simple:server> instead because it produces a Server bean.
> For example, are there any aspects of <jaxws:endpoint> that don't
>> naturally map onto say the simple frontend?
> Does the above explanation help clarify?
> I'd be +1 to keeping the features around somewhere. The CXF Endpoint 
> class
> sounds like a good place IMO. This could also help with some of the JMX
> stuff Seumas was talking about I think.

How useful is this?  They reflect the state of the server at one point 
in time  (i.e. service creation) - but that state may change over time.
Unless of course you are assuming that the only interaction with a 
service that affects its functionality is via features, i.e. by 
adding/removing/toggling features. I can see how this may be a policy 
(in the sense of a coding style guide)  in a customer scenario,  but 
don't see how it can be enforced.


> - Dan

View raw message