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 16:28:19 GMT
On 5/17/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>
>
>
> > > > 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();


there is also a sf.setStart(false); command in there as well.

The other issue Spring configuration: with the above syntax we'd have to
define two beans. The FactoryBeans are designed to encapsulate all the logic
for creation and make it as simple as possible. I guess we can work some
magic for this a DefinitionParser, but I don't really see what the advantage
is over the current approach. The ServerFactory just activates the features.
We just need to add a simple copy step
(endpoint.setActiveFeatures(getFeatures()))
to the endpoint and we should be fine, no?

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


QNames are associated with a specific class. So <jaxws:server> would be
associated with JaxWsServerFactoryBean. <simple:server> would be associated
with ServerFactoryBean. Hence we can't have one associated with two classes.
(although we can have multiple qnames associated with a single class)

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


 Well, I don't know how many of them there are... I was more thinking about
the samples and wondering if switching to <server> was what you were
proposing.

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

In the servlet case we create an endpoint internally and it just floats
around in memory as no one has direct access to it. It doesn't have to be an
jaxws Endpoint per se though - a <jaxws:server> would work as well.

The case where Endpoint is injected is more for the Spring user who is
injecting an jaxws Endpoint somewhere in his application.

- Dan

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

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