Hello Yes - you found the problematic aspect of Pax Web... I'm really trying to handle such scenarios in consistent way in Pax Web 8. There's huge amount of changes coming (see https://github.com/ops4j/org.ops4j.pax.web/commits/master-improvements branch) and listeners, ServletContainerInitializers (which also are not handled properly in Pax Web 7) are among the refactored changes.
Pax Web 7 is the final (before version 8) step in evolution of the implementation which started simply as implementation of HttpService which had ... 3 methods - registration of servlets, registration of resources and unregistration of the two... Then the whiteboard implementation came (and OSGi CMPN Whiteboard specification is actually inspired by Pax Web itself) and in parallel - WAR/WAB support. For WAR/WAB purposes, a concept of "web applications" was introduced in Pax Web, but still based (underneath) on a WebContainer (an extension of HttpService). Ensuring that listeners start before servlets/filters is tricky, especially because lot of intermediary layers between the HttpService implementation and actual Jetty/Tomcat/Undertow. On one side, Jetty (or other container) has to start immediately after the servlet is registered, but if "later" elements are registered the container has to be "restarted" (which is not full restart) and this is really not handled consistently (see my previous explanation of NOTSET vs INITIALIZED states). The final argument for me to rewrite Pax Web was ... https://ops4j1.jira.com/browse/PAXWEB-1123 and: osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=*) context selector filter - this itself was a reason to fully refactor all the internal Pax Web models. So for now I'm afraid you don't have much choice. regards Grzegorz Grzybek pt., 22 sty 2021 o 07:15 Denis Anisimov <[email protected]> napisał(a): > Intersting..... > I've modified the project so that the Servlet class requires the listener > class. > Which means that at least the service should be registered before the > servlet service. > But it doesn't help: listener is not called anyway. > Here is the project code: > https://github.com/denis-anisimov/simple-web/tree/wait-listener > > The only thing which finally worked is: move the listener out of the > Servlet project into a separate bundle. > Install and deploy it first. > Then install and deploy the project with Servlet. > Then I get the context initialization event finally. > > On Thursday, January 21, 2021 at 2:03:29 PM UTC+3 Denis Anisimov wrote: > >> Thanks a lot for your reply. >> >> Looks like you are talking about this issue: >> https://ops4j1.jira.com/browse/PAXWEB-62 >> But it's extremely old and it's closed so I though it's resolved. >> >> In my example it's not known when the listener is registered: before the >> servlet is registered and servlet context is initialized or after. >> You are right here. >> But I've started from another example where the listener is declared via >> DS in a separate bundle. >> And I had deployed this bundle first : so it's registered as a service by >> PAX. >> Then I've deployed the web bundle and the listener has not been called >> anyway. >> >> So personally for me regardless of the order of listener registration >> (before or after servlet) it's never called. >> >> The related topic for this : it's possible to declare >> `ServletContexHelper` with a given name. Then I can >> require to register a `Servlet` , any listener for the context identified >> by the name. But what happens if there >> is no such context helper registered YET ? In the same way I may declare >> the helper in a different bundle and >> it's not possible to say when it will be registered : before or after the >> servlet. >> So what will happen in that case: will it wait until the context helper >> appear with the given name or just >> simply fails because there is no helper with this name ? >> I expect that it won't fail and wait until the helper appears . Because >> otherwise I need to write boilerplate >> code which waits for the appearance of the service which normally I >> should not even know about >> (via ServiceTracker or via @Reference). This is extremely inconvenient. >> And the same situation is here with `ServletContexListener`: I have to >> wait until it's registered and register the servlet >> only after that. >> By the way I will check that : whether this work at all or not. >> >> But anyway: this looks like a bug because you may not rely on the order >> of listener registration: the listener should be called even if the servlet >> context >> of the web app "has been already initialized". As I understand this is >> exactly what https://ops4j1.jira.com/browse/PAXWEB-62 issue says. >> >> Also this is exactly how felix-jetty work: the servlet may be already >> intialized (registered and then even initialized) but once the servlet >> context listener >> is registered it's called anyway. >> That's why the behavior was quite confusing for me. >> >> But as I understand you confirmed that this does't work properly in pax >> web 7 and this is what you are working on for pax web 8. >> Thank you . >> >> >And about Pax Web issues - please let me know the login/email you've >> used in ops4j JIRA and I'll give you proper permissions. I can't see >> [email protected] <https://groups.google.com/> in OPS4j JIRA user list. >> >> I've been trying to login with my Google account [email protected] >> <https://groups.google.com/> but then it immediately says that this >> account has no access to JIRA. >> I've registered another account "den *@* admincomps *dot* >> ru" >> At least I've received the e-mail which confirms the registration. >> Could you please try that ? >> >> >> On Thursday, January 21, 2021 at 1:20:49 PM UTC+3 [email protected] >> wrote: >> >>> Hello >>> >>> I've checked your project and you're nicely using SCRs to register a >>> listener and a servlet. >>> >>> But you can't be sure which SCR component registers its service first! >>> And even if you could know it (there are tricks to add a @Reference from >>> one @Component to a service of other @Component), you would STILL not be >>> sure which will be first tracked by pax-web-extender-whiteboard! >>> >>> I found this SCR problem which was never resolved in pax web 7 and >>> earlier and I described it in my Pax Web 8 refactoring branch: >>> https://github.com/ops4j/org.ops4j.pax.web/tree/master-improvements/samples/samples-whiteboard/whiteboard-ds >>> >>> So I checked that Jetty's "context" is started immediately after your >>> servlet is being registered. This is the thread trace that starts Jetty: >>> >>> "pipe-start 109@10061" prio=5 tid=0x17f nid=NA runnable >>> java.lang.Thread.State: RUNNABLE >>> at >>> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:348) >>> at >>> org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.startContext(HttpServiceContext.java:392) >>> at >>> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:855) >>> at >>> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:275) >>> at >>> org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doStart(HttpServiceContext.java:268) >>> at >>> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72) >>> - locked <0x283c> (a java.lang.Object) >>> at >>> org.ops4j.pax.web.service.jetty.internal.JettyServerImpl$1.start(JettyServerImpl.java:327) >>> at >>> org.ops4j.pax.web.service.internal.HttpServiceStarted.registerServlet(HttpServiceStarted.java:255) >>> ... >>> at >>> org.ops4j.pax.web.extender.whiteboard.internal.element.ServletWebElement.register(ServletWebElement.java:102) >>> ... >>> at >>> org.ops4j.pax.web.extender.whiteboard.internal.tracker.AbstractTracker.addingService(AbstractTracker.java:44) >>> ... >>> at org.apache.felix.framework.Felix.registerService(Felix.java:3804) >>> at >>> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328) >>> at >>> org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:929) >>> ... >>> at >>> org.apache.karaf.bundle.command.BundlesCommand.execute(BundlesCommand.java:55) >>> at >>> org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84) >>> >>> and when org.eclipse.jetty.servlet.ServletContextHandler starts, there's >>> only one listener available - >>> org.eclipse.jetty.websocket.jsr356.server.deploy.WebSocketServerContainerInitializer$ContextDestroyListener. >>> >>> org.eclipse.jetty.server.handler.ContextHandler#callContextInitialized() >>> is called when the context is at >>> org.eclipse.jetty.server.handler.ContextHandler.ContextStatus#NOTSET state >>> and then switches to INITIALIZED. >>> >>> Then when your listener is added (after the servlet), Pax Web 7 tries >>> hard to unregister your first servlet (correctly) to register it again >>> after registering the listener. >>> org.eclipse.jetty.server.handler.ContextHandler#addEventListener() is >>> properly called, then >>> org.eclipse.jetty.servlet.ServletHandler#setServletMappings(), cache of >>> mappings is invalidated. >>> >>> And while >>> org.eclipse.jetty.server.handler.ContextHandler#_servletContextListeners >>> contains your org.example.TestServletContextListener, it is NOT called >>> because org.eclipse.jetty.server.handler.ContextHandler#_contextStatus is >>> not NOTSET, but INITIALIZED. >>> >>> So that's the problem with Pax Web 7. >>> >>> I'm really trying hard to handle all such cases in Pax Web 8, but I >>> can't do it 8hrs a day ;) That's why it's still not ready yet. >>> >>> And about Pax Web issues - please let me know the login/email you've >>> used in ops4j JIRA and I'll give you proper permissions. I can't see >>> [email protected] in OPS4j JIRA user list. >>> >>> regards >>> Grzegorz Grzybek >>> >>> czw., 21 sty 2021 o 10:12 Denis Anisimov <[email protected]> napisał(a): >>> >>>> Hi I have the same problem. >>>> >>>> I'm trying to get it working in Karaf. >>>> So I'm not sure whether this a Karaf issue or PAX-web. >>>> >>>> I can provide steps to reproduce with Karaf: >>>> - Download Karaf 4.3.0 >>>> - Extract it. >>>> - Run it via ./bin/karaf >>>> - invoke commands in the Karaf shell: "feature:install >>>> httpfeature:install war" >>>> - install logger via the Karaf shell: "bundle:install -s >>>> mvn:org.slf4j/slf4j-simple/1.7.25 bundle:install -s >>>> mvn:org.slf4j/slf4j-api/1.7.25" >>>> - Use this project https://github.com/denis-anisimov/simple-web >>>> - install the project locally >>>> - install the attached project : "bundle:install -s >>>> mvn:org.example/simple-web/1.0.0" >>>> - open the browser "http://localhost:8181/";. >>>> - the servlet is working : the message is shown in the browser. >>>> - but the "TestServletContextListener::contextInitialized" is never >>>> invoked. Neither console not log contains expected message. >>>> >>>> Is it a bug in PAX-web? Karaf ? >>>> Or am I doing somethig wrong ? >>>> ServletContextListener works as expected in the felix-jetty . >>>> >>>> By the way : how can I create an issue for PAX? Once I create an >>>> account to login to JIRA it says I don't have access to it. >>>> And I may not create a ticket. >>>> On Tuesday, March 5, 2019 at 8:20:45 AM UTC+3 [email protected] wrote: >>>> >>>>> Hello >>>>> >>>>> Did you try registering separate listeners instead of one with >>>>> different interfaces? >>>>> >>>>> I'm not sure about this ValidatorException. Try running mvn with -e >>>>> option to show full stack traces. >>>>> >>>>> regards >>>>> Grzegorz Grzybek >>>>> >>>>> czw., 14 lut 2019 o 23:45 Nhut Thai Le <[email protected]> >>>>> napisał(a): >>>>> >>>>>> Hello again, >>>>>> For some reason, i was able to get my ServletContextListener working >>>>>> for a while then now i need to added another one (for different app >>>>>> context) and i found that both the new and old one does not work anymore. >>>>>> My other HttpSessionListener is still working fine. Funny is that both >>>>>> the >>>>>> ServletContextListener and the HttpSessionListener is extended by the >>>>>> same >>>>>> class: >>>>>> >>>>>> @Component( >>>>>> service= { >>>>>> javax.servlet.http.HttpSessionListener.class, >>>>>> ServletContextListener.class >>>>>> }, >>>>>> property= { >>>>>> "osgi.http.whiteboard.listener=true", >>>>>> "osgi.http.whiteboard.context.select=( >>>>>> osgi.http.whiteboard.context.name=WebviewerServletContextHelper)", >>>>>> "listener.name=WebviewerServletContextListener" >>>>>> } >>>>>> ) >>>>>> public final class ZkListener implements >>>>>> javax.servlet.http.HttpSessionListener, ServletContextListener {} >>>>>> >>>>>> Where should i start debugging this? >>>>>> >>>>>> By the way, I tried to the command to run test on jetty that you >>>>>> suggested and i got: >>>>>> [INFO] >>>>>> ------------------------------------------------------------------------ >>>>>> [INFO] BUILD FAILURE >>>>>> [INFO] >>>>>> ------------------------------------------------------------------------ >>>>>> [INFO] Total time: 19.390 s >>>>>> [INFO] Finished at: 2019-02-14T17:32:16-05:00 >>>>>> [INFO] Final Memory: 24M/274M >>>>>> [INFO] >>>>>> ------------------------------------------------------------------------ >>>>>> [ERROR] Failed to execute goal on project >>>>>> pax-web-itest-container-jetty: Could not resolve dependencies for project >>>>>> org.ops4j.pax.web.itest.container:pax-web-itest-container-jetty:jar:7.2.9-SNAPSHOT: >>>>>> Failed to collect dependencies at >>>>>> org.ops4j.pax.web.itest:pax-web-itest-base:jar:7.2.9-SNAPSHOT: Failed to >>>>>> read artifact descriptor for >>>>>> org.ops4j.pax.web.itest:pax-web-itest-base:jar:7.2.9-SNAPSHOT: Could not >>>>>> transfer artifact >>>>>> org.ops4j.pax.web.itest:pax-web-itest-base:pom:7.2.9-SNAPSHOT from/to >>>>>> prime-repo (http://repository.primefaces.org): >>>>>> sun.security.validator.ValidatorException: PKIX path building failed: >>>>>> sun.security.provider.certpath.SunCertPathBuilderException: unable to >>>>>> find >>>>>> valid certification path to requested target -> [Help 1] >>>>>> >>>>>> Not sure what is wrong with my cert. >>>>>> >>>>>> On Tue, Oct 2, 2018 at 4:19 AM Grzegorz Grzybek <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hello >>>>>>> >>>>>>> Sorry for late answer. There's testListenersWithHttpContext() test >>>>>>> here: >>>>>>> https://github.com/ops4j/org.ops4j.pax.web/blob/pax-web-7.2.x/pax-web-itest/pax-web-itest-common/src/main/java/org/ops4j/pax/web/itest/common/AbstractWhiteboardR6IntegrationTest.java#L289 >>>>>>> >>>>>>> It does exactly what you're trying to achieve, but without SCR - >>>>>>> only by registering relevant services. You can run the test from within >>>>>>> any >>>>>>> of three container itest projects: >>>>>>> >>>>>>> mvn clean verify -f >>>>>>> pax-web-itest/pax-web-itest-container/pax-web-itest-container-jetty/ >>>>>>> -Dit.test=WhiteboardR6IntegrationTest#testListenersWithHttpContext >>>>>>> mvn clean verify -f >>>>>>> pax-web-itest/pax-web-itest-container/pax-web-itest-container-tomcat/ >>>>>>> -Dit.test=WhiteboardR6IntegrationTest#testListenersWithHttpContext >>>>>>> mvn clean verify -f >>>>>>> pax-web-itest/pax-web-itest-container/pax-web-itest-container-undertow/ >>>>>>> -Dit.test=WhiteboardR6IntegrationTest#testListenersWithHttpContext >>>>>>> >>>>>>> I'm not sure what may be your problem (maybe you'll share your maven >>>>>>> project via github?) - but this may be related to some other bundles you >>>>>>> have installed in your runtime (pure Equinox? pax-exam test? Karaf >>>>>>> based on >>>>>>> Equinox?) - which may cause problems with finding services you register >>>>>>> by >>>>>>> pax-web-extender-whiteboard. >>>>>>> >>>>>>> best regards >>>>>>> Grzegorz Grzybek >>>>>>> >>>>>>> pon., 24 wrz 2018 o 22:13 Nhut Thai Le <[email protected]> >>>>>>> napisał(a): >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I tried to hook a servletContextListener to my custom >>>>>>>> ServletContextHelper but the contextInitialized method is not called. >>>>>>>> -------------------Here is my ServletContextHelper:------------ >>>>>>>> @Component( >>>>>>>> service = ServletContextHelper.class, >>>>>>>> property = { >>>>>>>> "osgi.http.whiteboard.context.name >>>>>>>> =ZkComponentsServletContextHelper", >>>>>>>> "osgi.http.whiteboard.context.path=/components" >>>>>>>> } >>>>>>>> ) >>>>>>>> public class ZkComponentsServletContextHelper extends >>>>>>>> ServletContextHelper {...} >>>>>>>> --------------------------------My ServletContextListener---------- >>>>>>>> @Component( >>>>>>>> name="ZkListener", >>>>>>>> service= { >>>>>>>> ServletContextListener.class >>>>>>>> }, >>>>>>>> property= { >>>>>>>> "osgi.http.whiteboard.listener=true", >>>>>>>> "osgi.http.whiteboard.context.select=( >>>>>>>> osgi.http.whiteboard.context.name >>>>>>>> =ZkComponentsServletContextHelper)" >>>>>>>> } >>>>>>>> ) >>>>>>>> public final class ZkSessionListener implements >>>>>>>> ServletContextListener { >>>>>>>> private WebManager webManager; >>>>>>>> >>>>>>>> @Override >>>>>>>> public void contextInitialized(ServletContextEvent sce) { >>>>>>>> final ServletContext ctx = sce.getServletContext(); >>>>>>>> if (WebManager.getWebManagerIfAny(ctx) == null) { >>>>>>>> webManager = new WebManager(ctx, "/zkau"); >>>>>>>> } else { >>>>>>>> throw new IllegalStateException("ZK WebManager already exists. >>>>>>>> Could not initialize via Spring Boot configuration."); >>>>>>>> } >>>>>>>> } >>>>>>>> ------------------------------Finally, my simple >>>>>>>> servlet------------- >>>>>>>> @Component( >>>>>>>> service = Servlet.class, >>>>>>>> property= { >>>>>>>> "osgi.http.whiteboard.servlet.pattern=*.zul", >>>>>>>> "osgi.http.whiteboard.servlet.pattern=*.zhtml", >>>>>>>> "osgi.http.whiteboard.context.select=( >>>>>>>> osgi.http.whiteboard.context.name >>>>>>>> =ZkComponentsServletContextHelper)" >>>>>>>> } >>>>>>>> ) >>>>>>>> public class ZulExtensionServlet extends HttpServlet{..} >>>>>>>> ---------------------equinox bundle info------------- >>>>>>>> {org.osgi.service.http.context.ServletContextHelper}={service.id=95, >>>>>>>> osgi.http.whiteboard.context.name=ZkComponentsServletContextHelper, >>>>>>>> service.bundleid=59, service.scope=bundle, >>>>>>>> component.name=com.castortech.iris.zk.components.ZkComponentsServletContextHelper, >>>>>>>> osgi.http.whiteboard.context.path=/components, component.id=3} >>>>>>>> >>>>>>>> {javax.servlet.Servlet}={service.id=97, service.bundleid=59, >>>>>>>> service.scope=bundle, >>>>>>>> osgi.http.whiteboard.servlet.pattern=[*.zul,*.zhtml], >>>>>>>> osgi.http.whiteboard.context.select=( >>>>>>>> osgi.http.whiteboard.context.name=ZkComponentsServletContextHelper), >>>>>>>> component.name=com.castortech.iris.zk.components.ZulExtensionServlet, >>>>>>>> component.id=5} >>>>>>>> >>>>>>>> {javax.servlet.ServletContextListener}={service.id=98, >>>>>>>> service.bundleid=59, service.scope=bundle, >>>>>>>> osgi.http.whiteboard.context.select=( >>>>>>>> osgi.http.whiteboard.context.name=ZkComponentsServletContextHelper), >>>>>>>> osgi.http.whiteboard.listener=true, component.name=ZkListener, >>>>>>>> component.id=6} >>>>>>>> >>>>>>>> {javax.servlet.ServletContext}={osgi.web.version=1.0.0.qualifier, >>>>>>>> osgi.web.contextpath=/components, service.id=124, >>>>>>>> osgi.web.symbolicname=com.castortech.iris.zk.components, >>>>>>>> service.bundleid=59, service.scope=singleton, >>>>>>>> osgi.web.contextname=ZkComponentsServletContextHelper} >>>>>>>> >>>>>>>> >>>>>>>> As you can see, both the ServletContextListener and the servlet are >>>>>>>> bound to the same ServletContextHelper and there is a ServletContext >>>>>>>> created from the ServletContextHelper, however, the contextInitialized >>>>>>>> method was never called. Am I missing anything? >>>>>>>> >>>>>>>> Thai >>>>>>>> >>>>>>>> -- >>>>>>>> -- >>>>>>>> ------------------ >>>>>>>> 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. >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Castor Technologies Inc >>>>>> 460 rue St-Catherine St Ouest, Suite 613 >>>>>> Montréal, Québec H3B-1A7 >>>>>> (514) 360-7208 o >>>>>> (514) 798-2044 f >>>>>> [email protected] >>>>>> www.castortech.com >>>>>> >>>>>> CONFIDENTIALITY NOTICE: The information contained in this e-mail is >>>>>> confidential and may be proprietary information intended only for the use >>>>>> of the individual or entity to whom it is addressed. If the reader of >>>>>> this >>>>>> message is not the intended recipient, you are hereby notified that any >>>>>> viewing, dissemination, distribution, disclosure, copy or use of the >>>>>> information contained in this e-mail message is strictly prohibited. If >>>>>> you >>>>>> have received and/or are viewing this e-mail in error, please immediately >>>>>> notify the sender by reply e-mail, and delete it from your system without >>>>>> reading, forwarding, copying or saving in any manner. Thank you. >>>>>> AVIS DE CONFIDENTIALITE: L’information contenue dans ce message est >>>>>> confidentiel, peut être protégé par le secret professionnel et est >>>>>> réservé >>>>>> à l'usage exclusif du destinataire. Toute autre personne est par les >>>>>> présentes avisée qu'il lui est strictement interdit de diffuser, >>>>>> distribuer >>>>>> ou reproduire ce message. Si vous avez reçu cette communication par >>>>>> erreur, >>>>>> veuillez la détruire immédiatement et en aviser l'expéditeur. Merci. >>>>>> >>>>>> -- >>>>>> -- >>>>>> ------------------ >>>>>> 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]. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/ops4j/cb747b43-f883-4c89-92a7-176f03e7f991n%40googlegroups.com >>>> <https://groups.google.com/d/msgid/ops4j/cb747b43-f883-4c89-92a7-176f03e7f991n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- > -- > ------------------ > 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ops4j/08e6bf92-e96d-404c-87d1-5234595f47d1n%40googlegroups.com > <https://groups.google.com/d/msgid/ops4j/08e6bf92-e96d-404c-87d1-5234595f47d1n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- -- ------------------ 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAAdXmhrpPBF57rzEgAg0XXMRCa%2BYkKhR64O2Ldmehq-CmzfwyQ%40mail.gmail.com.
