Thanks for the link, Carsten - I’ve had a look and, as you mentioned, the way Sling is mounting servlets isn’t comparable to how it’s done in a straight forward web-app.
I’ve been digging through the code of org.apache.felix.http.(proxy | bridge) and debugging to see how it all fits together. As far as I can understand there is no way that the proxy+bridge can work if the ProxyServlet isn’t bound to “/*”. I’d be happy to be proven wrong though :) Maybe it’s possible to do some fancy HttpServletRequestWrapper hacking in order to pass on the request to the DispatcherServlet *without* the ProxyServlet path? I’ve created a reference projekt @ https://github.com/metamorph/http-osgi-bridge <https://github.com/metamorph/http-osgi-bridge> that illustrates the issue. It embeds and starts Felix from the web-application then loads a set of bundles to enable the bridge component. It would be great if you’d check my sample code and let me know if I’m doing something horribly wrong :) Best regards //Anders > On 04 Feb 2016, at 17:26, Carsten Ziegeler <cziege...@apache.org> wrote: > > Anders Engström wrote >> Hi, thanks for replying - >> >> that’s interesting.. code you provide a pointer to some sample code? > > The code for Sling can be found at: > > http://svn.apache.org/repos/asf/sling/trunk/launchpad/base/ > <http://svn.apache.org/repos/asf/sling/trunk/launchpad/base/> > > It's a whole module and more complicated than what you probably need, > but maybe it gives you a good hint > > Carsten > >> >> /Anders >> >>> On 04 Feb 2016, at 16:45, Carsten Ziegeler <cziege...@apache.org> wrote: >>> >>> Hi, >>> >>> I dont know the details, but we use the bridge in Apache Sling and in >>> some other projects. And if we register a servlet at /demo it's not >>> directly reachable at /demo, but /context/{servlet}/demo >>> >>> Carsten >>> >>> Anders Engström wrote >>>> Hi - >>>> >>>> I’m trying to set up the Felix Servlet Bridge in Tomcat (8) as a proxy to >>>> a bunch of services running in an embedded OSGi container. >>>> >>>> I’ve registered the >>>> `org.apache.felix.http.proxy.impl.ProxyServletContextListener` in web.xml >>>> and I’ve got a servlet setup that uses the >>>> `org.apache.felix.http.proxy.DispatcherTracker` to dispatch request to the >>>> bridge (which is installed in the OSGi container). >>>> >>>> The reason I’m using a custom servlet is because our OSGi container isn’t >>>> started until after the web-application have started (and the >>>> org.apache.felix.http.proxy.ProxyServlet requires that the BundleContext >>>> is defined on servlet initiation). >>>> >>>> Everything seems to work, if I register servlets (in the OSGi container) >>>> to the path `/bundles/{servlet}`. That is — the OSGi component registering >>>> the Servlet *needs* to know to which context path the proxy servlet is >>>> mapped. >>>> >>>> Is this by design, or did I miss some configuration setting or did I do >>>> something wrong in my setup? >>>> >>>> The behaviour I was expecting was that when registering the servlet like >>>> this: >>>> >>>> `httpService.registerServlet(“/demo”, theServlet, null, null);` >>>> >>>> a call, through Tomcat, to `http://host:port/context/bundles/demo` >>>> <http://host:port/context/bundles/demo`> >>>> <http://host:port/context/bundles/demo` >>>> <http://host:port/context/bundles/demo`>> >>>> <http://host:port/context/bundles/demo%60 >>>> <http://host:port/context/bundles/demo%60> >>>> <http://host:port/context/bundles/demo%60 >>>> <http://host:port/context/bundles/demo%60>>> would be dispatched to the >>>> `theServlet`. >>>> >>>> If the component registering the Servlet needs to know the servlet-path of >>>> the proxy-servlet it’s really hard to make the servlet portable across >>>> different HttpService implementations :/ >>>> >>>> Best regards //Anders >>>> >>> >>> >>> >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> cziege...@apache.org <mailto:cziege...@apache.org> >>> <mailto:cziege...@apache.org <mailto:cziege...@apache.org>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>> <mailto:users-unsubscr...@felix.apache.org> >>> <mailto:users-unsubscr...@felix.apache.org >>> <mailto:users-unsubscr...@felix.apache.org>> >>> For additional commands, e-mail: users-h...@felix.apache.org >>> <mailto:users-h...@felix.apache.org> <mailto:users-h...@felix.apache.org >>> <mailto:users-h...@felix.apache.org>> >> > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org <mailto:cziege...@apache.org> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > <mailto:users-unsubscr...@felix.apache.org> > For additional commands, e-mail: users-h...@felix.apache.org > <mailto:users-h...@felix.apache.org>
