Yeah..........
Thank you for the link to the ticket.
This is exactly what I've just found.
That's the reason why nothing works for me even when I deploy the bundle
with ServletContextListener BEFORE the bundle which registers Servlet.
The reason is: I have a filter in the service declaration:
*@Component*(immediate = true, property = {
HttpWhiteboardConstants.*HTTP_WHITEBOARD_LISTENER* + "=true",
HttpWhiteboardConstants.*HTTP_WHITEBOARD_CONTEXT_SELECT* + "=("
+ HttpWhiteboardConstants.*HTTP_WHITEBOARD_CONTEXT_NAME*
+ "=*)" }, service = { ServletContextListener.class,
TestServletContextListener.class }, scope =
*ServiceScope*.*SINGLETON*)
And exactly the same bundle with one single TestServletContextListener
which worked (as I mentioned before)
immediately stopped to work after this change.
So thank you for confirmation about that issue.
OK, I will have to find the ways to workaround these issues.
In the end there is always a choice to use felix-jetty impl for HTTP
WHITEBOARD instead of PAX.
On Friday, January 22, 2021 at 10:30:50 AM UTC+3 [email protected] wrote:
> 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/56365efa-58e4-4d96-8d5d-470d9178eea5n%40googlegroups.com.
