On 5/15/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
> -----Original Message-----
> From: Dan Diephouse [mailto:[EMAIL PROTECTED]
> Sent: 14 May 2007 19:24
> To: [email protected]
> Subject: Re: Determining the Features applied to an endpoint,
> from ServerLifeCycleListener.startServer()
>
> 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 <[EMAIL PROTECTED]> 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?
I guess I see that as an implementation detail.
The main point is that the endpoint/server config be injected into the
same thing, regardless of whether the actual frontend is JAX-WS or
simple.
Then we can *also* make those values available to the application
programmer in a frontend-specific way, e.g. via
o.a.c.jaxws.EndpointImpl.{get|set}Features(), by simply delegating to
the underlying Server or ServerFactoryBean or whatever.
But the underlying target for injection would be the *same* regardless
of the frontend. And the schema and namespace etc. used for the
endpoint/server would be the same also.
Does that make sense?
I think so. So adding getFeatures to org.apache.cxf.endpoint.Endpoint would
address this, right?
> 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...
OK, I see now where you're coming from.
I was more thinking of the case where the endpoint is created
programmatically by the application, via Endpoint.create()/publish() or
ServerFactoryBean.create(), as opposed to the endpoint instance *itself*
being injected into application code.
On a side issue, would that style of endpoint injection into another
bean make sense in the context of "createdFromAPI", as presumably the
injected endpoint wouldn't have been created via a programmatic call to
an API such as Endpoint.create()?
In that case createdFromAPI would be "false". Spring would be fully in
control .
In any case, could a layer of indirection solve this? In the case where
the endpoint instance is to be injected:
<bean class="FooBar">
<property name="ep"
id="{http://cxf.apache.org/greeter}GreeterPort.jaxws-endpoint"/>
</bean>
<jaxws:endpoint
id="{http://cxf.apache.org/greeter}GreeterPort.jaxws-endpoint";
<property name="server"
id="{http://cxf.apache.org/greeter}GreeterPort.simple-server"/>
</jaxws:endpoint>
<simple:server
id="http://cxf.apache.org/greeter}GreeterPort.simple-server";
<features>
</blah>
</features>
</simple:server>
So the application bean references the jaxws:endpoint bean, which itself
references the simple:server bean. Which sortta reflects the runtime
object graph too (application code -> JAX-WS EndpointImpl -> Server).
Then in the case where *either* a JAX-WS Endpoint or simple Server are
"created from API" by the application, then the following config would
work in either case:
<simple:server id="http://cxf.apache.org/greeter}GreeterPort";
createdFromAPI="true"
<features>
</blah>
</features>
</simple:server>
So for many applications, the same config would work regardless of the
frontend. Similarly for the client-side.
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. They can of
course still share most/all of the same sub-elements.
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.
I'm rather ambivalent on changing it. But hopefully you at least understand
why it is the way it is now :-)
Regards,
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
