cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Date Wed, 09 May 2007 10:12:18 GMT


> -----Original Message-----
> From: Andrea Smyth [mailto:andrea.smyth@iona.com] 
> Sent: 08 May 2007 18:41
> To: cxf-dev@incubator.apache.org
> Subject: Re: Determining the Features applied to an endpoint, 
> from ServerLifeCycleListener.startServer()
>
> >> 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.


I just want the presence of the feature to trigger some action in the
ServerLifeCycleListener.startServer() callback.

This particular feature wouldn't necessarily be involved in installing
interceptors or whatever else a feature usually does in initialize().
Instead it would just be the *presence* of the  feature that causes the
ServerLifeCycleListener to take a particular course of action.

I guess I could just install a do-nothing interceptor in the Feature
initialize(), and then in ServerLifeCycleListener.startServer() check if
server.getEndpoint().getInInterceptors() contains this particular
interceptor, and if so go ahead and do whatever.

On the issue of the feature or interceptor actually being removed
programmatically, I think that would be safe enough as both
ServerFactoryBean.create() and Server.start() are called as a side
effect of Endpoint.publish() in the JAX-WS case, and in the simple case
ServerFactoryBean.create() calls Server.start() directly. 

By the looks of things, ServerFactoryBean.create() takes care of
applying the feature set, while Server.start() takes care of triggering
the callback on ServerLifeCycleListener.startServer(). So as far as the
app is concerned, I think these two things occur atomically, i.e. the
app would not have the opportunity to remove a feature *after* its
applied, but *before* ServerLifeCycleListener.startServer() fires. 

But I'm open to correction on the fore-going, as the whole endpoint
creation logic is a bit byzantine, so I may have missed some of the
subtlety.

Cheers,
Eoghan
 
> >>
> >> 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()).getF
> eatures();
> >>         //...
> >>     }
> >>     //...
> >> }
> >>
> >> 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 
> >> org.apache.cxf.jaxws.support.JaxWsEndpointImpl (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 
> > javax.xml.ws.Endpoint 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.
> 
> Cheers,
> Andrea.
> 
> >
> > - Dan
> 
> 
> 

Mime
View raw message