Re: Making sure I understand application startup order correctly
On 01/06/2013 16:59, Nick Williams wrote: Off-topic, I should point out that I believe this is also a potential flaw in the Tomcat WebSocket filter registration. It is also mapped isMatchAfter=false. So, if someone were to add similar logging/auth filters to their deployment descriptor, they would only ever match AFTER the WebSocket filter, which I can't imagine would ever be desired. IMO, the WebSocket filter registration needs to be isMatchAfter=true. This would ensure that logging/auth filters in the deployment descriptor matched first, and also eliminate my need to have an absolute-ordering. Fair point. I'll get that changed. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Making sure I understand application startup order correctly
On May 31, 2013, at 5:06 AM, Mark Thomas wrote: On 30/05/2013 23:42, Nick Williams wrote: I still have some uncertainties with a couple: #2: 8.2.4 says of ServletContainerInitializers: the order in which these services are discovered MUST follow the application’s class loading delegation model. That is poor specification language. Discovery != invocation although I suspect that is what is meant. So, SCI /classes/ in the application should be discovered before SCI classes in the container /if/ parent last class loading is used (it is by default in Tomcat), and SCI classes in the container should be discovered before SCI classes in the application /if/ parent first class loading is used (it is by default in WebSphere, for example). If they get reordered from the order they're discovered in before they're fired, I'm not sure why Tomcat is doing that. You say that Tomcat, specifically, respects the fragment order (even though the spec doesn't say you must do so), but SCIs provided by the container don't belong to fragments and thus can't have a fragment order, so that ordering scheme only works for SCIs provided by the application. So if Tomcat is ordering them differently from the order they're discovered in, how is it determining that order? Tomcat first scans for JARs and fragments. Dummy fragments are created for any discovered JAR that doesn't have one. The JarScanner will always scan WEB-INF/lib before it scans the container regardless of the setting of delegate on the Context. That is one possible bug. Tomcat then orders the fragments it has discovered. This includes fragments from container JARs. There is another potential bug here as fragments in container JARs should be ignored. Tomcat then looks in the ordered fragments for SCIs. A possible bug here is that SCIs from the container should always be processed and currently they could be ignored based on ordering. It appears to be possible for a container JAR with an SCI that should always be used to be excluded from a webapp. A third possible bug. The counter point is that, as per the spec, it should be impossible to disable any container provided SCI on a per application basis. #6: 8.2.3(1) says The order for listeners, servlets, filters if relevant must be specified in either the web-fragment.xml or the web.xml. 8.2.2(1)(b) says The web.xml and WEB-INF/classes MUST be processed before any of the web-fragments listed in the absolute-ordering element. 8.2.2(2)(b) says The web.xml and WEB-INF/classes MUST be processed before any of the web-fragments listed in the ordering element. So, I know for sure that filters in web.xml and web-fragment.xml come before programmatically-registered filters (this was part of my mistake before). What I'm still uncertain on is: - If there are /no/ filters in web.xml or web-fragment.xml and filters are /only/ registered programmatically, is their order unspecified, or are they in the order addFilter is called? Again, look for isMatchAfter in the registration interface. - What comes first: @WebFilters or programmatically-registered filters? @WebFilters since annotations are merged into the associated web.xml. Or is this unspecified? - If there are filters and programmatically-registered filters, will the filters be placed on the chain in the order they are declared and /then/ the programmatic filters placed on the chain in the order they are declared, or is this unspecified? isMatchAfter Okay. I understand now. Here's one of the consequences of inability to order SCI is the spec (thankfully Tomcat supports it, but that's not portable): I have two filters: a LoggingFilter (/*) and an AuthenticationFilter (each URL pattern that needs securing). The LoggingFilter sets up information about the current request (UUID, username, etc.) in the Log4j context map, and it must come before the AuthenticationFilter, which makes sure the user is logged in. That filter must, then, come before any other filters. I add the filters in an SCI using isMatchAfter=false. Thankfully, Tomcat supports SCI ordering, so putting this in my deployment descriptor ensures that the WebSocket filter gets added after my filters: absolute-ordering namespring_web/name others / /absolute-ordering And, indeed, that worked. However, it's not guaranteed to work on all containers. Off-topic, I should point out that I believe this is also a potential flaw in the Tomcat WebSocket filter registration. It is also mapped isMatchAfter=false. So, if someone were to add similar logging/auth filters to their deployment descriptor, they would only ever match AFTER the WebSocket filter, which I can't imagine would ever be desired. IMO, the WebSocket filter registration needs to be isMatchAfter=true. This would ensure that logging/auth filters in the deployment descriptor matched first, and also eliminate my need to have an
Re: Making sure I understand application startup order correctly
On 30/05/2013 23:42, Nick Williams wrote: I still have some uncertainties with a couple: #2: 8.2.4 says of ServletContainerInitializers: the order in which these services are discovered MUST follow the application’s class loading delegation model. That is poor specification language. Discovery != invocation although I suspect that is what is meant. So, SCI /classes/ in the application should be discovered before SCI classes in the container /if/ parent last class loading is used (it is by default in Tomcat), and SCI classes in the container should be discovered before SCI classes in the application /if/ parent first class loading is used (it is by default in WebSphere, for example). If they get reordered from the order they're discovered in before they're fired, I'm not sure why Tomcat is doing that. You say that Tomcat, specifically, respects the fragment order (even though the spec doesn't say you must do so), but SCIs provided by the container don't belong to fragments and thus can't have a fragment order, so that ordering scheme only works for SCIs provided by the application. So if Tomcat is ordering them differently from the order they're discovered in, how is it determining that order? Tomcat first scans for JARs and fragments. Dummy fragments are created for any discovered JAR that doesn't have one. The JarScanner will always scan WEB-INF/lib before it scans the container regardless of the setting of delegate on the Context. That is one possible bug. Tomcat then orders the fragments it has discovered. This includes fragments from container JARs. There is another potential bug here as fragments in container JARs should be ignored. Tomcat then looks in the ordered fragments for SCIs. A possible bug here is that SCIs from the container should always be processed and currently they could be ignored based on ordering. It appears to be possible for a container JAR with an SCI that should always be used to be excluded from a webapp. A third possible bug. The counter point is that, as per the spec, it should be impossible to disable any container provided SCI on a per application basis. #6: 8.2.3(1) says The order for listeners, servlets, filters if relevant must be specified in either the web-fragment.xml or the web.xml. 8.2.2(1)(b) says The web.xml and WEB-INF/classes MUST be processed before any of the web-fragments listed in the absolute-ordering element. 8.2.2(2)(b) says The web.xml and WEB-INF/classes MUST be processed before any of the web-fragments listed in the ordering element. So, I know for sure that filters in web.xml and web-fragment.xml come before programmatically-registered filters (this was part of my mistake before). What I'm still uncertain on is: - If there are /no/ filters in web.xml or web-fragment.xml and filters are /only/ registered programmatically, is their order unspecified, or are they in the order addFilter is called? Again, look for isMatchAfter in the registration interface. - What comes first: @WebFilters or programmatically-registered filters? @WebFilters since annotations are merged into the associated web.xml. Or is this unspecified? - If there are filters and programmatically-registered filters, will the filters be placed on the chain in the order they are declared and /then/ the programmatic filters placed on the chain in the order they are declared, or is this unspecified? isMatchAfter My overriding concern is ordering something before anything else. Based on reading the various specs, reading the link Pid sent me, and your answers, I've concluded the following, which I pray someone can tell me is wrong, because if I'm right it seems like a backwards movement in the spec: - In Servlet 2.5, there was a way to execute something before anything else on application startup. You could define a ServletContextListener as the /very first listener/ in the deployment descriptor (web.xml), and its contextInitialized method would always be invoked before the initialize methods on any other listeners, servlets, or filters. - As of Servlet 3.0 and the introduction of ServletContainerInitializers, there is no longer a way to guarantee that something can be executed before anything else. A) Any ServletContainerInitializers' onStartup methods will always be called before ServletContextListeners' contextInitialized methods, so you can't rely on the ServletContextListener to come first anymore. B) You can't create your own ServletContainerInitializer and make it run before any others because the order of ServletContainerInitializers is unspecified. C) You can disable all web fragments with absolute-ordering / and that will stop those SCIs from firing but you still can't stop the container SCIs from firing so, again, there's no way to *make* something run first anymore. I hope I'm wrong about this... In Tomcat you can define an absolute order and the SCIs from the JARs will be triggered in that order
Re: Making sure I understand application startup order correctly
On May 29, 2013, at 6:58 AM, Pid wrote: On 29/05/2013 00:24, Nick Williams wrote: Guys, Can some of the fine experts on this list double check my assertions below and let me know if I'm going wrong anywhere? I hope I got it all right. :-) Assertion #1 If metadata-complete=true is present in the deployment descriptor: A) The container does NOT scan /WEB-INF/classes for annotations, B) The container does NOT scan /WEB-INF/lib JARs for ServletContainerInitializers, The metadata-complete and invocation of ServletContainerInitializers are independent. https://java.net/jira/browse/SERVLET_SPEC-36 Thanks. I'm assuming that I got everything else correct since this is the only thing you corrected and nobody else replied. But I want to make sure I understand the discussion at this link correctly. Rajiv says here: Ordering does not apply to ServletContainerInitializers. Is that really correct? There's really no way at all to order the invocation of ServletContainerInitializers' onStartup methods??? Mark, you seemed to be involved in this discussion a lot. Is this really true??? Nick p C) The container does NOT scan /WEB-INF/lib JARs for web-fragment.xml files, and D) The container does NOT scan /WEB-INF/lib JARs for annotations. Assertion #2 If class loading is configured parent last, the ServletContainerInitializers in the application are fired before ServletContainerInitializers provided by the container. If class loading is configured parent first, the ServletContainerInitializers provided by the container fire before the ServletContainerInitializers in the application. Assertion #3 ServletContainerInitializers in the container and in /WEB-INF/lib JARs are fired before any ServletContextListeners. The order in which they are fired is determined by absolute-ordering (web.xml) and/or order (web-fragment.xml), but if neither of those are present the order is unspecified. Assertion #4 The init methods of ServletContextListeners declared in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARS are all fired BEFORE the init methods of any Filters or Servlets. The destroy methods of ServletContextListeners declared in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARs are all fired AFTER the destroy methods of any Filters or Servlets. Assertion #5 The init methods of Filters declared in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARs are all fired BEFORE the init methods of any Servlets. The destroy methods of Filters declared in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARs are all fired AFTER the destroy methods of any Servlets. Assertion #6 If any given ServletContainerInitializer is the first ServletContainerInitializer to be fired when an application starts up, and that ServletContainerInitializer adds a ServletContextListener and a Filter to the ServletContext: A) The Listener it adds will be the first Listener whose init method is called and the last Listener whose destroy method is called, B) The Filter it adds will be the first Filter whose init method is called and the last Filter whose destroy method is called, and C) The Filter will be the first Filter on the Filter chain, always. Thanks in advance, Nick - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- [key:62590808] - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Making sure I understand application startup order correctly
On 30/05/2013 21:04, Nick Williams wrote: On May 29, 2013, at 6:58 AM, Pid wrote: On 29/05/2013 00:24, Nick Williams wrote: Guys, Can some of the fine experts on this list double check my assertions below and let me know if I'm going wrong anywhere? I hope I got it all right. :-) Assertion #1 If metadata-complete=true is present in the deployment descriptor: A) The container does NOT scan /WEB-INF/classes for annotations, B) The container does NOT scan /WEB-INF/lib JARs for ServletContainerInitializers, The metadata-complete and invocation of ServletContainerInitializers are independent. https://java.net/jira/browse/SERVLET_SPEC-36 Thanks. I'm assuming that I got everything else correct since this is the only thing you corrected and nobody else replied. Or pid just stopped at the first invalid assumption ;) But I want to make sure I understand the discussion at this link correctly. Rajiv says here: Ordering does not apply to ServletContainerInitializers. Is that really correct? There's really no way at all to order the invocation of ServletContainerInitializers' onStartup methods??? Mark, you seemed to be involved in this discussion a lot. Is this really true??? If that is what the spec lead says then yes. Tomcat will process them in the order they are found: i.e. respecting the fragment order but you can't rely on a) any other container doing the same, b) Tomcat continuing to do the same (although it is unlikely to change unless a spec feature mandates a change) C) The container does NOT scan /WEB-INF/lib JARs for web-fragment.xml files False. The scan still occurs because the ordering elements determines whether or not SCIs are scanned for. , and D) The container does NOT scan /WEB-INF/lib JARs for annotations. Assertion #2 If class loading is configured parent last, the ServletContainerInitializers in the application are fired before ServletContainerInitializers provided by the container. If class loading is configured parent first, the ServletContainerInitializers provided by the container fire before the ServletContainerInitializers in the application. False. Ordering of SCIs from the container is undefined, as is the mechanism by which they get added to the app. It is a container specific process. Assertion #3 ServletContainerInitializers in the container and in /WEB-INF/lib JARs are fired before any ServletContextListeners. The order in which they are fired is determined by absolute-ordering (web.xml) and/or order (web-fragment.xml), but if neither of those are present the order is unspecified. Listeners defined in a single web[-fragment].xml will be fired in the order they are defined. Assertion #4 The init methods of ServletContextListeners declared in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARS are all fired BEFORE the init methods of any Filters or Servlets. The destroy methods of ServletContextListeners declared in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARs are all fired AFTER the destroy methods of any Filters or Servlets. Assertion #5 The init methods of Filters declared in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARs are all fired BEFORE the init methods of any Servlets. The destroy methods of Filters declared in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARs are all fired AFTER the destroy methods of any Servlets. Assertion #6 If any given ServletContainerInitializer is the first ServletContainerInitializer to be fired when an application starts up, and that ServletContainerInitializer adds a ServletContextListener and a Filter to the ServletContext: A) The Listener it adds will be the first Listener whose init method is called and the last Listener whose destroy method is called, False. B) The Filter it adds will be the first Filter whose init method is called and the last Filter whose destroy method is called, and It depends. Look for isMatchAfter C) The Filter will be the first Filter on the Filter chain, always. False. The detail for all of the above is in the spec. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Making sure I understand application startup order correctly
On May 30, 2013, at 3:38 PM, Mark Thomas wrote: On 30/05/2013 21:04, Nick Williams wrote: On May 29, 2013, at 6:58 AM, Pid wrote: On 29/05/2013 00:24, Nick Williams wrote: Guys, Can some of the fine experts on this list double check my assertions below and let me know if I'm going wrong anywhere? I hope I got it all right. :-) Assertion #1 If metadata-complete=true is present in the deployment descriptor: A) The container does NOT scan /WEB-INF/classes for annotations, B) The container does NOT scan /WEB-INF/lib JARs for ServletContainerInitializers, The metadata-complete and invocation of ServletContainerInitializers are independent. https://java.net/jira/browse/SERVLET_SPEC-36 Thanks. I'm assuming that I got everything else correct since this is the only thing you corrected and nobody else replied. Or pid just stopped at the first invalid assumption ;) But I want to make sure I understand the discussion at this link correctly. Rajiv says here: Ordering does not apply to ServletContainerInitializers. Is that really correct? There's really no way at all to order the invocation of ServletContainerInitializers' onStartup methods??? Mark, you seemed to be involved in this discussion a lot. Is this really true??? If that is what the spec lead says then yes. Tomcat will process them in the order they are found: i.e. respecting the fragment order but you can't rely on a) any other container doing the same, b) Tomcat continuing to do the same (although it is unlikely to change unless a spec feature mandates a change) C) The container does NOT scan /WEB-INF/lib JARs for web-fragment.xml files False. The scan still occurs because the ordering elements determines whether or not SCIs are scanned for. , and D) The container does NOT scan /WEB-INF/lib JARs for annotations. Assertion #2 If class loading is configured parent last, the ServletContainerInitializers in the application are fired before ServletContainerInitializers provided by the container. If class loading is configured parent first, the ServletContainerInitializers provided by the container fire before the ServletContainerInitializers in the application. False. Ordering of SCIs from the container is undefined, as is the mechanism by which they get added to the app. It is a container specific process. Assertion #3 ServletContainerInitializers in the container and in /WEB-INF/lib JARs are fired before any ServletContextListeners. The order in which they are fired is determined by absolute-ordering (web.xml) and/or order (web-fragment.xml), but if neither of those are present the order is unspecified. Listeners defined in a single web[-fragment].xml will be fired in the order they are defined. Assertion #4 The init methods of ServletContextListeners declared in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARS are all fired BEFORE the init methods of any Filters or Servlets. The destroy methods of ServletContextListeners declared in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARs are all fired AFTER the destroy methods of any Filters or Servlets. Assertion #5 The init methods of Filters declared in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARs are all fired BEFORE the init methods of any Servlets. The destroy methods of Filters declared in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARs are all fired AFTER the destroy methods of any Servlets. Assertion #6 If any given ServletContainerInitializer is the first ServletContainerInitializer to be fired when an application starts up, and that ServletContainerInitializer adds a ServletContextListener and a Filter to the ServletContext: A) The Listener it adds will be the first Listener whose init method is called and the last Listener whose destroy method is called, False. B) The Filter it adds will be the first Filter whose init method is called and the last Filter whose destroy method is called, and It depends. Look for isMatchAfter C) The Filter will be the first Filter on the Filter chain, always. False. The detail for all of the above is in the spec. Yea, I've read these areas of the spec since then. I see where some of my assertions were wrong now, but I still have some uncertainties with a couple: #2: 8.2.4 says of ServletContainerInitializers: the order in which these services are discovered MUST follow the application’s class loading delegation model. So, SCI /classes/ in the application should be discovered before SCI classes in the container /if/ parent last class loading is used (it is by default in Tomcat), and SCI classes in the container should be discovered before SCI classes in the application /if/ parent first class loading is used (it is by default in WebSphere, for example). If they get reordered from the order they're discovered in before they're fired, I'm not sure why Tomcat is doing that. You say
Re: Making sure I understand application startup order correctly
On 29/05/2013 00:24, Nick Williams wrote: Guys, Can some of the fine experts on this list double check my assertions below and let me know if I'm going wrong anywhere? I hope I got it all right. :-) Assertion #1 If metadata-complete=true is present in the deployment descriptor: A) The container does NOT scan /WEB-INF/classes for annotations, B) The container does NOT scan /WEB-INF/lib JARs for ServletContainerInitializers, The metadata-complete and invocation of ServletContainerInitializers are independent. https://java.net/jira/browse/SERVLET_SPEC-36 p C) The container does NOT scan /WEB-INF/lib JARs for web-fragment.xml files, and D) The container does NOT scan /WEB-INF/lib JARs for annotations. Assertion #2 If class loading is configured parent last, the ServletContainerInitializers in the application are fired before ServletContainerInitializers provided by the container. If class loading is configured parent first, the ServletContainerInitializers provided by the container fire before the ServletContainerInitializers in the application. Assertion #3 ServletContainerInitializers in the container and in /WEB-INF/lib JARs are fired before any ServletContextListeners. The order in which they are fired is determined by absolute-ordering (web.xml) and/or order (web-fragment.xml), but if neither of those are present the order is unspecified. Assertion #4 The init methods of ServletContextListeners declared in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARS are all fired BEFORE the init methods of any Filters or Servlets. The destroy methods of ServletContextListeners declared in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARs are all fired AFTER the destroy methods of any Filters or Servlets. Assertion #5 The init methods of Filters declared in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARs are all fired BEFORE the init methods of any Servlets. The destroy methods of Filters declared in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARs are all fired AFTER the destroy methods of any Servlets. Assertion #6 If any given ServletContainerInitializer is the first ServletContainerInitializer to be fired when an application starts up, and that ServletContainerInitializer adds a ServletContextListener and a Filter to the ServletContext: A) The Listener it adds will be the first Listener whose init method is called and the last Listener whose destroy method is called, B) The Filter it adds will be the first Filter whose init method is called and the last Filter whose destroy method is called, and C) The Filter will be the first Filter on the Filter chain, always. Thanks in advance, Nick - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- [key:62590808] - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Making sure I understand application startup order correctly
Guys, Can some of the fine experts on this list double check my assertions below and let me know if I'm going wrong anywhere? I hope I got it all right. :-) Assertion #1 If metadata-complete=true is present in the deployment descriptor: A) The container does NOT scan /WEB-INF/classes for annotations, B) The container does NOT scan /WEB-INF/lib JARs for ServletContainerInitializers, C) The container does NOT scan /WEB-INF/lib JARs for web-fragment.xml files, and D) The container does NOT scan /WEB-INF/lib JARs for annotations. Assertion #2 If class loading is configured parent last, the ServletContainerInitializers in the application are fired before ServletContainerInitializers provided by the container. If class loading is configured parent first, the ServletContainerInitializers provided by the container fire before the ServletContainerInitializers in the application. Assertion #3 ServletContainerInitializers in the container and in /WEB-INF/lib JARs are fired before any ServletContextListeners. The order in which they are fired is determined by absolute-ordering (web.xml) and/or order (web-fragment.xml), but if neither of those are present the order is unspecified. Assertion #4 The init methods of ServletContextListeners declared in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARS are all fired BEFORE the init methods of any Filters or Servlets. The destroy methods of ServletContextListeners declared in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARs are all fired AFTER the destroy methods of any Filters or Servlets. Assertion #5 The init methods of Filters declared in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARs are all fired BEFORE the init methods of any Servlets. The destroy methods of Filters declared in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARs are all fired AFTER the destroy methods of any Servlets. Assertion #6 If any given ServletContainerInitializer is the first ServletContainerInitializer to be fired when an application starts up, and that ServletContainerInitializer adds a ServletContextListener and a Filter to the ServletContext: A) The Listener it adds will be the first Listener whose init method is called and the last Listener whose destroy method is called, B) The Filter it adds will be the first Filter whose init method is called and the last Filter whose destroy method is called, and C) The Filter will be the first Filter on the Filter chain, always. Thanks in advance, Nick - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
