Please check the activator I used: https://github.com/ops4j/org.ops4j.pax.web/commit/c4efc95ebe1e5ecd4d7763f3f04267f9213a845d#diff-c7a6d3e304fd5dd93a853e2d86a1f1ea390f1f1d313691af2854a63b527ccaa4
regards Grzegorz Grzybek wt., 20 wrz 2022 o 11:43 Grzegorz Grzybek <gr.grzy...@gmail.com> napisał(a): > Anyway, I've created a Pax Web issue at > https://github.com/ops4j/org.ops4j.pax.web/issues/1769, so we can > continue the discussion there. > > regards > Grzegorz Grzybek > > wt., 20 wrz 2022 o 09:44 Grzegorz Grzybek <gr.grzy...@gmail.com> > napisał(a): > >> Hello Dave >> >> Your logs are really helpful, I've found (in some.txt) that a servlet >> named "com.candatag.repository.servlet.RepoMenu" is registered into OCM-3 >> (/admin): >> >> [paxweb-config-1-thread-1] INFO >> org.ops4j.pax.web.service.internal.HttpServiceEnabled - Registering >> ServletModel{id=ServletModel-9,name='com.candatag.repository.servlet.RepoMenu',urlPatterns=[/repo],contexts=[{WB,OCM-3,com.candatag.web.security.admin.services.AdminWebSecurity,/admin}]} >> >> but only later this OCM-3 is passed to Jetty: >> >> [paxweb-config-1-thread-1] INFO >> org.ops4j.pax.web.service.jetty.internal.JettyServerController - Receiving >> Batch{"Registration of >> OsgiContextModel{WB,id=OCM-3,name='com.candatag.web.security.admin.services.AdminWebSecurity',path='/admin',bundle=com.candatag.web.security.admin,ref={org.osgi.service.http.context.ServletContextHelper, >> com.candatag.web.security.admin.services.AdminWebSecurity}={service.id=55, >> osgi.http.whiteboard.context.name=com.candatag.web.security.admin.services.AdminWebSecurity, >> service.bundleid=18, service.scope=bundle, >> component.name=com.candatag.web.security.admin.zoo.impl.AdminContext, >> osgi.http.whiteboard.context.path=/admin, component.id=21}}", size=2} >> [paxweb-config-1-thread-1] INFO >> org.ops4j.pax.web.service.jetty.internal.JettyServerWrapper - Creating new >> Jetty context for >> ServletContextModel{id=ServletContextModel-12,contextPath='/admin'} >> [paxweb-config-1-thread-1] INFO >> org.ops4j.pax.web.service.jetty.internal.JettyServerWrapper - Adding >> OsgiContextModel{WB,id=OCM-3,name='com.candatag.web.security.admin.services.AdminWebSecurity',path='/admin',bundle=com.candatag.web.security.admin,ref={org.osgi.service.http.context.ServletContextHelper, >> com.candatag.web.security.admin.services.AdminWebSecurity}={service.id=55, >> osgi.http.whiteboard.context.name=com.candatag.web.security.admin.services.AdminWebSecurity, >> service.bundleid=18, service.scope=bundle, >> component.name=com.candatag.web.security.admin.zoo.impl.AdminContext, >> osgi.http.whiteboard.context.path=/admin, component.id=21}} to >> o.o.p.w.s.j.i.PaxWebServletContextHandler@48beedf5{/admin,null,STOPPED} >> >> I'll ensure that this doesn't lead to problems. >> >> I'll check further, bu if you could please set DEBUG log level for entire >> "org.ops4j.pax.web" logger and add timestamps, we'd get more information. >> >> In server.txt I think everything looks fine though (if I read the DTOs >> correctly): >> >> Servlet Context {"name":"default", "contextPath":"/", ..., >> "serviceId":39, "servletDTOs":[{"patterns":["/osgi/started"], ..., >> "name":"com.candatag.k8s.zoo.servlet.ReadyProbe", ...], ...} >> - {"patterns":["/osgi/started"], ..., >> "name":"com.candatag.k8s.zoo.servlet.ReadyProbe", ...} >> >> Servlet Context {"name":"default", "contextPath":"/", ..., "serviceId":0, >> "servletDTOs":[], ...} >> - <no servlets> >> >> Servlet Context >> {"name":"com.candatag.web.security.admin.services.AdminWebSecurity", >> "contextPath":"/admin", ..., "serviceId":40, "servletDTOs":[ >> - {"patterns":["/repo/localservice/console/services/view"], ..., >> "name":"com.candatag.osgi.console.servlet.ViewService", ...}, >> - {"patterns":["/repo/localservice/console/services"], ..., >> "name":"com.candatag.osgi.console.servlet.Services", ...}, >> - {"patterns":["/repo/localservice/console/services/check"], ..., >> "name":"com.candatag.osgi.console.servlet.SystemCheck", ...}, >> - {"patterns":["/repo/localservice/console/run"], ..., >> "name":"com.candatag.osgi.console.servlet.RunService", } >> ], ...} >> >> so "/osgi/started" servlet is registered to "/" context, which is (from >> Whiteboard point of view) "backed" by OCM-3 (serviceId=39) - the one >> registered by you, not the default one from pax-web-extender-whiteboard. >> >> However, in "some.txt", I see what I mentioned - that a servlet >> registration is being handled before OCM-3 is processed. Indeed, in code, >> the OsgiContextModel is added to Whiteboard internal structures, before >> it's passed further. And in between, a servlet may refer to it. Checking. >> >> regards >> Grzegorz Grzybek >> >> >> pon., 19 wrz 2022 o 21:36 Dave Smith <dave.sm...@candata.com> napisał(a): >> >>> Never responds to the GET request. I have a helper method that displays >>> the ServletDTO. It does not show up there either. It does seem to be a >>> timing issue. >>> >>> I have attached a couple of log dumps. The checks of the DTO (They are >>> the last lines of the log entries) happen about 10 seconds after the >>> container starts. >>> In server.txt there is one servlet that gets dropped from the new >>> default context >>> In some.txt there are 2 servlets that get dropped and then there are 2 >>> that are registered successfully . >>> >>> Dave >>> >>> On Mon, Sep 19, 2022 at 2:06 PM Grzegorz Grzybek <gr.grzy...@gmail.com> >>> wrote: >>> >>>> Hi. See inline >>>> >>>> pon., 19 wrz 2022 o 20:21 Dave Smith <dave.sm...@candata.com> >>>> napisał(a): >>>> >>>>> I have been doing a little more testing. I have an activator method >>>>> like this ... >>>>> >>>>> Thread context = new Thread(()->{ >>>>> Hashtable<String, Object> aDic = new Hashtable<>(); >>>>> aDic.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_NAME, >>>>> "default"); >>>>> aDic.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_PATH, "/"); >>>>> aDic.put(Constants.SERVICE_RANKING,Integer.MAX_VALUE); >>>>> ctx.registerService(ServletContextHelper.class, new DefaultContxt(), >>>>> aDic); >>>>> >>>>> }); >>>>> >>>>> CountDownLatch latch = new CountDownLatch(1); >>>>> Thread s2 = new Thread(()->{ >>>>> >>>>> Hashtable<String, Object> aDic = new Hashtable<>(); >>>>> aDic.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_NAME, >>>>> "test2"); >>>>> aDic.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_PATTERN, >>>>> "/test2"); >>>>> ctx.registerService(Servlet.class, new TestServlet("Test 2"), aDic); >>>>> latch.countDown(); >>>>> }); >>>>> >>>>> s2.start(); >>>>> latch.await(); >>>>> Thread.sleep(400); >>>>> context.start(); >>>>> >>>>> On my machine any value where sleep is <400 the context is always >>>>> started first otherwise the servlet gets started first and gets >>>>> unresgtered >>>>> and re-registered into the new context. I am guessing it takes longer to >>>>> init the servlet and I wonder if the Context is getting updated during the >>>>> servlet init process. (That is what it would seem like from the logs)... >>>>> >>>>> Let me know if you need any more info ... >>>>> >>>> >>>> I'll check the order of operations tomorrow. The point is that in Pax >>>> Web 8 I've created several such tests, including SCR one ( >>>> https://github.com/ops4j/org.ops4j.pax.web/tree/web-8.0.9/samples/samples-whiteboard/whiteboard-ds >>>> - see the readme describing fundamental difficulty with SCR) where contexts >>>> and servlets are registered, but eventually everything is fine. >>>> >>>> So a question - is your servlet eventually responding to a GET request? >>>> Don't just look at the logs for registration/unregistration of the context. >>>> The lines you've sent: >>>> >>>> Unegistering >>>> OsgiServletContext{model=OsgiContextModel{WB,id=OCM-1,name='default',path='/',bundle=org.ops4j.pax.web.pax-web-extender-whiteboard,context=(supplier)}} >>>> as OSGi service for "/" context path >>>> >>>> Registering >>>> OsgiServletContext{model=OsgiContextModel{WB,id=OCM-2,name='default',path='/',bundle=com.candatag.web.util,ref={org.osgi.service.http.context.ServletContextHelper}={ >>>> service.id=57, osgi.http.whiteboard.context.name=default, >>>> service.bundleid=19, service.scope=bundle, service.ranking=2147483647, >>>> component.name=com.candatag.web.util.zoo.impl.NoSecurityContextImpl, >>>> osgi.http.whiteboard.context.path=/, component.id=22}}} as OSGi >>>> service for "/" context path >>>> >>>> are information that different object of OsgiServletContext class is >>>> registered as the OSGi service of javax.servlet.ServletContext interface. >>>> This is according to chapter 128.3.4 ( >>>> https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.war.html#i3078599) >>>> of Web Applications Specification, but has nothing to do with Whiteboard - >>>> the underlying Jetty/Tomcat/Undertow context stays started. >>>> >>>> regards >>>> Grzegorz Grzybek >>>> >>>> >>>>> >>>>> >>>>> Dave >>>>> >>>>> >>>>> >>>>> On Mon, Sep 19, 2022 at 12:52 PM Grzegorz Grzybek < >>>>> gr.grzy...@gmail.com> wrote: >>>>> >>>>>> Hello >>>>>> >>>>>> It's all loosely coupled - a "servlet registration" knows the LDAP >>>>>> filter (by default "osgi.http.whiteboard.context.select=( >>>>>> osgi.http.whiteboard.context.name=default)") for it's contexts. And >>>>>> each time the new context is registered, the web elements with matching >>>>>> filter are being re-registered. >>>>>> >>>>>> The fact that you're overriding an "OSGi Context" >>>>>> (ServletContextHelper) within the same context path "/" means that the >>>>>> servlet context is restarted (because there's higher-ranked >>>>>> OsgiServletContext), but the servlet should be simply kept in existing >>>>>> "/" >>>>>> ServletContext. I know - lots of contexts. >>>>>> >>>>>> Today I was checking few other >>>>>> https://github.com/ops4j/org.ops4j.pax.web/issues, but I remember >>>>>> about your scenario - I should have an explanation tomorrow. >>>>>> >>>>>> regards >>>>>> Grzegorz Grzybek >>>>>> >>>>>> pon., 19 wrz 2022 o 19:42 dave....@candata.com < >>>>>> dave.sm...@candata.com> napisał(a): >>>>>> >>>>>>> Still trying to get a test case but I do believe it is a threading >>>>>>> issue ... What I find strange is the servlet that disappears gets >>>>>>> registered like this >>>>>>> >>>>>>> [paxweb-config-1-thread-1] INFO >>>>>>> org.ops4j.pax.web.service.internal.HttpServiceEnabled - Registering >>>>>>> ServletModel{id=ServletModel-4,name='com.candatag.k8s.zoo.servlet.ReadyProbe',urlPatterns=[/osgi/started],contexts=[{WB,OCM-2,default,/}]} >>>>>>> Receiving Batch{"Registration of >>>>>>> ServletModel{id=ServletModel-4,name='com.candatag.k8s.zoo.servlet.ReadyProbe',urlPatterns=[/osgi/started],contexts=[{WB,OCM-2,default,/}]}", >>>>>>> size=1} >>>>>>> Adding servlet >>>>>>> ServletModel{id=ServletModel-4,name='com.candatag.k8s.zoo.servlet.ReadyProbe',urlPatterns=[/osgi/started],contexts=[{WB,OCM-2,default,/}]} >>>>>>> >>>>>>> Now what is ODD is that OCM-2 is not registered yet! It follows in >>>>>>> the logs >>>>>>> >>>>>>> Receiving Batch{"Registration of >>>>>>> OsgiContextModel{WB,id=OCM-2,name='default',path='/',bundle=com.candatag.web.util,ref={org.osgi.service.http.context.ServletContextHelper}={ >>>>>>> service.id=39, osgi.http.whiteboard.context.name=default, >>>>>>> service.bundleid=17, service.scope=bundle, service.ranking=2147483647, >>>>>>> component.name=com.candatag.web.util.zoo.impl.NoSecurityContextImpl, >>>>>>> osgi.http.whiteboard.context.path=/, component.id=1}}", size=1} >>>>>>> >>>>>>> So how does the servlet know that this new default context is >>>>>>> coming? In my test harness I see the servlet unregistering and then >>>>>>> registering again when the context changes... >>>>>>> >>>>>>> It looks like we are half pregnant, somebody knows the context is >>>>>>> there but it is in an unregistered state so the servlet modal does not >>>>>>> get >>>>>>> attached. >>>>>>> >>>>>>> Dave >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sunday, September 18, 2022 at 8:50:28 AM UTC-5 >>>>>>> dave....@candata.com wrote: >>>>>>> >>>>>>>> My other question would be if you are "Unregistering " the default >>>>>>>> context should it still show up in the >>>>>>>> HttpServiceRuntime.getRuntimeDTO().servletContextDTOs ? It does now >>>>>>>> >>>>>>>> Dave >>>>>>>> >>>>>>>> >>>>>>>> On Sunday, September 18, 2022 at 8:43:33 AM UTC-5 >>>>>>>> dave....@candata.com wrote: >>>>>>>> >>>>>>>>> It will be a little tricky to send my whole project in , let me >>>>>>>>> see what I can do , however I have reviewed the test cases in the link >>>>>>>>> provided and it looks like you are not covering my case ... >>>>>>>>> >>>>>>>>> I do not see a test where ... >>>>>>>>> >>>>>>>>> Register the default handler -> HttpContext defaultContext = wc. >>>>>>>>> createDefaultHttpContext(); , not sure if this also creates a >>>>>>>>> ServletContextHelper >>>>>>>>> wrapper as well >>>>>>>>> >>>>>>>>> Then create a servlet that attaches to it , but do not call the >>>>>>>>> servlet , just check it is added >>>>>>>>> >>>>>>>>> Register the default override with a high service ranking . >>>>>>>>> >>>>>>>>> See if this happens >>>>>>>>> org.ops4j.pax.web.service.spi.servlet.OsgiServletContext - >>>>>>>>> Unegistering >>>>>>>>> OsgiServletContext{model=OsgiContextModel{WB,id=OCM-1,name='default',path='/' >>>>>>>>> org.ops4j.pax.web.service.spi.servlet.OsgiServletContext - >>>>>>>>> Registering >>>>>>>>> OsgiServletContext{model=OsgiContextModel{WB,id=OCM-2,name='default',path='/', >>>>>>>>> >>>>>>>>> And then see if the servlet is in the new context ... >>>>>>>>> >>>>>>>>> The override testcases seem to all create the override first >>>>>>>>> before the first servlet is registered OR you are changing the path >>>>>>>>> in the >>>>>>>>> default context ... >>>>>>>>> >>>>>>>>> Dave >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sun, Sep 18, 2022 at 8:06 AM Grzegorz Grzybek < >>>>>>>>> gr.gr...@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hello >>>>>>>>>> >>>>>>>>>> Actually, the initial reason of entire Pax Web 8 refactoring was >>>>>>>>>> the context handling - ability to register one servlet into multiple >>>>>>>>>> contexts and multiple servlets into one context. >>>>>>>>>> There are really lot of integration tests that show exactly this. >>>>>>>>>> >>>>>>>>>> I'd have to see your example and check what's the problem there - >>>>>>>>>> you seem to correctly override "default" whiteboard context with "/" >>>>>>>>>> path >>>>>>>>>> and higher ranking, so it should work. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://github.com/ops4j/org.ops4j.pax.web/tree/web-8.0.9/samples/samples-whiteboard/whiteboard-ds >>>>>>>>>> is and example of SCR registration of multiple web elements and >>>>>>>>>> contexts. >>>>>>>>>> >>>>>>>>>> This integration test ( >>>>>>>>>> https://github.com/ops4j/org.ops4j.pax.web/blob/web-8.0.9/pax-web-itest/pax-web-itest-server/src/test/java/org/ops4j/pax/web/itest/server/whiteboard/WhiteboardAndHttpServiceTest.java#L198) >>>>>>>>>> - overridenDefaultContextsWithWhiteboardServlet() shows how >>>>>>>>>> "default" + "/" context is overriden. >>>>>>>>>> >>>>>>>>>> Could you please share your project? It can be attached to an >>>>>>>>>> issue in https://github.com/ops4j/org.ops4j.pax.web/issues >>>>>>>>>> >>>>>>>>>> kind regards >>>>>>>>>> Grzegorz Grzybek >>>>>>>>>> >>>>>>>>>> niedz., 18 wrz 2022 o 14:16 Dave Smith <dave....@candata.com> >>>>>>>>>> napisał(a): >>>>>>>>>> >>>>>>>>>>> What is the correct way to override the default servlet context? >>>>>>>>>>> I am doing this... >>>>>>>>>>> >>>>>>>>>>> @Component(service = ServletContextHelper.class,property = { >>>>>>>>>>> Constants.SERVICE_RANKING+":Integer="+Integer.MAX_VALUE}) >>>>>>>>>>> @HttpWhiteboardContext(name = "default",path = "/") >>>>>>>>>>> public class NoSecurityContextImpl extends ServletContextHelper >>>>>>>>>>> { >>>>>>>>>>> >>>>>>>>>>> What I am seeing is if a servlet is registered BEFORE the new >>>>>>>>>>> default context it just seems to disappear, anything after gets put >>>>>>>>>>> in the >>>>>>>>>>> new default. When I call HttpServiceRuntime.servletDTOs I see the >>>>>>>>>>> original >>>>>>>>>>> default context with no servlets attached to it and my overridden >>>>>>>>>>> one with >>>>>>>>>>> the servlets that were registered after. >>>>>>>>>>> failedServletDTOs,failedServletContextDTOs are empty. If I remove my >>>>>>>>>>> override the servlets appear. >>>>>>>>>>> >>>>>>>>>>> What is weird is it looks like the servlet is getting put into >>>>>>>>>>> the right context if I read the log correctly ... >>>>>>>>>>> >>>>>>>>>>> Registering >>>>>>>>>>> ServletModel{id=ServletModel-4,name='com.candatag.k8s.zoo.servlet.ReadyProbe',urlPatterns=[/osgi/started],contexts=[{WB,OCM-2,default,/}]} >>>>>>>>>>> >>>>>>>>>>> INFO org.ops4j.pax.web.service.spi.servlet.OsgiServletContext - >>>>>>>>>>> Unegistering >>>>>>>>>>> OsgiServletContext{model=OsgiContextModel{WB,id=OCM-1,name='default',path='/',bundle=org.ops4j.pax.web.pax-web-extender-whiteboard,context=(supplier)}} >>>>>>>>>>> as OSGi service for "/" context path >>>>>>>>>>> >>>>>>>>>>> Registering >>>>>>>>>>> OsgiServletContext{model=OsgiContextModel{WB,id=OCM-2,name='default',path='/',bundle=com.candatag.web.util,ref={org.osgi.service.http.context.ServletContextHelper}={ >>>>>>>>>>> service.id=57, osgi.http.whiteboard.context.name=default, >>>>>>>>>>> service.bundleid=19, service.scope=bundle, service.ranking= >>>>>>>>>>> 2147483647 <(214)%20748-3647>, >>>>>>>>>>> component.name=com.candatag.web.util.zoo.impl.NoSecurityContextImpl, >>>>>>>>>>> osgi.http.whiteboard.context.path=/, component.id=22}}} as OSGi >>>>>>>>>>> service for "/" context path >>>>>>>>>>> >>>>>>>>>>> Dave >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> -- >>>>>>>>>>> ------------------ >>>>>>>>>>> OPS4J - http://www.ops4j.org - op...@googlegroups.com >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> 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 ops4j+un...@googlegroups.com. >>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>> https://groups.google.com/d/msgid/ops4j/CA%2BFCLu2SbiSKmN7W3-ZQqHLYCA67vF104UCVWtU77-63tcarUA%40mail.gmail.com >>>>>>>>>>> <https://groups.google.com/d/msgid/ops4j/CA%2BFCLu2SbiSKmN7W3-ZQqHLYCA67vF104UCVWtU77-63tcarUA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> -- >>>>>>>>>> ------------------ >>>>>>>>>> OPS4J - http://www.ops4j.org - op...@googlegroups.com >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> 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 ops4j+un...@googlegroups.com. >>>>>>>>>> >>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/d/msgid/ops4j/CAAdXmhrMU6_5ABFc0oxevK%2BjuZVhOzxdK0cqvyTz6pCWZAM7Yg%40mail.gmail.com >>>>>>>>>> <https://groups.google.com/d/msgid/ops4j/CAAdXmhrMU6_5ABFc0oxevK%2BjuZVhOzxdK0cqvyTz6pCWZAM7Yg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>> -- >>>>>>> -- >>>>>>> ------------------ >>>>>>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com >>>>>>> >>>>>>> --- >>>>>>> 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 ops4j+unsubscr...@googlegroups.com. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/ops4j/e972d47a-f8b3-4dec-9ba1-94549e29a250n%40googlegroups.com >>>>>>> <https://groups.google.com/d/msgid/ops4j/e972d47a-f8b3-4dec-9ba1-94549e29a250n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>>> -- >>>>>> ------------------ >>>>>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com >>>>>> >>>>>> --- >>>>>> 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 ops4j+unsubscr...@googlegroups.com. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/ops4j/CAAdXmhqzknu%3DwfrL5d-hWbHe%2BGa%2Bazbx6Yg__OTuC683B8VbMA%40mail.gmail.com >>>>>> <https://groups.google.com/d/msgid/ops4j/CAAdXmhqzknu%3DwfrL5d-hWbHe%2BGa%2Bazbx6Yg__OTuC683B8VbMA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>>> -- >>>>> ------------------ >>>>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com >>>>> >>>>> --- >>>>> 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 ops4j+unsubscr...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/ops4j/CA%2BFCLu1OssPACzuqNDCpxT3AGz%3DRjarNubJUi%2BPXuog2D0aWMA%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/ops4j/CA%2BFCLu1OssPACzuqNDCpxT3AGz%3DRjarNubJUi%2BPXuog2D0aWMA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> -- >>>> ------------------ >>>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com >>>> >>>> --- >>>> 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 ops4j+unsubscr...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/ops4j/CAAdXmhrP%3DUawM0_EYyg%2B3NuyMDjz%3DRzqvAP%3D%3DfTkcXUXgJH6jw%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/ops4j/CAAdXmhrP%3DUawM0_EYyg%2B3NuyMDjz%3DRzqvAP%3D%3DfTkcXUXgJH6jw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> -- >>> ------------------ >>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com >>> >>> --- >>> 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 ops4j+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/ops4j/CA%2BFCLu3Wm1mXtGYBGHr7MoLpo83%2BQbd0TMHNheKiWii_at-CsQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/ops4j/CA%2BFCLu3Wm1mXtGYBGHr7MoLpo83%2BQbd0TMHNheKiWii_at-CsQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- -- ------------------ OPS4J - http://www.ops4j.org - ops4j@googlegroups.com --- 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 ops4j+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAAdXmhpjLo5kJZt8Nnew22fiXmPk1GjsURAOddRBpVmGdYUFNw%40mail.gmail.com.
