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, 17 May 2007 14:59:33 GMT
On 5/16/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>
>
>
> > > The main point is that the endpoint/server config be
> > injected into the
> > > same thing, regardless of whether the actual frontend is JAX-WS or
> > > simple.
> > >
> > > Then we can *also* make those values available to the application
> > > programmer in a frontend-specific way, e.g. via
> > > o.a.c.jaxws.EndpointImpl.{get|set}Features(), by simply
> > delegating to
> > > the underlying Server or ServerFactoryBean or whatever.
> > >
> > > But the underlying target for injection would be the *same*
> > regardless
> > > of the frontend. And the schema and namespace etc. used for the
> > > endpoint/server would be the same also.
> > >
> > > Does that make sense?
> >
> >
> > I think so. So adding getFeatures to
> > org.apache.cxf.endpoint.Endpoint would address this, right?
>
>
> Yep, it would.
>
>
> > In any case, could a layer of indirection solve this? In the
> > case where
> > > the endpoint instance is to be injected:
> > >
> > > <bean class="FooBar">
> > >    <property name="ep"
> > > id="{http://cxf.apache.org/greeter}GreeterPort.jaxws-endpoint"/>
> > > </bean>
> > >
> > > <jaxws:endpoint
> > > id="{http://cxf.apache.org/greeter}GreeterPort.jaxws-endpoint"
> > >    <property name="server"
> > > id="{http://cxf.apache.org/greeter}GreeterPort.simple-server"/>
> > > </jaxws:endpoint>
> > >
> > > <simple:server
> > > id="http://cxf.apache.org/greeter}GreeterPort.simple-server"
> > >    <features>
> > >       </blah>
> > >    </features>
> > > </simple:server>
> > >
> > > So the application bean references the jaxws:endpoint bean, which
> > > itself references the simple:server bean. Which sortta reflects the
> > > runtime object graph too (application code -> JAX-WS
> > EndpointImpl -> Server).
> > >
> > > Then in the case where *either* a JAX-WS Endpoint or simple
> > Server are
> > > "created from API" by the application, then the following
> > config would
> > > work in either case:
> > >
> > > <simple:server id="http://cxf.apache.org/greeter}GreeterPort"
> > > createdFromAPI="true"
> > >    <features>
> > >       </blah>
> > >    </features>
> > > </simple:server>
> > >
> > > So for many applications, the same config would work
> > regardless of the
> > > frontend. Similarly for the client-side.
> >
> >
> > I don't think that would work. There would still need to be a
> > <jaxws:server> and a <simple:server>. The former would be
> > associated with a JaxWsServerFactoryBean and the later with
> > the ServerFactoryBean.
>
>
> Yep, this is true.
>
> I guess I'm wondering why we inject into the *ServerFactoryBean as
> opposed to the Server instance?


I see. It was mainly to make using the *FactoryBeans easy to use:

ServerFactoryBean sf = new ServerFactoryBean();
sf.getFeatures().add(new WSAFeature());
sf.create();

Not sure how big of a deal this is - but if we add it directly to server,
that means there is this period between creation/activation of a server and
the time when the feature gets applied. Unless we go through the extra step
of not starting the Server and then starting it after the features are
applied.

If the latter approach was taken, then I think we'd get around the
> problem as there's no JaxWsServer sub-class, i.e. the
> o.a.c.jaxws.EndpointImpl holds a reference to a Server instance.
>
>
> > They can of course still share
> > most/all of the same sub-elements.
> >
> > However, adding a layer of indirection (i.e. requiring the
> > <server> to be injected in the <endpoint>) is another
> > possible way to do it. I did it the other way for two reasons:
> > 1. The CXFServlet previously used the <endpoint/> syntax. I
> > was trying to stay close to that.
> > 2. The <server> + <endpoint> syntax requires more XML for
> > those wanting to inject an Endpoint.
>
>
> One way of looking at the extra XML required in injected Endpoint case
> is that it neatly mirrors the Endpoint createdFromAPI case, in the sense
> that there's a certain symmetry to choosing between (a) JAX-WS-specific
> code and frontend-independent config or (b) JAX-WS-specific config
> referencing frontend-independent config.
>
> Personally, I think it would be worth the indirection in the XML, if the
> config in case (a) could be reused unchanged if the application code
> were to switch frontends.


IMO the choice of frontend should only impact on application code (as
> opposed to config), unless in a sense some of what's traditionally done
> in code (e.g. the creation of the Endpoint) is instead being encoded in
> config, in which its right that config should include frontend
> specifics.


The XML would still need to change from <simple:server> to <jaxws:server>. I
also doubt people are going to really be switching frontends and I also
think the jaxws frontend will probably include more jax-ws specific options
in the future. But if thats what you're keen on, go ahead. I'm fine with
telling people to just use the <jaxws:server> syntax unless they need an
Endpoint injected.

Would you want to change the cxf-servlet.xml files to just use
<jaxws:server/> then?

- Dan


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

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