cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Date Tue, 08 May 2007 15:54:07 GMT
Hi Eoghan

On 5/8/07, Glynn, Eoghan <eoghan.glynn@iona.com> 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.
>
> 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
> 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.

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

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