Very good. Thanks a lot ! On Friday, January 22, 2021 at 11:37:01 AM UTC+3 [email protected] wrote:
> Hello > > Here you are: > 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/WhiteboardResourcesTest.java#L122-L123 > > - it registers an Object.class OSGi service with > "osgi.http.whiteboard.resource.pattern" property and also with > osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=c1) > property, so resources are properly available from different (than "/") > context path. > > Also here's a test with welcome files: > 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/WhiteboardWelcomeFilesTest.java#L135 > > Remember that welcome files are completely forgotten by Whiteboard > specification, although they're very important from the point of view of > resource access. Pax Web 7 had consistency problems to serve welcome files > in the same manner for Tomcat, Jetty and Undertow. Also trailing slash (or > lack of it) was handled differently. In Pax Web it's not. > > regards > Grzegorz Grzybek > > pt., 22 sty 2021 o 09:08 Denis Anisimov <[email protected]> napisał(a): > >> >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 >> >> <https://groups.google.com/d/msgid/ops4j/f9310059-a8dc-4652-b5e9-64425d15b5dan%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/72a6370d-4951-46e1-b8ed-272b1ecdac6fn%40googlegroups.com.
