You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "Glynn, Eoghan" <eo...@iona.com> on 2007/05/08 17:17:13 UTC
Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Folks,
I'd like to customize the behavior of a ServerLifeCycleListener on the
basis of the features applied to the corresponding endpoint.
Now the problem is how to determine which features have been applied to
the endpoint in question.
The problem sortta boils down to the way the feature mechanism is
specific to JAX-WS, as opposed to being common to all frontends. If I
could assume the endpoint was published via JAX-WS (as opposed to say
the simple frontend), then you'd think it would just be a simple case
of:
Public class FeatureAwareServerLifecycleListener
implements ServerLifecycleListener {
public void startServer(Server server) {
List<AbstractFeature> appliedFeatures =
((org.apache.cxf.jaxws.EndpointImpl)server.getEndpoint()).getFeatures();
//...
}
//...
}
Apart from the cast above being ugly and error-prone, it doesn't seem to
give me what I need anyway, as this endpoint is an instance of
org.apache.cxf.jaxws.support.JaxWsEndpointImpl (which doesn't expose the
applied Features) as opposed to org.apache.cxf.jaxws.EndpointImpl (which
does).
I guess I could add something like
JaxWsEndpointImpl.setFrontendEndpoint() so as to allow navigation
between the two Endpoint impls, but this approach is beginning to look
really messy, not least because JaxWsEndpointImpl is used on the
client-side also.
So it would seem more logical that the feature mechanism be made
independent of JAX-WS, so we wouldn't have to resort to the above
hoop-jumping (as the applied features would then presumably be available
from org.apache.cxf.endpoint.EndpointImpl, or maybe via the Server
instance directly instead).
So is there any reason why the <jaxws:endpoint> should be specific to
JAX-WS?
For example, are there any aspects of <jaxws:endpoint> that don't
naturally map onto say the simple frontend?
Cheers,
Eoghan
Re: Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 5/17/07, Glynn, Eoghan <eo...@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
RE: Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> > > 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();
> > > 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 ...
> 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?
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).
Cheers,
Eoghan
Re: Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 5/16/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
>
> > > 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?
>
>
> Yep, it would.
>
>
> > 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.
>
>
> 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.
If the latter approach was taken, then I think we'd get around the
> problem as there's no JaxWsServer sub-class, i.e. the
> o.a.c.jaxws.EndpointImpl holds a reference to a Server instance.
>
>
> > 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.
>
>
> 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
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?
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> > 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?
Yep, it would.
> 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.
Yep, this is true.
I guess I'm wondering why we inject into the *ServerFactoryBean as
opposed to the Server instance?
If the latter approach was taken, then I think we'd get around the
problem as there's no JaxWsServer sub-class, i.e. the
o.a.c.jaxws.EndpointImpl holds a reference to a Server instance.
> 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.
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.
> I'm rather ambivalent on changing it. But hopefully you at
> least understand why it is the way it is now :-)
Slowly becoming clearer :)
/Eoghan
Re: Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 5/15/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 14 May 2007 19:24
> > To: cxf-dev@incubator.apache.org
> > 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 <eo...@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?
>
>
> 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
RE: Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 14 May 2007 19:24
> To: cxf-dev@incubator.apache.org
> 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 <eo...@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?
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?
> 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.
Fine, as long as the applied Features accessible to the application in
some way.
> > 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?
Well, I'm happy enough with "client" ... I just brought up the "proxy"
thing to show that we don't have to stick religously with JAX-WS
terminology, and could instead name the beans in a way that was natural
for *both* the JAX-WS and simple frontends.
> 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 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.
Or am I missing something?
Cheers,
Eoghan
Re: Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Posted by Dan Diephouse <da...@envoisolutions.com>.
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 <eo...@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
RE: Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> > > > 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.
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.
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 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.
Cheers,
Eoghan
Re: Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 5/11/07, Glynn, Eoghan <eo...@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 <eo...@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
RE: Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----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 <eo...@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.
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)?
Cheers,
Eoghan
Re: Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 5/8/07, Glynn, Eoghan <eo...@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 :-)
Back to the main question of making the applied features available to a
> ServerLifeCycleListener .. are you saying the general solution would be
> to pass a reference to the underlying ServerFactoryBean to the
> org.apache.cxf.endpoint.EndpointImpl, which would have to go via the
> AbstractServiceFactoryBean.create() I guess?
No, I don't think we should keep the factorybeans around.
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.
/Eoghan
>
>
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 08 May 2007 16:54
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Determining the Features applied to an endpoint,
> > from ServerLifeCycleListener.startServer()
> >
> > Hi Eoghan
> >
> > On 5/8/07, Glynn, Eoghan <eo...@iona.com> wrote:
> > >
> > >
> > >
> > > Folks,
> > >
> > > I'd like to customize the behavior of a
> > ServerLifeCycleListener on the
> > > basis of the features applied to the corresponding endpoint.
> > >
> > > Now the problem is how to determine which features have
> > been applied
> > > to the endpoint in question.
> > >
> > > The problem sortta boils down to the way the feature mechanism is
> > > specific to JAX-WS, as opposed to being common to all
> > frontends. If I
> > > could assume the endpoint was published via JAX-WS (as
> > opposed to say
> > > the simple frontend), then you'd think it would just be a
> > simple case
> > > of:
> >
> >
> > How is it specific to JAX-WS? ClientFactoryBeans and
> > ServerFactoryBeans support features as well (get/setFeatures)
> >
> > I'm guessing that you are referring to the fact that
> > get/setFeature is on EndpointImpl and thus it hangs around
> > even after Server/Client creation.
> > Whereas in the simple frontend we simply discard the
> > *factorybeans which hold the features. The reason
> > EndpointImpl is like this is because we needed a way to set
> > the features before doing a publish. So someone can create an
> > endpoint, set the features, then publish it.
> >
> > Public class FeatureAwareServerLifecycleListener
> > > implements ServerLifecycleListener {
> > >
> > > public void startServer(Server server) {
> > > List<AbstractFeature> appliedFeatures =
> > >
> > >
> > ((org.apache.cxf.jaxws.EndpointImpl)server.getEndpoint()).getF
> > eatures();
> > > //...
> > > }
> > > //...
> > > }
> > >
> > > Apart from the cast above being ugly and error-prone, it
> > doesn't seem
> > > to give me what I need anyway, as this endpoint is an instance of
> > > org.apache.cxf.jaxws.support.JaxWsEndpointImpl (which
> > doesn't expose
> > > the applied Features) as opposed to
> > org.apache.cxf.jaxws.EndpointImpl
> > > (which does).
> > >
> > > I guess I could add something like
> > > JaxWsEndpointImpl.setFrontendEndpoint() so as to allow navigation
> > > between the two Endpoint impls, but this approach is
> > beginning to look
> > > really messy, not least because JaxWsEndpointImpl is used on the
> > > client-side also.
> > >
> > > So it would seem more logical that the feature mechanism be made
> > > independent of JAX-WS, so we wouldn't have to resort to the above
> > > hoop-jumping (as the applied features would then presumably be
> > > available from org.apache.cxf.endpoint.EndpointImpl, or
> > maybe via the
> > > Server instance directly instead).
> > >
> > > So is there any reason why the <jaxws:endpoint> should be
> > specific to
> > > JAX-WS?
> >
> >
> > Well jaxws:endpoint is specific to jaxws because it produces
> > a javax.xml.ws.Endpoint bean. The simple frontend would no
> > doubt have a <simple:server> instead because it produces a
> > Server bean.
> >
> > For example, are there any aspects of <jaxws:endpoint> that don't
> > > naturally map onto say the simple frontend?
> >
> >
> > Does the above explanation help clarify?
> >
> > I'd be +1 to keeping the features around somewhere. The CXF
> > Endpoint class sounds like a good place IMO. This could also
> > help with some of the JMX stuff Seumas was talking about I think.
> >
> > - Dan
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog
> >
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 5/8/07, Andrea Smyth <an...@iona.com> wrote:
>
>
>
> How useful is this? They reflect the state of the server at one point
> in time (i.e. service creation) - but that state may change over time.
> Unless of course you are assuming that the only interaction with a
> service that affects its functionality is via features, i.e. by
> adding/removing/toggling features. I can see how this may be a policy
> (in the sense of a coding style guide) in a customer scenario, but
> don't see how it can be enforced.
>
>
Thats a good point... On the other hand though I think it'd be handy to have
a reference to the feature so at some point again to disable it as Seumas
pointed out...
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Andrea Smyth [mailto:andrea.smyth@iona.com]
> Sent: 08 May 2007 18:41
> To: cxf-dev@incubator.apache.org
> Subject: Re: Determining the Features applied to an endpoint,
> from ServerLifeCycleListener.startServer()
>
> >> I'd like to customize the behavior of a ServerLifeCycleListener on
> >> the basis of the features applied to the corresponding endpoint.
> >>
> >> Now the problem is how to determine which features have
> been applied
> >> to the endpoint in question.
> >
> Is it not a bit dangerous to assume an endpoint provides a
> certain type of functionality because a feature has been
> applied to it?
> Everything that can be achieved by applying a feature can
> also be achieved programatically or by low level
> configuration, why should a server care about how it got to
> the point of offering e.g. reliability?
> And there is no mechanism that prevents a feature from being
> removed programatically - by that I don't mean Seamus vision
> of toggling features but the manual approach of removing
> interceptors previously added by applying the feature.
I just want the presence of the feature to trigger some action in the
ServerLifeCycleListener.startServer() callback.
This particular feature wouldn't necessarily be involved in installing
interceptors or whatever else a feature usually does in initialize().
Instead it would just be the *presence* of the feature that causes the
ServerLifeCycleListener to take a particular course of action.
I guess I could just install a do-nothing interceptor in the Feature
initialize(), and then in ServerLifeCycleListener.startServer() check if
server.getEndpoint().getInInterceptors() contains this particular
interceptor, and if so go ahead and do whatever.
On the issue of the feature or interceptor actually being removed
programmatically, I think that would be safe enough as both
ServerFactoryBean.create() and Server.start() are called as a side
effect of Endpoint.publish() in the JAX-WS case, and in the simple case
ServerFactoryBean.create() calls Server.start() directly.
By the looks of things, ServerFactoryBean.create() takes care of
applying the feature set, while Server.start() takes care of triggering
the callback on ServerLifeCycleListener.startServer(). So as far as the
app is concerned, I think these two things occur atomically, i.e. the
app would not have the opportunity to remove a feature *after* its
applied, but *before* ServerLifeCycleListener.startServer() fires.
But I'm open to correction on the fore-going, as the whole endpoint
creation logic is a bit byzantine, so I may have missed some of the
subtlety.
Cheers,
Eoghan
> >>
> >> The problem sortta boils down to the way the feature mechanism is
> >> specific to JAX-WS, as opposed to being common to all
> frontends. If I
> >> could assume the endpoint was published via JAX-WS (as
> opposed to say
> >> the simple frontend), then you'd think it would just be a
> simple case
> >> of:
> >
> >
> >
> > How is it specific to JAX-WS? ClientFactoryBeans and
> > ServerFactoryBeans support features as well (get/setFeatures)
> >
> > I'm guessing that you are referring to the fact that
> get/setFeature is
> > on EndpointImpl and thus it hangs around even after
> Server/Client creation.
> > Whereas in the simple frontend we simply discard the *factorybeans
> > which hold the features. The reason EndpointImpl is like this is
> > because we needed a way to set the features before doing a
> publish. So
> > someone can create an endpoint, set the features, then publish it.
> >
> > Public class FeatureAwareServerLifecycleListener
> >
> >> implements ServerLifecycleListener {
> >>
> >> public void startServer(Server server) {
> >> List<AbstractFeature> appliedFeatures =
> >>
> >>
> ((org.apache.cxf.jaxws.EndpointImpl)server.getEndpoint()).getF
> eatures();
> >> //...
> >> }
> >> //...
> >> }
> >>
> >> Apart from the cast above being ugly and error-prone, it
> doesn't seem
> >> to give me what I need anyway, as this endpoint is an instance of
> >> org.apache.cxf.jaxws.support.JaxWsEndpointImpl (which
> doesn't expose
> >> the applied Features) as opposed to
> org.apache.cxf.jaxws.EndpointImpl
> >> (which does).
> >>
> >> I guess I could add something like
> >> JaxWsEndpointImpl.setFrontendEndpoint() so as to allow navigation
> >> between the two Endpoint impls, but this approach is beginning to
> >> look really messy, not least because JaxWsEndpointImpl is
> used on the
> >> client-side also.
> >>
> >> So it would seem more logical that the feature mechanism be made
> >> independent of JAX-WS, so we wouldn't have to resort to the above
> >> hoop-jumping (as the applied features would then presumably be
> >> available from org.apache.cxf.endpoint.EndpointImpl, or
> maybe via the
> >> Server instance directly instead).
> >>
> >> So is there any reason why the <jaxws:endpoint> should be
> specific to
> >> JAX-WS?
> >
> >
> >
> > Well jaxws:endpoint is specific to jaxws because it produces a
> > javax.xml.ws.Endpoint bean. The simple frontend would no
> doubt have a
> > <simple:server> instead because it produces a Server bean.
> >
> > For example, are there any aspects of <jaxws:endpoint> that don't
> >
> >> naturally map onto say the simple frontend?
> >
> >
> >
> > Does the above explanation help clarify?
> >
> > I'd be +1 to keeping the features around somewhere. The CXF
> Endpoint
> > class sounds like a good place IMO. This could also help
> with some of
> > the JMX stuff Seumas was talking about I think.
>
> How useful is this? They reflect the state of the server at
> one point in time (i.e. service creation) - but that state
> may change over time.
> Unless of course you are assuming that the only interaction
> with a service that affects its functionality is via
> features, i.e. by adding/removing/toggling features. I can
> see how this may be a policy (in the sense of a coding style
> guide) in a customer scenario, but don't see how it can be enforced.
>
> Cheers,
> Andrea.
>
> >
> > - Dan
>
>
>
Re: Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Posted by Andrea Smyth <an...@iona.com>.
Dan Diephouse wrote:
> Hi Eoghan
>
> On 5/8/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>>
>>
>>
>> Folks,
>>
>> I'd like to customize the behavior of a ServerLifeCycleListener on the
>> basis of the features applied to the corresponding endpoint.
>>
>> Now the problem is how to determine which features have been applied to
>> the endpoint in question.
>
Is it not a bit dangerous to assume an endpoint provides a certain type
of functionality because a feature has been applied to it?
Everything that can be achieved by applying a feature can also be
achieved programatically or by low level configuration, why should a
server care about how it got to the point of offering e.g. reliability?
And there is no mechanism that prevents a feature from being removed
programatically - by that I don't mean Seamus vision of toggling
features but the manual approach of removing interceptors previously
added by applying the feature.
>>
>> The problem sortta boils down to the way the feature mechanism is
>> specific to JAX-WS, as opposed to being common to all frontends. If I
>> could assume the endpoint was published via JAX-WS (as opposed to say
>> the simple frontend), then you'd think it would just be a simple case
>> of:
>
>
>
> How is it specific to JAX-WS? ClientFactoryBeans and ServerFactoryBeans
> support features as well (get/setFeatures)
>
> I'm guessing that you are referring to the fact that get/setFeature is on
> EndpointImpl and thus it hangs around even after Server/Client creation.
> Whereas in the simple frontend we simply discard the *factorybeans which
> hold the features. The reason EndpointImpl is like this is because we
> needed
> a way to set the features before doing a publish. So someone can
> create an
> endpoint, set the features, then publish it.
>
> Public class FeatureAwareServerLifecycleListener
>
>> implements ServerLifecycleListener {
>>
>> public void startServer(Server server) {
>> List<AbstractFeature> appliedFeatures =
>>
>> ((org.apache.cxf.jaxws.EndpointImpl)server.getEndpoint()).getFeatures();
>> //...
>> }
>> //...
>> }
>>
>> Apart from the cast above being ugly and error-prone, it doesn't seem to
>> give me what I need anyway, as this endpoint is an instance of
>> org.apache.cxf.jaxws.support.JaxWsEndpointImpl (which doesn't expose the
>> applied Features) as opposed to org.apache.cxf.jaxws.EndpointImpl (which
>> does).
>>
>> I guess I could add something like
>> JaxWsEndpointImpl.setFrontendEndpoint() so as to allow navigation
>> between the two Endpoint impls, but this approach is beginning to look
>> really messy, not least because JaxWsEndpointImpl is used on the
>> client-side also.
>>
>> So it would seem more logical that the feature mechanism be made
>> independent of JAX-WS, so we wouldn't have to resort to the above
>> hoop-jumping (as the applied features would then presumably be available
>> from org.apache.cxf.endpoint.EndpointImpl, or maybe via the Server
>> instance directly instead).
>>
>> So is there any reason why the <jaxws:endpoint> should be specific to
>> JAX-WS?
>
>
>
> Well jaxws:endpoint is specific to jaxws because it produces a
> javax.xml.ws.Endpoint bean. The simple frontend would no doubt have a
> <simple:server> instead because it produces a Server bean.
>
> For example, are there any aspects of <jaxws:endpoint> that don't
>
>> naturally map onto say the simple frontend?
>
>
>
> Does the above explanation help clarify?
>
> I'd be +1 to keeping the features around somewhere. The CXF Endpoint
> class
> sounds like a good place IMO. This could also help with some of the JMX
> stuff Seumas was talking about I think.
How useful is this? They reflect the state of the server at one point
in time (i.e. service creation) - but that state may change over time.
Unless of course you are assuming that the only interaction with a
service that affects its functionality is via features, i.e. by
adding/removing/toggling features. I can see how this may be a policy
(in the sense of a coding style guide) in a customer scenario, but
don't see how it can be enforced.
Cheers,
Andrea.
>
> - Dan
RE: Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Posted by "Glynn, Eoghan" <eo...@iona.com>.
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?
Back to the main question of making the applied features available to a
ServerLifeCycleListener .. are you saying the general solution would be
to pass a reference to the underlying ServerFactoryBean to the
org.apache.cxf.endpoint.EndpointImpl, which would have to go via the
AbstractServiceFactoryBean.create() I guess?
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()?
/Eoghan
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 08 May 2007 16:54
> To: cxf-dev@incubator.apache.org
> Subject: Re: Determining the Features applied to an endpoint,
> from ServerLifeCycleListener.startServer()
>
> Hi Eoghan
>
> On 5/8/07, Glynn, Eoghan <eo...@iona.com> wrote:
> >
> >
> >
> > Folks,
> >
> > I'd like to customize the behavior of a
> ServerLifeCycleListener on the
> > basis of the features applied to the corresponding endpoint.
> >
> > Now the problem is how to determine which features have
> been applied
> > to the endpoint in question.
> >
> > The problem sortta boils down to the way the feature mechanism is
> > specific to JAX-WS, as opposed to being common to all
> frontends. If I
> > could assume the endpoint was published via JAX-WS (as
> opposed to say
> > the simple frontend), then you'd think it would just be a
> simple case
> > of:
>
>
> How is it specific to JAX-WS? ClientFactoryBeans and
> ServerFactoryBeans support features as well (get/setFeatures)
>
> I'm guessing that you are referring to the fact that
> get/setFeature is on EndpointImpl and thus it hangs around
> even after Server/Client creation.
> Whereas in the simple frontend we simply discard the
> *factorybeans which hold the features. The reason
> EndpointImpl is like this is because we needed a way to set
> the features before doing a publish. So someone can create an
> endpoint, set the features, then publish it.
>
> Public class FeatureAwareServerLifecycleListener
> > implements ServerLifecycleListener {
> >
> > public void startServer(Server server) {
> > List<AbstractFeature> appliedFeatures =
> >
> >
> ((org.apache.cxf.jaxws.EndpointImpl)server.getEndpoint()).getF
> eatures();
> > //...
> > }
> > //...
> > }
> >
> > Apart from the cast above being ugly and error-prone, it
> doesn't seem
> > to give me what I need anyway, as this endpoint is an instance of
> > org.apache.cxf.jaxws.support.JaxWsEndpointImpl (which
> doesn't expose
> > the applied Features) as opposed to
> org.apache.cxf.jaxws.EndpointImpl
> > (which does).
> >
> > I guess I could add something like
> > JaxWsEndpointImpl.setFrontendEndpoint() so as to allow navigation
> > between the two Endpoint impls, but this approach is
> beginning to look
> > really messy, not least because JaxWsEndpointImpl is used on the
> > client-side also.
> >
> > So it would seem more logical that the feature mechanism be made
> > independent of JAX-WS, so we wouldn't have to resort to the above
> > hoop-jumping (as the applied features would then presumably be
> > available from org.apache.cxf.endpoint.EndpointImpl, or
> maybe via the
> > Server instance directly instead).
> >
> > So is there any reason why the <jaxws:endpoint> should be
> specific to
> > JAX-WS?
>
>
> Well jaxws:endpoint is specific to jaxws because it produces
> a javax.xml.ws.Endpoint bean. The simple frontend would no
> doubt have a <simple:server> instead because it produces a
> Server bean.
>
> For example, are there any aspects of <jaxws:endpoint> that don't
> > naturally map onto say the simple frontend?
>
>
> Does the above explanation help clarify?
>
> I'd be +1 to keeping the features around somewhere. The CXF
> Endpoint class sounds like a good place IMO. This could also
> help with some of the JMX stuff Seumas was talking about I think.
>
> - Dan
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
Re: Determining the Features applied to an endpoint, from ServerLifeCycleListener.startServer()
Posted by Dan Diephouse <da...@envoisolutions.com>.
Hi Eoghan
On 5/8/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
>
> Folks,
>
> I'd like to customize the behavior of a ServerLifeCycleListener on the
> basis of the features applied to the corresponding endpoint.
>
> Now the problem is how to determine which features have been applied to
> the endpoint in question.
>
> The problem sortta boils down to the way the feature mechanism is
> specific to JAX-WS, as opposed to being common to all frontends. If I
> could assume the endpoint was published via JAX-WS (as opposed to say
> the simple frontend), then you'd think it would just be a simple case
> of:
How is it specific to JAX-WS? ClientFactoryBeans and ServerFactoryBeans
support features as well (get/setFeatures)
I'm guessing that you are referring to the fact that get/setFeature is on
EndpointImpl and thus it hangs around even after Server/Client creation.
Whereas in the simple frontend we simply discard the *factorybeans which
hold the features. The reason EndpointImpl is like this is because we needed
a way to set the features before doing a publish. So someone can create an
endpoint, set the features, then publish it.
Public class FeatureAwareServerLifecycleListener
> implements ServerLifecycleListener {
>
> public void startServer(Server server) {
> List<AbstractFeature> appliedFeatures =
>
> ((org.apache.cxf.jaxws.EndpointImpl)server.getEndpoint()).getFeatures();
> //...
> }
> //...
> }
>
> Apart from the cast above being ugly and error-prone, it doesn't seem to
> give me what I need anyway, as this endpoint is an instance of
> org.apache.cxf.jaxws.support.JaxWsEndpointImpl (which doesn't expose the
> applied Features) as opposed to org.apache.cxf.jaxws.EndpointImpl (which
> does).
>
> I guess I could add something like
> JaxWsEndpointImpl.setFrontendEndpoint() so as to allow navigation
> between the two Endpoint impls, but this approach is beginning to look
> really messy, not least because JaxWsEndpointImpl is used on the
> client-side also.
>
> So it would seem more logical that the feature mechanism be made
> independent of JAX-WS, so we wouldn't have to resort to the above
> hoop-jumping (as the applied features would then presumably be available
> from org.apache.cxf.endpoint.EndpointImpl, or maybe via the Server
> instance directly instead).
>
> So is there any reason why the <jaxws:endpoint> should be specific to
> JAX-WS?
Well jaxws:endpoint is specific to jaxws because it produces a
javax.xml.ws.Endpoint bean. The simple frontend would no doubt have a
<simple:server> instead because it produces a Server bean.
For example, are there any aspects of <jaxws:endpoint> that don't
> naturally map onto say the simple frontend?
Does the above explanation help clarify?
I'd be +1 to keeping the features around somewhere. The CXF Endpoint class
sounds like a good place IMO. This could also help with some of the JMX
stuff Seumas was talking about I think.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog