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 Thu, 17 May 2007 16:12:46 GMT
 

> > > 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.


Well I guess that approach would at least mirror what one would need to
do in the JAX-WS world to programmatically set features, i.e. something
like:

  Endpoint ep = Endpoint.create(implementor)
  ep.getFeatures().add(new MyFeature());
  ep.publish(address);

looks and smells similar to:

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


> > > 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 don't follow why this would be the case, as there's only one generic
ServerImpl, i.e. there isn't a JAX-WS subclass such as JaxWsServerImpl.

So why not just have a single generic frontend-independent namespace for
the <server> bean?

I'm probably missing something obvious here ...


> 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?


OK, I see the problem, all the deployed cxf-servlet.xml files out there
in the wild, right?

But just so that I'm sure I understand this ... in the servlet case, the
endpoint is being injected, i.e not createdFromAPI, so the
<jaxws:endpoint> bean would still be required, right? (though it could
reference a <server> bean).

Cheers,
Eoghan

Mime
View raw message