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