On 5/11/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
> -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: 10 May 2007 19:19 > To: [email protected] > Subject: Re: Determining the Features applied to an endpoint, > from ServerLifeCycleListener.startServer() > > On 5/8/07, Glynn, Eoghan <[EMAIL PROTECTED]> 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
