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 Thu, 10 May 2007 18:18:59 GMT
On 5/8/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>
>
>
>
> By the mechanism being specific to JAX-WS, I meant that this frontend
> provides the only way of wiring features in from configuration.
>
> I didn't realize that an analogous <simple:server> approach can be used
> with the simple frontend. Can you point me at a test/demo?


I haven't actually supported the <simple:server> syntax yet. I was simply
drawing a distinction between EndpointImpl and *ServerFactorys. The one
produces Endpoints. The other produces Servers. Hence their names :-)

Back to the main question of making the applied features available to a
> ServerLifeCycleListener .. are you saying the general solution would be
> to pass a reference to the underlying ServerFactoryBean to the
> org.apache.cxf.endpoint.EndpointImpl, which would have to go via the
> AbstractServiceFactoryBean.create() I guess?


No, I don't think we should keep the factorybeans around.

Or to add a new setFeautures() method to
> org.apache.cxf.endpoint.EndpointImpl, which is then called by
> ServerFactoryBean.create() on the endpoint created via
> AbstractServiceFactoryBean.create()?



Yes. I think your suggestion to create the *Features around is a good one
and we should maybe add a org.apache.cxf.endpoint.Endpoint.getFeatures()
method. This would only contain the active features I would think.

/Eoghan
>
>
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 08 May 2007 16:54
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Determining the Features applied to an endpoint,
> > from ServerLifeCycleListener.startServer()
> >
> > 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()).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.
> >
> > - Dan
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog
> >
>



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

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