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 Mon, 14 May 2007 18:24:16 GMT
Hi Eoghan,

Apologies for slacking on this thread here - J1 was keeping me away from
email, but I should be much more on top of things this week!

On 5/12/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>
>
> >
> > 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.
>
>
> Well our JAX-WS endpoint impl (i.e. org.apache.cxf.jaxws.EndpointImpl)
> holds a reference internally to a Server instance, so if the injection
> was to occur in the first instance into the Server instance, then the
> Feature setter and getter on EndpointImpl could just look like:
>
>     public List<AbstractFeature> getFeatures() {
>         return getServer().getFeatures();
>     }
>
>     public void setFeatures(List<AbstractFeature> features) {
>         getServer().setFeatures(features);
>     }
>
> So regardless of the choice of frontend, the config values would be
> wired into the underlying Server instance, which could then be accessed
> via the JAX-WS Endpoint if the user wishes.


Except, we need to inject those features into the serverfactorybean - which
is pretty much what the JAX-WS EndpoitnImpl does now. Or am I missing the
point here?

Similarly on the client-side, the JaxWsClientProxy holds a reference to
> the Client instance, so if the injection was to occur in the first
> instance into the Client instance, it could be generic across the JAX-WS
> and simple frontends.


I don't think that we would want to set the features on the Server. Features
could be applied to both the Client & Server, so it seems like it'd be
better to put it on the org.apache.cxf.endpoint.Endpoint interface.

> 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.
>
>
> But we already use <jaxws:client> when the JAX-WS terminology would be
> more like "proxy" instead of "Client".
>

So it wouldn't necessarily be inconsistent to use "server" in the JAX-WS
> case.
>
> Or we could come up with different more neutral synonyms for
> client/proxy and server/endpoint.


Yeah, the client side doesn't line up with the *factorybeans :-\. Apologies
to everyone for my short sightedness on that. We could possibly deprecate
<jaxws:client> and add support for <jaxws:proxy/> instead. Thoughts?

To me, its not so much a terminology thing as it is an injection thing. In
the one case I might want to inject a JAXWS endpoint:

public class FooBar {
  private Endpoint ep;
  get/setEndpoint()
}

Then I'd want a spring config like:
<bean class="FooBar">
  <property name="ep" id="myEndpoint"/>
</bean>
<jaxws:endpoint id="myEndpoint" ..../>

In another I'd want a Server:

public class FooBar {
  private Server server;
  get/setServer()
}

<bean class="FooBar">
  <property name="server" id="myServer"/>
</bean>
<jaxws:server id="myServer" ..../>

Are you saying we shouldn't have support for both of these options? On the
simple frontend we obviously only need support for just the server syntax,
because there is no custom Endpoint class which we might want to interact
with. However I think its definitely a requirement that we are able to
inject a JAX-WS Endpoint into a class. We could maybe get rid of the
<jaxws:server> though as you could do a endpoint.getServer() if you need it.

Does that clarify what I was trying to say earlier? Or were you trying to
make another point? Unfortunately, I'm a little bit confused at this point
where we're directing this thread...

I'll try and create a concrete proposal for the features in a separate
thread so we can all get on the same page with regards to disable/enable,
getName(), etc.

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

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