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 Fri, 11 May 2007 21:23:14 GMT
On 5/11/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 10 May 2007 19:19
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Determining the Features applied to an endpoint,
> > from ServerLifeCycleListener.startServer()
> >
> > On 5/8/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
> > >
> > >
> > >
> > >
> > > 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. 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.

Hence, I wrote docs on <endpoint>, not <server>.

Does that make sense? I agree that there is some suckiness here, but I'm not
100% sure what to do about it.

That way the choice of frontend wouldn't be burned into config as well
> as application code. Also it might be more convenient for injecting
> values into endpoints created independently of _either_ JAX-WS or
> simple, e.g. the internal endpoints used by RM for out-of-band
> messaging.
>
>
> > > Or to add a new setFeautures() method to
> > > org.apache.cxf.endpoint.EndpointImpl, which is then called by
> > > ServerFactoryBean.create() on the endpoint created via
> > > AbstractServiceFactoryBean.create()?
> >
> >
> >
> > Yes. I think your suggestion to create the *Features around
> > is a good one and we should maybe add a
> > org.apache.cxf.endpoint.Endpoint.getFeatures()
> > method. This would only contain the active features I would think.
>
> The "active" features being just the features applied to this endpoint,
> or the applied features not yet disable()d (via the
> Feature.enable/disable() mechanism proposed by Seumas)?
>
> I was thinking that later, but am not confident that that is the correct
approach yet. I think it may make sense to keep all the features around as
well so you could reenable a feature easily at some later point. Maybe
getEnabledFeatures/getDisabledFeatures?

Cheers,
- Dan


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

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