An update... I found this:
http://www.tuckey.org/urlrewrite It's a servlet filter that does all kinds of rewrites. It solves all the problems with legacy URL's I have. Really neat. I also found an OSGI wrapped version of this on maven central. Just use this: <dependency> > <groupId>org.apache.servicemix.bundles</groupId> > <artifactId>org.apache.servicemix.bundles.urlrewritefilter</artifactId> > <version>4.0.4_1</version> > </dependency> I also subclassed the UrlRewriteFilter class to make it possible to load the configuration from a string that I construct at runtime using configuration properties. All is well, /Bengt 2016-11-10 17:31 GMT+01:00 Bengt Rodehav <[email protected]>: > I now managed to get this working. > > I stopped using the Jetty handler for publishing resources from the > filesystem. Instead I created a Servlet for that purpose. Hope Java with > NIO is performant enough. > > Using that approach it is possible to have overlapping URL's. Servlets > allow it. > > Thanks for all your help! > > The one remaining problem for my now is to have aliases for some of my > URL's for backward compatibility reasons. E g the previous vendor used: > > .../index.php > > while we use: > > .../index.html > > Also the previous vendor used: > > .../index.php/fund?id=xyz > > while we use: > > .../index.html/fund.html?isin=xyz > > I've been trying to get Jetty's RewriteHandler to work but can't figure it > out. I can have it process my URL's but the replacement URL is never found > (I get a 404). > > Maybe there is a trick in Pax-Web for this? Or some fallback Servlet I can > create that forwards/redirects/rewrites (not exactly sure which term is > correct) the old URL's to the new URL's. Also sounds like a pretty common > problem since one often need to support legacy URL's. > > /Bengt > > /Bengt > > > 2016-11-10 16:12 GMT+01:00 'Achim Nierbeck' via OPS4J < > [email protected]>: > >> The thing is not really two servlets (but for those it's the same) it >> isn't possible to have two different connection handlers, which you have >> right now. >> >> So if you want to have a chain of responsibility, you'll need servlets >> and filters, those you can chain. Filters can always be in a pre and post >> mode. >> >> Regarding moving static content to the outside world ... 20 years ago >> you'd done that to have performance improvments. Nowadays, modern cpus and >> java are fast enough so you don't need to care anymore. >> When using different handlers you can't use filters etc for those >> resources registered via different handlers, as those aren't chained. >> >> hope that helps :) >> >> regards, Achim >> >> >> >> >> 2016-11-10 16:00 GMT+01:00 Bengt Rodehav <[email protected]>: >> >>> It seems like a general problem and not just a Pax-Web problem. It is >>> probably not possible to have two servlets with overlapping context paths. >>> Although I think it should be possible if one could control the order in >>> which they are invoked. >>> >>> Strange, I would think that this would be a pretty normal thing. >>> >>> You seem to be very knowledgable about servlets. How does the actual >>> invoking of a servlet work? Is it possible to have a chain where one >>> servlet leaves the request unhandled to be passed on to the next? If not, >>> then I guess it's Jetty internals that decide what servlet to invoke. >>> >>> Would a workaround be to move all my static files out of the bundle and >>> not use the registerResources() method at all but only use jetty.xml >>> and org.eclipse.jetty.server.handler.ResourceHandler. Would I loose any >>> Pax-Web functionality this way? >>> >>> /Bengt >>> >>> >>> 2016-11-10 15:35 GMT+01:00 'Achim Nierbeck' via OPS4J < >>> [email protected]>: >>> >>>> ok, at least #1 is solved ... that one worried me. >>>> >>>> Using "/" for the HttpService in conjunction with aliases plus an extra >>>> handler on the same context path ... seems hard to achieve. I fear we need >>>> an issue for this. >>>> Combining two handlers on the same context path seems to be a bit >>>> tricky right now. >>>> >>>> regards, Achim >>>> >>>> >>>> 2016-11-10 15:16 GMT+01:00 Bengt Rodehav <[email protected]>: >>>> >>>>> An update on this problem... >>>>> >>>>> Problem #1 was not a problem but a bug in my code. I created the "//" >>>>> (double slash) all by myself. Sorry for the buzz. >>>>> >>>>> Problem #2 however still exists. If I register resources on the root >>>>> url using >>>>> >>>>> mWebService.registerResources("/", "/webroot", mHttpContext); >>>>> >>>>> Then I cannot publish any resources using jetty.xml and >>>>> org.eclipse.jetty.server.handler.ResourceHandler. >>>>> >>>>> Pax-Web's resource handler does not seem to pass the request on to the >>>>> handler I register in jetty.xml. >>>>> >>>>> So my problem is that I need to accomplish both of these things at the >>>>> same time: >>>>> >>>>> - Map "/logo" to a normal directory using jetty.xml and >>>>> org.eclipse.jetty.server.handler.ResourceHandler >>>>> - Map "/" to the "/webroot" directory in my bundle using the >>>>> registerResources() method. >>>>> >>>>> How can I accomplish this? >>>>> >>>>> I did try to use "insertRule" in my jetty.xml instead of "addHandler" >>>>> since I hoped that this would put the "/logo" rule first. However, this >>>>> syntax does not seem to be supported. >>>>> >>>>> /Bengt >>>>> >>>>> 2016-11-09 8:58 GMT+01:00 Bengt Rodehav <[email protected]>: >>>>> >>>>>> OK - thanks. >>>>>> >>>>>> Finally got you :-) >>>>>> >>>>>> /Bengt >>>>>> >>>>>> 2016-11-08 21:27 GMT+01:00 'Achim Nierbeck' via OPS4J < >>>>>> [email protected]>: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> regarding registering resources on "/" ... I'd expect it to work in >>>>>>> the way you describe it, but you might have found a bug there. >>>>>>> The thing about the "/" - context, is. It is special. Since all >>>>>>> HttpService registered "resources" are registered with this as the >>>>>>> context >>>>>>> ... So it might be that an additional context from outside doesn't play >>>>>>> along. Will need to test. >>>>>>> >>>>>>> regards, Achim >>>>>>> >>>>>>> >>>>>>> 2016-11-08 8:58 GMT+01:00 Bengt Rodehav <[email protected]>: >>>>>>> >>>>>>>> Hi again Achim, >>>>>>>> >>>>>>>> I'm not exactly sure how you mean. The way I register my resources >>>>>>>> is via the WebContainer (which I get with iPojo) as follows: >>>>>>>> >>>>>>>> private HttpContext mHttpContext; >>>>>>>> >>>>>>>> @Requires >>>>>>>> private WebContainer mWebService; >>>>>>>> ... >>>>>>>> mHttpContext = mWebService.createDefaultHttpContext(); >>>>>>>> mWebService.registerResources("/", "/webroot", mHttpContext); >>>>>>>> >>>>>>>> The above will get me the double slash problem. If I instead do: >>>>>>>> >>>>>>>> mWebService.registerResources("", "/webroot", mHttpContext); >>>>>>>> >>>>>>>> Then I get: >>>>>>>> >>>>>>>> Caused by: java.lang.IllegalArgumentException: Alias does not >>>>>>>> start with slash (/) >>>>>>>> at org.ops4j.pax.web.service.spi. >>>>>>>> model.ServletModel.validateAlias(ServletModel.java:169) >>>>>>>> at org.ops4j.pax.web.service.spi. >>>>>>>> model.ServletModel.<init>(ServletModel.java:53) >>>>>>>> at org.ops4j.pax.web.service.spi. >>>>>>>> model.ResourceModel.<init>(ResourceModel.java:29) >>>>>>>> at org.ops4j.pax.web.service.inte >>>>>>>> rnal.HttpServiceStarted.registerResources(HttpServiceStarted >>>>>>>> .java:262) >>>>>>>> at org.ops4j.pax.web.service.inte >>>>>>>> rnal.HttpServiceProxy.registerResources(HttpServiceProxy.java:71) >>>>>>>> at org.ops4j.pax.web.service.WebC >>>>>>>> ontainer$$Proxy.registerResources(Unknown Source) >>>>>>>> at se.digia.hp.web.HpWebService._ >>>>>>>> _M_init(HpWebService.java:134) >>>>>>>> at se.digia.hp.web.HpWebService.init(HpWebService.java) >>>>>>>> at se.digia.hp.web.HpWebService._ >>>>>>>> _M_starting(HpWebService.java:47) >>>>>>>> at se.digia.hp.web.HpWebService.starting(HpWebService.java) >>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>>> Method)[:1.8.0_74] >>>>>>>> at sun.reflect.NativeMethodAccess >>>>>>>> orImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0_74] >>>>>>>> at sun.reflect.DelegatingMethodAc >>>>>>>> cessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0_74] >>>>>>>> at java.lang.reflect.Method.invok >>>>>>>> e(Method.java:498)[:1.8.0_74] >>>>>>>> at org.apache.felix.ipojo.util.Ca >>>>>>>> llback.call(Callback.java:237)[50:org.apache.felix.ipojo:1.12.1] >>>>>>>> at org.apache.felix.ipojo.util.Ca >>>>>>>> llback.call(Callback.java:193)[50:org.apache.felix.ipojo:1.12.1] >>>>>>>> at org.apache.felix.ipojo.handler >>>>>>>> s.lifecycle.callback.LifecycleCallback.call(LifecycleCallbac >>>>>>>> k.java:86)[50:org.apache.felix.ipojo:1.12.1] >>>>>>>> at org.apache.felix.ipojo.handler >>>>>>>> s.lifecycle.callback.LifecycleCallbackHandler.__M_stateChang >>>>>>>> ed(LifecycleCallbackHandler.java:162)[50:org.apache.felix.i >>>>>>>> pojo:1.12.1] >>>>>>>> >>>>>>>> Specifying null does not work either. If I do >>>>>>>> >>>>>>>> mWebService.registerResources(null, "/webroot", mHttpContext); >>>>>>>> >>>>>>>> Then I get: >>>>>>>> >>>>>>>> Caused by: java.lang.IllegalArgumentException: Alias does not >>>>>>>> start with slash (/) >>>>>>>> at org.ops4j.pax.web.service.spi. >>>>>>>> model.ServletModel.validateAlias(ServletModel.java:169) >>>>>>>> at org.ops4j.pax.web.service.spi. >>>>>>>> model.ServletModel.<init>(ServletModel.java:53) >>>>>>>> at org.ops4j.pax.web.service.spi. >>>>>>>> model.ResourceModel.<init>(ResourceModel.java:29) >>>>>>>> at org.ops4j.pax.web.service.inte >>>>>>>> rnal.HttpServiceStarted.registerResources(HttpServiceStarted >>>>>>>> .java:262) >>>>>>>> at org.ops4j.pax.web.service.inte >>>>>>>> rnal.HttpServiceProxy.registerResources(HttpServiceProxy.java:71) >>>>>>>> at org.ops4j.pax.web.service.WebC >>>>>>>> ontainer$$Proxy.registerResources(Unknown Source) >>>>>>>> at se.digia.hp.web.HpWebService._ >>>>>>>> _M_init(HpWebService.java:134) >>>>>>>> at se.digia.hp.web.HpWebService.init(HpWebService.java) >>>>>>>> at se.digia.hp.web.HpWebService._ >>>>>>>> _M_starting(HpWebService.java:47) >>>>>>>> at se.digia.hp.web.HpWebService.starting(HpWebService.java) >>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>>> Method)[:1.8.0_74] >>>>>>>> at sun.reflect.NativeMethodAccess >>>>>>>> orImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0_74] >>>>>>>> at sun.reflect.DelegatingMethodAc >>>>>>>> cessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0_74] >>>>>>>> at java.lang.reflect.Method.invok >>>>>>>> e(Method.java:498)[:1.8.0_74] >>>>>>>> at org.apache.felix.ipojo.util.Ca >>>>>>>> llback.call(Callback.java:237)[50:org.apache.felix.ipojo:1.12.1] >>>>>>>> at org.apache.felix.ipojo.util.Ca >>>>>>>> llback.call(Callback.java:193)[50:org.apache.felix.ipojo:1.12.1] >>>>>>>> at org.apache.felix.ipojo.handler >>>>>>>> s.lifecycle.callback.LifecycleCallback.call(LifecycleCallbac >>>>>>>> k.java:86)[50:org.apache.felix.ipojo:1.12.1] >>>>>>>> at org.apache.felix.ipojo.handler >>>>>>>> s.lifecycle.callback.LifecycleCallbackHandler.__M_stateChang >>>>>>>> ed(LifecycleCallbackHandler.java:162)[50:org.apache.felix.i >>>>>>>> pojo:1.12.1] >>>>>>>> >>>>>>>> It looks like the code you are referring to registers a Servlet >>>>>>>> which I do not do directly for these resources (although Pax-Web >>>>>>>> ResourceServlet is probably used under the hood). >>>>>>>> >>>>>>>> Perhaps I'd better give you the overall picture... >>>>>>>> >>>>>>>> I have a web application consisting of html/javascript/css files. >>>>>>>> These are included in my app and will reside in my bundle. They are >>>>>>>> located >>>>>>>> in my bundle directory "\webroot". I want "\webroot" to correspond to >>>>>>>> the >>>>>>>> root ("\") context path. >>>>>>>> >>>>>>>> I also have a couple of Servlets providing services for my >>>>>>>> javascript files: >>>>>>>> >>>>>>>> - One using the context path "\api" that provides general services. >>>>>>>> - One using the context path "\admin\login" for logging in. Shiro >>>>>>>> is automatically implementing "\admin\logout" since I specify in my >>>>>>>> shiro.ini that this should be the logout page. >>>>>>>> >>>>>>>> In addition to the above, I need to externalize some of my >>>>>>>> resources to a normal directory in the file system. My web application >>>>>>>> uses >>>>>>>> different logos for the different clients and they can upload their >>>>>>>> logos >>>>>>>> on their own so they cannot be a static part of the web application. >>>>>>>> >>>>>>>> So I need something like this: >>>>>>>> >>>>>>>> a) The bundle's "\webroot" mapped to "\" >>>>>>>> b) Servlet mapped to "\api" >>>>>>>> c) Serlvet mapped to "\admin\login" (and "\admin\logout" via Shiro) >>>>>>>> d) Normal directory mapped to "\logo". >>>>>>>> >>>>>>>> I can get the individual pieces working but not together. If I put >>>>>>>> everything under "\hp" instead of under "\" then it works fine but that >>>>>>>> context part is not acceptable. I need to put it under "\" since there >>>>>>>> are >>>>>>>> existing URL's on the public site that must remain as today. >>>>>>>> >>>>>>>> Might sound a bit complicated but I don't think it's an unusual >>>>>>>> setup. >>>>>>>> >>>>>>>> /Bengt >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2016-11-07 20:09 GMT+01:00 'Achim Nierbeck' via OPS4J < >>>>>>>> [email protected]>: >>>>>>>> >>>>>>>>> Hi Bengt, >>>>>>>>> >>>>>>>>> regarding issue #1 ... could you try to do something as >>>>>>>>> "documented" in this[1] integration test? >>>>>>>>> If you abandon the first parameter, with only the alias, it's >>>>>>>>> always bound to the root "/". >>>>>>>>> >>>>>>>>> regarding issue#2 ... I'm not sure yet, but might be solved with >>>>>>>>> #1 done right ;) >>>>>>>>> >>>>>>>>> regards, Achim >>>>>>>>> >>>>>>>>> [1] - https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax >>>>>>>>> -web-itest/pax-web-itest-container/pax-web-itest-container-j >>>>>>>>> etty/src/test/java/org/ops4j/pax/web/itest/jetty/RootAliasIn >>>>>>>>> tegrationTest.java >>>>>>>>> >>>>>>>>> >>>>>>>>> 2016-11-07 17:40 GMT+01:00 Bengt Rodehav <[email protected]>: >>>>>>>>> >>>>>>>>>> I'm using Pax-Web in Karaf 4.0.7. >>>>>>>>>> >>>>>>>>>> I have two problems with aliases: >>>>>>>>>> >>>>>>>>>> *Problem #1* >>>>>>>>>> >>>>>>>>>> If I register resources for the context path "/" (i e the root) >>>>>>>>>> as follows: >>>>>>>>>> >>>>>>>>>> mWebService.registerResources("/", "/webroot", mHttpContext); >>>>>>>>>> >>>>>>>>>> Then my application is reachable at: >>>>>>>>>> >>>>>>>>>> http://localhost:8183//admin/login >>>>>>>>>> >>>>>>>>>> but not at: >>>>>>>>>> >>>>>>>>>> http://localhost:8183/admin/login >>>>>>>>>> >>>>>>>>>> I want to get rid of the double slash. However if I try this >>>>>>>>>> instead: >>>>>>>>>> >>>>>>>>>> mWebService.registerResources("", "/webroot", mHttpContext); >>>>>>>>>> >>>>>>>>>> Then I get: >>>>>>>>>> >>>>>>>>>> Caused by: java.lang.IllegalArgumentException: Alias does not >>>>>>>>>> start with slash (/) >>>>>>>>>> at org.ops4j.pax.web.service.spi. >>>>>>>>>> model.ServletModel.validateAlias(ServletModel.java:169) >>>>>>>>>> at org.ops4j.pax.web.service.spi. >>>>>>>>>> model.ServletModel.<init>(ServletModel.java:53) >>>>>>>>>> at org.ops4j.pax.web.service.spi. >>>>>>>>>> model.ResourceModel.<init>(ResourceModel.java:29) >>>>>>>>>> at org.ops4j.pax.web.service.inte >>>>>>>>>> rnal.HttpServiceStarted.registerResources(HttpServiceStarted >>>>>>>>>> .java:262) >>>>>>>>>> at org.ops4j.pax.web.service.inte >>>>>>>>>> rnal.HttpServiceProxy.registerResources(HttpServiceProxy.java:71) >>>>>>>>>> at org.ops4j.pax.web.service.WebC >>>>>>>>>> ontainer$$Proxy.registerResources(Unknown Source) >>>>>>>>>> at se.digia.hp.web.HpWebService._ >>>>>>>>>> _M_init(HpWebService.java:133) >>>>>>>>>> at se.digia.hp.web.HpWebService.init(HpWebService.java) >>>>>>>>>> at se.digia.hp.web.HpWebService._ >>>>>>>>>> _M_starting(HpWebService.java:47) >>>>>>>>>> at se.digia.hp.web.HpWebService.s >>>>>>>>>> tarting(HpWebService.java) >>>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>>>>> Method)[:1.8.0_74] >>>>>>>>>> at sun.reflect.NativeMethodAccess >>>>>>>>>> orImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0_74] >>>>>>>>>> at sun.reflect.DelegatingMethodAc >>>>>>>>>> cessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8 >>>>>>>>>> .0_74] >>>>>>>>>> at java.lang.reflect.Method.invok >>>>>>>>>> e(Method.java:498)[:1.8.0_74] >>>>>>>>>> at org.apache.felix.ipojo.util.Ca >>>>>>>>>> llback.call(Callback.java:237)[50:org.apache.felix.ipojo:1.12.1] >>>>>>>>>> at org.apache.felix.ipojo.util.Ca >>>>>>>>>> llback.call(Callback.java:193)[50:org.apache.felix.ipojo:1.12.1] >>>>>>>>>> at org.apache.felix.ipojo.handler >>>>>>>>>> s.lifecycle.callback.LifecycleCallback.call(LifecycleCallbac >>>>>>>>>> k.java:86)[50:org.apache.felix.ipojo:1.12.1] >>>>>>>>>> at org.apache.felix.ipojo.handler >>>>>>>>>> s.lifecycle.callback.LifecycleCallbackHandler.__M_stateChang >>>>>>>>>> ed(LifecycleCallbackHandler.java:162)[50:org.apache.felix.i >>>>>>>>>> pojo:1.12.1] >>>>>>>>>> >>>>>>>>>> How can I get rid of the "double slash"? >>>>>>>>>> >>>>>>>>>> *Problem #2* >>>>>>>>>> >>>>>>>>>> Assume that my web application resides at the context url: >>>>>>>>>> >>>>>>>>>> http://localhost:8183/hp >>>>>>>>>> >>>>>>>>>> I also register a separate resource directory directly in jetty >>>>>>>>>> with the following configuration (as I was helped by Achim on this >>>>>>>>>> forum): >>>>>>>>>> >>>>>>>>>> <?xml version="1.0"?> >>>>>>>>>> <!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" " >>>>>>>>>> http://www.eclipse.org/jetty/configure_9_0.dtd";> >>>>>>>>>> >>>>>>>>>> <Configure id="Server" class="org.eclipse.jetty.server.Server"> >>>>>>>>>> <Get name="handler"> >>>>>>>>>> <Call name="addHandler"> >>>>>>>>>> <Arg> >>>>>>>>>> <New class="org.eclipse.jetty.serve >>>>>>>>>> r.handler.ContextHandler"> >>>>>>>>>> <Set name="contextPath">/logo</Set> >>>>>>>>>> <Set name="handler"> >>>>>>>>>> <New class="org.eclipse.jetty.serve >>>>>>>>>> r.handler.ResourceHandler"> >>>>>>>>>> <Set name="resourceBase">../../comm >>>>>>>>>> on/etc/logo</Set> >>>>>>>>>> <Set name="directoriesListed">true</Set> >>>>>>>>>> </New> >>>>>>>>>> </Set> >>>>>>>>>> </New> >>>>>>>>>> </Arg> >>>>>>>>>> </Call> >>>>>>>>>> </Get> >>>>>>>>>> </Configure> >>>>>>>>>> >>>>>>>>>> This works fine. But when I try to move the application up to the >>>>>>>>>> root (which has the double slash problem as described in Problem #1) >>>>>>>>>> to the >>>>>>>>>> following url: >>>>>>>>>> >>>>>>>>>> http://localhost:8183// >>>>>>>>>> >>>>>>>>>> Then the separate resource via my jetty.xml does not work. It >>>>>>>>>> seems that it cannot be a descendant of the context path I use for >>>>>>>>>> my web >>>>>>>>>> application. But, since this is a public web application, with a >>>>>>>>>> predetermined url, it must reside at the root. Then there is no >>>>>>>>>> context >>>>>>>>>> path that works for my separate resource directory since all paths >>>>>>>>>> are >>>>>>>>>> descendants of root. >>>>>>>>>> >>>>>>>>>> This seems a bit weird... >>>>>>>>>> >>>>>>>>>> /Bengt >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> -- >>>>>>>>>> ------------------ >>>>>>>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>> Google Groups "OPS4J" group. >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>>> send an email to [email protected]. >>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Apache Member >>>>>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>>>>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> >>>>>>>>> Committer & Project Lead >>>>>>>>> blog <http://notizblog.nierbeck.de/> >>>>>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >>>>>>>>> >>>>>>>>> Software Architect / Project Manager / Scrum Master >>>>>>>>> >>>>>>>>> -- >>>>>>>>> -- >>>>>>>>> ------------------ >>>>>>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>>>>>> >>>>>>>>> --- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "OPS4J" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to [email protected]. >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> -- >>>>>>>> ------------------ >>>>>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>>>>> >>>>>>>> --- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "OPS4J" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Apache Member >>>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> >>>>>>> Committer & Project Lead >>>>>>> blog <http://notizblog.nierbeck.de/> >>>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >>>>>>> >>>>>>> Software Architect / Project Manager / Scrum Master >>>>>>> >>>>>>> -- >>>>>>> -- >>>>>>> ------------------ >>>>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>>>> >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "OPS4J" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> >>>>> -- >>>>> -- >>>>> ------------------ >>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>> >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "OPS4J" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Apache Member >>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> >>>> Committer & Project Lead >>>> blog <http://notizblog.nierbeck.de/> >>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >>>> >>>> Software Architect / Project Manager / Scrum Master >>>> >>>> -- >>>> -- >>>> ------------------ >>>> OPS4J - http://www.ops4j.org - [email protected] >>>> >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "OPS4J" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> -- >>> ------------------ >>> OPS4J - http://www.ops4j.org - [email protected] >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "OPS4J" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> >> Apache Member >> Apache Karaf <http://karaf.apache.org/> Committer & PMC >> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer >> & Project Lead >> blog <http://notizblog.nierbeck.de/> >> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >> >> Software Architect / Project Manager / Scrum Master >> >> -- >> -- >> ------------------ >> OPS4J - http://www.ops4j.org - [email protected] >> >> --- >> You received this message because you are subscribed to the Google Groups >> "OPS4J" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
