>Yes. It takes so long, because in my daily work I'm a software maintainer and my usual practice is to code in conservative way to 1) not break anything, 2) anticipate all potential problems with the fix.
Sure, thank you very much for your answers. One last question which may be important for me: is it possible to refer to the ServletContextHelper by the name (via the osgi.http.whiteboard.context.select property) when I register web resources? I mean @HttpWhiteboardResource and refer to 140.6 Registering Resources CMPN 7 specification ( or the same can be done via *registerService * programmatically). In the example which you mentioned ServletContextHelper target the default context only. My usecase is: I should register dynamically (programmatically) a couple of resources using ServletContextHelper for the same context path which Servlet uses : I'm using some internal events when servlet becomes initialized and then register resources for the same context path. I cannot use default context here because it refers to the root context path. So I have to use ServletContextHelper with the Servlet context path and register resources via referring to this ServletContextHelper. And related question: if filter select for context doesn't work then how may I register a servlet for a custom context ? Or it doesn't work ONLY being used for ServletContextListener service ? On Friday, January 22, 2021 at 10:53:05 AM UTC+3 [email protected] wrote: > Hello (see answers inline) > > (I also invited you to OPS4J JIRA). > > czw., 21 sty 2021 o 12:03 Denis Anisimov <[email protected]> napisał(a): > >> 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. >> > > Yes - it's not about this issue... It's about lifecycle mismatch between > the container (like Jetty) and Pax Web Whiteboard. > > >> >> 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. >> > > After reading your later email I think it works in some combination ;) > > >> >> 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. >> > > See for example this specially crafted test: > https://github.com/ops4j/org.ops4j.pax.web/blob/master-improvements/pax-web-itest/pax-web-itest-server/src/test/java/org/ops4j/pax/web/itest/server/whiteboard/WhiteboardDynamicContextsTest.java#L92-L118 > > This test first registers a Servlet and only then a ServletContextHelper > matching the servlet's osgi.http.whiteboard.context.select selector. > It is then handled by reRegisterWebElements() method > <https://github.com/ops4j/org.ops4j.pax.web/blob/785781c3a074481237b7afbbcdd3d67fcac9558e/pax-web-extender-whiteboard/src/main/java/org/ops4j/pax/web/extender/whiteboard/internal/WhiteboardExtenderContext.java#L374> > . > > >> 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 ? >> > > It can't fail according to specification. What's even more confusing is > this scenario: > > 1) you register a ServletContextHelper with name "x" and context path "/x" > 2) you register a Servlet targetting "x" context with /s mapping - so it's > available under /x/s > 3) you register a ServletContextHelper with name "x" (so conflicting with > the first one), "/x2" context path and higher service ranking - your > servlet should automatically re-register itself to be available under /x2/s > path > > See also > https://github.com/ops4j/org.ops4j.pax.web/blob/master-improvements/pax-web-itest/pax-web-itest-server/src/test/java/org/ops4j/pax/web/itest/server/controller/ServerControllerBasicRegistrationTest.java#L681-L708 > > to check how servlets conflicting by name impact the context they're > registered in... > > >> 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. >> > > Yes - this is assured by proper Whiteboard implementation which I believe > Pax Web 8 already is. > > >> 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. >> > > PAXWEB-62 probably concerned something more fundamental and I think it was > created even before OSGi CMPN Whiteboard spec was created. > > >> 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. >> > > felix.http is good HttpService/Whiteboard implementation, but everything > is implemented under/inside single "dispatcher servlet" registered ONCE to > Jetty. Pax Web attempts to leverage as much as possible from the underlying > container, which may be dynamically swapped. > > >> 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. >> > > Yes. It takes so long, because in my daily work I'm a software maintainer > and my usual practice is to code in conservative way to 1) not break > anything, 2) anticipate all potential problems with the fix. > > kind regards > Grzegorz Grzybek > > >> 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/7bfbad5c-0945-4585-9739-6c166a1f21a2n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/ops4j/7bfbad5c-0945-4585-9739-6c166a1f21a2n%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/f9310059-a8dc-4652-b5e9-64425d15b5dan%40googlegroups.com.
