Home » Archived » Eclipse SmartHome » javax.xml.ws.Endpoint & org.osgi.service.http.HttpService(How to remove EndpointContext from the http server?)
| javax.xml.ws.Endpoint & org.osgi.service.http.HttpService [message #1703235] |
Wed, 29 July 2015 15:24  |
 Karel Goderis
Messages: 198
Registered: March 2014 |
Senior Member |
|
|
Hi all,
I am bit struggling with the following topic. I am by no means an expert on servlets and alike, and nor do I know this part of the core ESH code very well.
As far as I understand, when you use javax.xml.ws.* web services in Java, you basically register - in my usecase SOAP - services on the set http server in the JVM. As far as I understand, in ESH, this is provided by org.osgi.service.http.HttpService, right?
I have a binding for which the Thing Handler is basically a web service that publishes its service using Endpoint.publish() on a URL, which is something like openhabserver:portnumber/notification , with each Thing having its own portnumber (to keep communication flows apart).
The service stack on the physical device (in this case, a videophone) is configured through a series of calls, and basically it is told where to publish events, e.g openhabserver:portnumber/notification. However, when the videophone is reconfigured, or looses power, it kinda resets all its communications stacks, and thus it also looses the information where to publish its event data. In other words, the whole configuration handshaking process of the Thing Handler has to be done over again
the Thing Handler can detect this situation, and could do a dispose()/initialize() sequence to get things going again. However, when doing so, I get things like
2015-07-28 20:09:54 [ERROR] [b.helios.handler.HeliosHandler:174 ] - An exception occurred while setting up the notification consumer webservice: Server Runtime Error: java.lang.IllegalArgumentException: Context with URL path /notification already exists on the server /192.168.0.5:8502
e.g. the server implementation of ESH does not allow to re-use the context of the Endpoint. Note that the Endpoint.stop() method is called before
There are a few quick solutions to this problem:
1. use a different url, like /notification-something
2. use a different port number, like portnumber+1, +2, ... until you find a port that works/is free
The better solution would be to remove the offending Context, but I don't know how this can be done (cfr org.osgi.service.http.HttpService), let alone if it can be done.
Strangely enough, when I google the exception.message() nothing shows up, so, I do not even know where to look.
Any help or ideas are appreciated
Karel
|
|
| | |
| Re: javax.xml.ws.Endpoint & org.osgi.service.http.HttpService [message #1703412 is a reply to message #1703400] |
Fri, 31 July 2015 11:53  |
Karel Goderis
Messages: 198
Registered: March 2014 |
Senior Member |
|
|
Yes I did but I very often do an "rm -rf *" of my brain to make room for new stuff
I have investigated it, and as far as I conceptually understand, Servlets are one layer down compared to WebServices. Servlets rather focus on the (HTTP) protocol part, whereas the WebServices focuses on the SOAP part (and JAXB etc for message handling) I have searched it but could not find a way to build a WebService with Servlets without writing a complete SOAP message handler myself. Given that on top of that I am using WS-Notification (as the videophone is only speaking that stuff), and that this implementation is available in an CXF jar, and is exposing it interfaces specifically as a WebService (XML namespace etc), I am not inclined to rewrite the binding for the sake of having one webserver. It was a very complicated thing to do the first time around.
Basically, I have given up on resetting the Context of the webserver, and rather went for the option to use a different URL. Less beautiful, but it works
|
|
|
| Re: javax.xml.ws.Endpoint & org.osgi.service.http.HttpService [message #1703498 is a reply to message #1703412] |
Sat, 01 August 2015 13:09 |
Karel Goderis
Messages: 198
Registered: March 2014 |
Senior Member |
|
|
I spent some more time on this subject, and basically, if one steps out of the ordinary WebServices stuff (that is, using web.xml for declaring services, and deploying on a standard servlet container server like tomcat or websphere), then things are a bit more complicated. In the ordinary case with tomcat and others, it is the server that will take on an HTTP request, then instantiate the servlet, contain it in a container, and have the request handled. If you on the other hand want to define your servlets beforehand, and be ready to handle HTTP requests, the whole point is that one needs to find a servlet transport mechanism that can host the WebService. And there are not many options, with in fact the only one being referenced is the Apache CXF Servlet that is Spring disabled. It looks more as a dirty hack than anything else, but one does not have any other option, as there is no real servlet container implementation in javax(.servlet). Well, there is, e.g. the HttpServlet, but if you opt for that, then you need to do write your own SOAP handler to deal with WebServices.
I will give it a try to have the Helios Thing Handlers bind the OSGi HttpService, and have them register themselves as Servlets on the already present Jetty. I am curious how this work in term of life-time management, e.g. HttpService being available, or not and so forth.
In any case, the standard javax.ws API is working well, e.g. it creates a light and standard Sun provided http server, which is maybe not ideal, but it works wonderfully well.
Maybe one day we will provide not only a full REST interface to OH, but maybe also a full SOAP WebService interface so that OH can be interconnected with other services or parties. 
|
|
|
Goto Forum:
Current Time: Sat Apr 20 02:47:41 GMT 2024
Powered by FUDForum. Page generated in 0.02940 seconds |
] 
Search
Help
Register
Login
Home
