Jax Webservice LogHandler [message #989989] |
Mon, 10 December 2012 06:03  |
Eclipse User |
|
|
|
Hello all,
I have a challenge regarding the LogHandler of some WebServices.
I've a 'DatabaseLogHandler' like in the Example:
http://wiki.eclipse.org/Scout/Tutorial/3.8/webservices/Webservices_with_JAX-WS#Log_Webservice_Consumer.27s_SOAP_messages
Regarding the logged Values i need to log the WebService which is the source of a request or reply.
The target is to have an Outline in the Client for each WebService with its own logged messages.
Like in the Example I did already log the Service and Port, which contain among others the name of the WebService.
Until now im trying to extract that name and use it for the WebService-Providers to match them.
For the Consumers I've made another Constructor on which the ID (CodeType) is forwarded to the DatabaseLogHandler and use this one on the 'execInstallHandlers()' of each Consumer.
So finally the Question: is there a way to access the WebService from within the LogHandler.
By that I want to achieve a reliable source for matching, like the Constructor way [ DatabaseLogHandler(Long webServiceId) ] but with cleaner code, so I won't miss if another Developer uses the Constructor without forwarding the WebServicesID and to have a reliable Way for the WebService Provider.
Kind regards
Kris
|
|
|
|
Re: Jax Webservice LogHandler [message #991276 is a reply to message #989989] |
Tue, 18 December 2012 04:59  |
Eclipse User |
|
|
|
Hi Kris
I am not quite sure whether I understand your question correctly. Is it that you try to access the webservice provider/consumer instance from within the handler? Or is it simply to identify the underlying webservice stub to link your log with?
Its the first one I try to access the Webservice Provider/Consumer from within the handler
As you already mentioned you can access the service name through the provided SOAPMessageContext. That would be something like this:
Code: [Select all] [Show/ hide]
context.get(SOAPMessageContext.WSDL_SERVICE)
.As a result you get a QName instance with the service's name as its local part. That is not the alias that you see in Scout SDK but the name as specified in the WSDL file. The alias itself is only used at development time to link the webservice with the specific build-jaxws.xml entry to instrument the stub generation.
Yes, the "SOAPMessageContext.WSDL_SERVICE" by the provided SOAPMessageContext is the way I choose for the WebService Producer.
If not good enough it may be easiest to use a separate handler class for each of your webservices. So you exactly know which webservice the handler belongs to.
Thanks for that input, but that's not the way I'm willing to go, because it means to much code duplicates and work for each new WebService.
If you really look for a way to have the webservice instance in the handler's implementation you face the problem that in case of a webservice provider it is not available yet. Meaning that of the time your handler chain is called the instance is not created yet. So the only way to access the instance would be to propagate it back within the webservice context. This context can be injected into the implementing class by annotating a member of the type WebServiceContext with the @Resource annotation. You then put the webservice instance into its message context which in turn is accessible from within your handler.
Code: [Select all] [Show/ hide]
@Resource
private WebServiceContext context;
@Override
public void foo() {
MessageContext msgCtx = context.getMessageContext();
msgCtx.put("porttype", this);
}
But that is definitely not the way to go.
By the way, in your post you mentioned that you created a separate constructor to instantiate your webservice consumers. Indeed those consumers are OSGi services that should be obtained by SERVICES.get(xxx). To instrument the consumer simply cast the porttype into javax.xml.ws.BindingProvider which allows you to access the request context.
If I missed your question, please let me know.
Thanks for the Statement „...you face the problem that in case of a webservice provider it is not available yet." That helped a lot to keep my solution. Also my colleagues supported me in the way I used with the Constructor for Webservice Consumer and the regex name extracting for the Webservice-Provider, so I will stay with that.
Thanks Daniel for that great Support!!!
|
|
|
Powered by
FUDForum. Page generated in 0.03496 seconds