>>>>> Tim Ward <[email protected]>: > The OSGi Http Whiteboard requires your service to be registered as a > javax.servlet.Servlet. In your code snippet you register it as a > VaadinServlet, which is not part of the spec. My guess is that this is > either being handled by a Vaadin component somehow, or that the PAX > Web container goes beyond the limits of the OSGi spec.
You're right! The VaadinServlet service is probably handled by the Vaadin framework somehow. In some ways it behaves as a whiteboard servlet so Vaadin probably plays by the rules there, but there is a lot of other magic stuff going on. > The next thing to comment on is that the servlet is targeting a > specific Context. You can see what this means in the section about > Common Whiteboard Properties > <https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#service.http.whiteboard.common.properties>, > but in essence your servlet is ineligible to run unless a Servlet > Context exists with the name "frontend-karaf-demo”. Right! Creating such a context would be the first step of this message I wrote to the OPS4J mailing list on 31 March this year? Ie. the ServletContextHelper component? https://groups.google.com/d/msg/ops4j/Y8YwekymQ-Q/VF6QhzJSBgAJ (life would be so much simpler if I could just remember everything I did a couple of months back...:-) ) > You can see how to register a custom Context using Servlet Context > Properties > <https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#service.http.whiteboard.servletcontext.helper.properties>, > but my question to you is “do you actually need a custom context?”. If > you remove the context selection filter and use a servlet pattern of > “/frontend-karaf-demo/*” then you should get a servlet listening on > the correct path. That's what I ended up doing for the karaf-frontend-demo. https://github.com/steinarb/frontend-karaf-demo The reason ukelonn had a servlet context was that it was using an apache shiro filter in front of the servlet to do authentication and authorization: https://github.com/steinarb/ukelonn Also the VAADIN static resources worked a lot better with a context, because that let me serve two Vaadin applications from the same jetty instance when they were based on different Vaadin versions (if I didn't use a context Vaadin would look for resources at /VAADIN, with a context Vaadin would look for resources at /ukelonn/VAADIN) Thanks! - Steinar
