Re: NPE in coyote InternalNioOutputBuffer
a) are not thread-safe
b) are cached and reused for subsequent incoming requests.
Thanks for helpful response.
I did not expect these tomcat features...
Now I am reinspecting my implementation and I have found one place that
seems fuzzy to me.
public void onTimeout(AsyncEvent ae) throws IOException {
ae.getAsyncContext().getResponse().getWriter().write(no changes);
}
There is not much in the documentation.
AsyncListener has method onTimeout. I am using it to inform subscribers
that there is no change. Is it legal to sent back some response on timeout
(like no changes) ? No recycle can happen during this action ? I have
looked in the sources and request recycle is called after this listener is
executed.
I just want to be sure that this order is always the same and any other
tomcat feature will not interfere.
best regards
Peter Cipov
-
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 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
Encrypting AJP13 Traffic With isapi_redirect
Does the IIS isapi_redirect.dll support encrypting AJP13 traffic? We are setting up IIS 7.5 talking to GlassFish 3.1.2.2 using the 1.2.37 isapi_redirect.dll. We have everything working with HTTPS/SSL coming into IIS and passing through to GlassFish using unencrypted AJP13, but want to also encrypt the traffic between IIS and GlassFish. There is GlassFish documentation for enabling SSL between Apache and GlassFish using mod_jk, and it involves setting some mod_jk settings (in addition to some settings in GlassFish to enable SSL on that end). I’ve made the changes to GlassFish to enable SSL on the passthrough port, but can’t find any settings for isapi_redirect that would indicate using SSL. The GlassFish documentation for using SSL with mod_jk involved some settings like “JkExtractSSL On” and “JkHTTPSIndicator HTTPS”, but there is nothing like that available for the isapi_redirect configuration. I can access the site fine using the built-in GlassFish HTTPS/SSL port 8181, but I’m getting a 502 error when trying to do the IIS passthrough to the SSL-enabled AJP13 port in GlassFish. Following is what I’m seeing in the isapi_redirect log file: [Thu May 30 17:51:44.219 2013] [224:1172] [debug] jk_shutdown_socket::jk_connect.c (732): About to shutdown socket 1300 [127.0.0.1:61402 - 127.0.0.1:8009] [Thu May 30 17:51:44.219 2013] [224:1172] [debug] jk_shutdown_socket::jk_connect.c (803): shutting down the read side of socket 1300 [127.0.0.1:61402 - 127.0.0.1:8009] [Thu May 30 17:51:44.219 2013] [224:1172] [debug] jk_shutdown_socket::jk_connect.c (814): Shutdown socket 1300 [127.0.0.1:61402 - 127.0.0.1:8009] and read 0 lingering bytes in 0 sec. [Thu May 30 17:51:44.219 2013] [224:1172] [info] ajp_connection_tcp_get_message::jk_ajp_common.c (1259): (worker1) can't receive the response header message from tomcat, tomcat (127.0.0.1:8009) has forced a connection close for socket 1300 [Thu May 30 17:51:44.219 2013] [224:1172] [error] ajp_get_reply::jk_ajp_common.c (2126): (worker1) Tomcat is down or refused connection. No response has been sent to the client (yet) Is encrypting the AJP13 traffic possible with isapi_redirect.dll and I just don’t have something configured properly, or am I trying to do something that isn’t supported natively? I saw some old posts about needing to use other methods to encrypt the traffic, like VPNs or IPSEC, but they also indicated that something was in the works to support this natively. Thanks, Jonathan This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Exelis Inc. The recipient should check this e-mail and any attachments for the presence of viruses. Exelis Inc. accepts no liability for any damage caused by any virus transmitted by this e-mail.
Re: Encrypting AJP13 Traffic With isapi_redirect
On 31.05.2013 01:38, Cochran, Jonathan - IS.CONTRACTOR wrote: Does the IIS isapi_redirect.dll support encrypting AJP13 traffic? We are setting up IIS 7.5 talking to GlassFish 3.1.2.2 using the 1.2.37 isapi_redirect.dll. We have everything working with HTTPS/SSL coming into IIS and passing through to GlassFish using unencrypted AJP13, but want to also encrypt the traffic between IIS and GlassFish. There is GlassFish documentation for enabling SSL between Apache and GlassFish using mod_jk, and it involves setting some mod_jk settings (in addition to some settings in GlassFish to enable SSL on that end). I’ve made the changes to GlassFish to enable SSL on the passthrough port, but can’t find any settings for isapi_redirect that would indicate using SSL. The GlassFish documentation for using SSL with mod_jk involved some settings like “JkExtractSSL On” and “JkHTTPSIndicator HTTPS”, but there is nothing like that available for the isapi_redirect configuration. I can access the site fine using the built-in GlassFish HTTPS! /SSL por t 8181, but I’m getting a 502 error when trying to do the IIS passthrough to the SSL-enabled AJP13 port in GlassFish. Following is what I’m seeing in the isapi_redirect log file: mod_jk and the isapi redirector both do not support encrypting the connection between web server and servlet engine. You could set up an encrypted tunnel. The SSL options for mod_jk are just to control what kind if information about the HTTPS connection betwen client and web server are forwarded from there to the servlet engine (like original ssl session id, crtificate details etc.). [Thu May 30 17:51:44.219 2013] [224:1172] [debug] jk_shutdown_socket::jk_connect.c (732): About to shutdown socket 1300 [127.0.0.1:61402 - 127.0.0.1:8009] [Thu May 30 17:51:44.219 2013] [224:1172] [debug] jk_shutdown_socket::jk_connect.c (803): shutting down the read side of socket 1300 [127.0.0.1:61402 - 127.0.0.1:8009] [Thu May 30 17:51:44.219 2013] [224:1172] [debug] jk_shutdown_socket::jk_connect.c (814): Shutdown socket 1300 [127.0.0.1:61402 - 127.0.0.1:8009] and read 0 lingering bytes in 0 sec. [Thu May 30 17:51:44.219 2013] [224:1172] [info] ajp_connection_tcp_get_message::jk_ajp_common.c (1259): (worker1) can't receive the response header message from tomcat, tomcat (127.0.0.1:8009) has forced a connection close for socket 1300 [Thu May 30 17:51:44.219 2013] [224:1172] [error] ajp_get_reply::jk_ajp_common.c (2126): (worker1) Tomcat is down or refused connection. No response has been sent to the client (yet) Is encrypting the AJP13 traffic possible with isapi_redirect.dll and I just don’t have something configured properly, or am I trying to do something that isn’t supported natively? I saw some old posts about needing to use other methods to encrypt the traffic, like VPNs or IPSEC, but they also indicated that something was in the works to support this natively. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
