Thank you, Rene! This is a great help to me and allows me to move forward with my current implementation. It might be a good idea for someone from the Struts2 project to update the documentation with Rene's finding, as I am sure others will also find this unclear and concerning.
Thank you again! -----Original Message----- From: Rene Gielen [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 10, 2007 2:38 AM To: Struts Users Mailing List Subject: Re: [S2] Interceptor Question (Thread Safety) Ken, others, now for the definitive answer: There is one instance per interceptor ref, thus interceptor instances being unique within the scope they are referenced in. Example: <package name="foo" extends="struts-default" namespace="/foo"> <interceptors> <interceptor name="foo" class="FooInterceptor"/> </interceptors> <action name="bar1" class="com.opensymphony.xwork2.ActionSupport"> <interceptor-ref name="foo"> <param name="bar">barfoobar</param> </interceptor-ref> <result name="success">/index.jsp</result> </action> <action name="bar2" class="com.opensymphony.xwork2.ActionSupport"> <interceptor-ref name="foo"> <param name="bar">barfoo</param> </interceptor-ref> <result name="success">/index.jsp</result> </action> </package> This will cause two instances of FooInterceptor being created, one with bar property set to "barfoobar" and one with "barfoo". The interceptors parameters given in struts.xml are only set once per instance, which means that there are no thread safety issues with interceptor instance variables. HTH, Rene Rene Gielen schrieb: > Uahhh, > > thanks for pointing out this information, I was way to fast to reply > on the said question - I recalled it wrong. Indeed documentation is > right here, they need to be thread safe - sorry for causing > misunderstanding here. > > Anyway, this does not answer the question if interceptor parameters > introduce thread safety issues. The builder mechanism is a little > complicated here, but AFAIK Interceptor instances are unique to the > scope they are configured in. I will check this tonight to ensure we > do not face a problem here with current implementation and hopefully > can provide a reliable answer then. > > Regards, > Rene > > <interceptor name=" > > Am Mo, 9.07.2007, 15:01, schrieb Hoying, Ken: >> Thanks, Rene! >> >> Someone might want to update the documentation to make this clearer. >> The following document seems to indicate otherwise: >> >> http://struts.apache.org/2.x/docs/writing-interceptors.html >> >> Thread Safety >> Interceptors must be thread-safe! >> >> A Struts 2 Action instance is created for every request and do not >> need to be thread-safe. Conversely, Interceptors are shared between >> requests and must be thread-safe. >> >> -----Original Message----- >> From: Rene Gielen [mailto:[EMAIL PROTECTED] >> Sent: Sunday, July 08, 2007 7:00 AM >> To: Struts Users Mailing List >> Subject: Re: [S2] Interceptor Question (Thread Safety) >> >> Ken, >> >> there is no problem at all since s2 interceptor instances, as well as >> action instances, are created per ActionInvokation, which means they >> are always operated in a single thread. >> >> Regards, >> Rene >> >> Hoying, Ken schrieb: >>> From what I understand from reading the documentation, interceptors >>> are suppose to be thread safe. However, I have noticed that some of >>> the interceptors do contain instance variables and I have seen some >>> examples where these variables are set or modified from with in the >>> action configurations. >>> >>> For example, the File Upload interceptor allows you to set the >>> maximumSize and allowedTypes. Is this going to work if I have 2 >>> different actions each allowing different maximumSize and >> allowedTypes? >>> This does not seem thread safe to me. Is there only one instance of >>> the interceptors or does maybe each action mapping have its own >>> instance of the interceptors? >>> >>> Thanks in advance, >>> Ken >>> >>> >>> >>> ----------------------------------------- >>> ***Note:The information contained in this message may be privileged >>> and confidential and protected from disclosure. If the reader of >>> this message is not the intended recipient, or an employee or agent >>> responsible for delivering this message to the intended recipient, >>> you are hereby notified that any dissemination, distribution or >>> copying of this communication is strictly prohibited. If you have >>> received this communication in error, please notify the Sender >>> immediately by replying to the message and deleting it from your computer. Thank you. >>> Premier Inc. >> -- Rene Gielen | http://it-neering.net/ Aachen | PGP-ID: BECB785A Germany | gielen at it-neering.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
