cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <>
Subject RE: Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Date Sat, 12 May 2007 09:08:59 GMT

> -----Original Message-----
> > > > 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 :-)
> >
> >
> > Would the scehma for <simple:server> be that different from 
> > <jaxws:endpoint>, or would they be close to identical?
> >
> > If the latter, IMO it would make more sense to have a 
> single generic 
> > endpoint bean type that's common to both frontends.
> They're close to identical. However, the point is that you 
> can use an <endpoint> to inject an Endpoint and a <server> to 
> inject a Server. 

Well our JAX-WS endpoint impl (i.e. org.apache.cxf.jaxws.EndpointImpl)
holds a reference internally to a Server instance, so if the injection
was to occur in the first instance into the Server instance, then the
Feature setter and getter on EndpointImpl could just look like:

    public List<AbstractFeature> getFeatures() {
        return getServer().getFeatures();

    public void setFeatures(List<AbstractFeature> features) {

So regardless of the choice of frontend, the config values would be
wired into the underlying Server instance, which could then be accessed
via the JAX-WS Endpoint if the user wishes.

Similarly on the client-side, the JaxWsClientProxy holds a reference to
the Client instance, so if the injection was to occur in the first
instance into the Client instance, it could be generic across the JAX-WS
and simple frontends. 

> I don't think its appropriate to really 
> promote the <server> syntax for JAX-WS because I think JAX-WS 
> users will want to interact with the JAX-WS Endpoint and its APIs.

But we already use <jaxws:client> when the JAX-WS terminology would be
more like "proxy" instead of "Client".

So it wouldn't necessarily be inconsistent to use "server" in the JAX-WS

Or we could come up with different more neutral synonyms for
client/proxy and server/endpoint.


View raw message