Dan Diephouse wrote:
Hi Eoghan
On 5/8/07, Glynn, Eoghan <[EMAIL PROTECTED]> 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
