Re: Interceptor question
On Fri, Dec 09, 2011 at 03:37:10PM -0500, Dave Newton wrote: > That was a long question :( Yes, I wanted to make sure that I had covered all of what I had already done. > Yes; the default-intereptor-ref element is a per-package configuration, as > described in the pacakge configuration docs [1]. Unfortunately, when I had tried that before, it didn't seem to work. I guess that there is something else wrong. One thing that I have been experimenting with since then, is the position in the stack of this particular interceptor, which is dealing with authentication. I will work on it. Thanks, Brian - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Interceptor question
That was a long question :( On Fri, Dec 9, 2011 at 2:48 PM, Brian McCullough wrote: > I would like to be able to define a particular Interceptor Stack as being > the Default for a particular packageName, and applicable to the whole > Package and its Actions, instead of having to code interceptor-def for each > Action. > > Is this possible? > Yes; the default-intereptor-ref element is a per-package configuration, as described in the pacakge configuration docs [1]. Dave [1] http://struts.apache.org/2.x/docs/package-configuration.html
Interceptor question
Folks, I don't seem to be able to ask this question in a way that lets the search engines give me a useful answer, so I am coming here. I am working on adding functionality to an application that I inherited. I have struts.xml as well as several struts-packageName.xml files in WEB-INF/classes. In struts.xml I have several "custom" interceptors defined, as well as interceptor stacks that use those, as well as the "built-in" interceptors. One of those stacks is defined as default with default-interceptor-ref. The struts-packageName.xml files are each included with Include File statements at the top of struts.xml. Each of them has the following at the top: They also have various Action definitions, specific to the particular packageName. My question has to do with the Interceptors and Interceptor Stacks defined in struts.xml. Incidentally, all of those definitions are after the Include File statements for all of the struts-packageName.xml files. I would like to be able to define a particular Interceptor Stack as being the Default for a particular packageName, and applicable to the whole Package and its Actions, instead of having to code interceptor-def for each Action. Is this possible? Thanks, Brian - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Struts 2 Interceptor Question
> Can a Struts 2 interceptor change/add a request or session parameter? Yes, and you can look at an example when you have the source and open: com.opensymphony.xwork2.interceptor.ParametersInterceptor > I'm trying to write a Struts 2 Exception Handler which is executed whenever > there is an uncaught exception. To do that, I plan to use a custom > interceptor based on the existing Struts 2 ExceptionMappingInterceptor. My > custom interceptor needs to be able to send customized text to a jsp page > which is displayed to the user. For example, a unique incidentId number will > be displayed on the jsp page. > > Inside my intercept method, I can access the AccessInvocation's > InvocationContext which contains the following methods: > > Map - getParameters() > Map - getSession() > void - put(key, value) > Object - get(key) > > I tried modifying the Map returned by getParameters() and getSession(). I > also tried using put(key, value). However, my changes were not visible on > the jsp page when I used these methods. > Is it possible to modify a request or session variable from an interceptor? > Is there a better way to load dynamic information into a struts > global-exception-mapping error page? As far as I can see it is done inside setParameters and its done via the ActionContext method. But I am not sure why your changes are not reflected. Anyway, hope this class gives you some inspiration. Cheers, Christian - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Struts 2 Interceptor Question
Can a Struts 2 interceptor change/add a request or session parameter? I'm trying to write a Struts 2 Exception Handler which is executed whenever there is an uncaught exception. To do that, I plan to use a custom interceptor based on the existing Struts 2 ExceptionMappingInterceptor. My custom interceptor needs to be able to send customized text to a jsp page which is displayed to the user. For example, a unique incidentId number will be displayed on the jsp page. Inside my intercept method, I can access the AccessInvocation's InvocationContext which contains the following methods: Map - getParameters() Map - getSession() void - put(key, value) Object - get(key) I tried modifying the Map returned by getParameters() and getSession(). I also tried using put(key, value). However, my changes were not visible on the jsp page when I used these methods. Is it possible to modify a request or session variable from an interceptor? Is there a better way to load dynamic information into a struts global-exception-mapping error page? -- View this message in context: http://struts.1045723.n5.nabble.com/Struts-2-Interceptor-Question-tp4332934p4332934.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Interceptor question
By the way, Pawel, at that link some software seems to have severely butchered your xml in the struts.xml part. Chris -Original Message- From: Dale Newfield To: Struts Users Mailing List Sent: Wed, Sep 9, 2009 12:41 pm Subject: Re: Interceptor question Paweł Wielgus wrote: > Mike You can take a look at my post about this problem [1] > and read more about Spring Security (ACEGI). > > [1] - > http://poulwiel.blogspot.com/2009/01/intercepting-all-actions-inside-my-app.html I don't understand what your problem is. As you state, you can set the interceptor stack for each package, and you have two separate packages that you want to have two separate interceptor stacks. You also illustrate how the interceptor can make decisions based on the mapping. What's the problem? -Dale - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Interceptor question
Paweł Wielgus wrote: Mike You can take a look at my post about this problem [1] and read more about Spring Security (ACEGI). [1] - http://poulwiel.blogspot.com/2009/01/intercepting-all-actions-inside-my-app.html I don't understand what your problem is. As you state, you can set the interceptor stack for each package, and you have two separate packages that you want to have two separate interceptor stacks. You also illustrate how the interceptor can make decisions based on the mapping. What's the problem? -Dale - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Interceptor question
Hi all, Mike You can take a look at my post about this problem [1] and read more about Spring Security (ACEGI). [1] - http://poulwiel.blogspot.com/2009/01/intercepting-all-actions-inside-my-app.html Best greetings, Paweł Wielgus. 2009/9/9 Dale Newfield : > Mike Baranski wrote: >> >> If I run an interceptor on an action, then redirect, is the same >> interceptor >> run on the redirected-to action? > > "then redirect" means that request is done, and the browser will be > submitting a new request. That new request gets processed according to the > action/interceptor definition appropriate to the url. > > -Dale > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Interceptor question
Mike Baranski wrote: If I run an interceptor on an action, then redirect, is the same interceptor run on the redirected-to action? "then redirect" means that request is done, and the browser will be submitting a new request. That new request gets processed according to the action/interceptor definition appropriate to the url. -Dale - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Interceptor question
Wes Wannemacher wrote: If the action you are redirecting to has the same interceptor-stack (via package inheritance or interceptor configuration), then the answer is 'yes' So the answer is to not put this "force to password change page" interceptor in the stack used for the password change page, or make that interceptor a no-op if the appropriate action is already about to be invoked. -Dale On Wed, Sep 9, 2009 at 12:12 PM, Mike Baranski wrote: I have a question about an interceptor. If I run an interceptor on an action, then redirect, is the same interceptor run on the redirected-to action? I'm redirecting to a change password page if a password is over x days old, so do I need to specify a different interceptor stack for the change password action to prevent an infinite loop of redirection? Thanks, Mike. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Interceptor question
If the action you are redirecting to has the same interceptor-stack (via package inheritance or interceptor configuration), then the answer is 'yes' -Wes On Wed, Sep 9, 2009 at 12:12 PM, Mike Baranski wrote: > I have a question about an interceptor. > > If I run an interceptor on an action, then redirect, is the same interceptor > run on the redirected-to action? > > I'm redirecting to a change password page if a password is over x days old, > so do I need to specify a different interceptor stack for the change > password action to prevent an infinite loop of redirection? > > Thanks, > Mike. > > > > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > -- Wes Wannemacher Head Engineer, WanTii, Inc. Need Training? Struts, Spring, Maven, Tomcat... Ask me for a quote! - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Interceptor question
I have a question about an interceptor. If I run an interceptor on an action, then redirect, is the same interceptor run on the redirected-to action? I'm redirecting to a change password page if a password is over x days old, so do I need to specify a different interceptor stack for the change password action to prevent an infinite loop of redirection? Thanks, Mike. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
RE: [S2] Interceptor question
I'm sorry, I should have been more specific with my original question. I need to secure struts *.action URIs. Nothing else, be it by port, directory mapping, or context name. Right now. You see, my app supports adding users and changing their roles via web UI (hence the DB). It also supports adding sections and/or pages at run-time, which requires the capability to dynamically add new URI-role mappings. For these reasons, container-managed security is out of the question. Recompiling, redeploying, and/or restarting are best avoided. This is what the current framework affords me. These are the reasons I was thinking app-managed security. The current framework uses a filter to do authentication & authorization validation. It throws typed exceptions which are handled via web.xml's error-page. I was having difficulty maintaining sessions during this error page redirection, which makes it difficult to maintain the originally-requested URL for redirection to upon successful login. Aside from that it works well. But I want to expand my skillset, so I can take this opportunity to work with Interceptors. Or Spring. Or something else, but these two seem to have more traction than anything else so that's probably where I'll land. -Original Message- From: Martin Gainty [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 16, 2008 9:54 PM To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: RE: [S2] Interceptor question dave- which urls needs to be secured? Struts webapp? All the webapps of your container? everything under Port 80? take a look at http://www.devarticles.com/c/a/Java/Securing-Struts-Applications/ Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. > Subject: [S2] Interceptor question > Date: Tue, 16 Sep 2008 16:37:26 -0400 > From: [EMAIL PROTECTED] > To: user@struts.apache.org; [EMAIL PROTECTED] > > I have a mature, home-grown database-backed authentication & > authorization framework. > It does not conform to JAAS or anything remotely similar. > I'd like to harness in a new struts2 site, because the core > functionality exists, it pre-populated, etc > > At a very high level, would I be able to get some advice on a path > forward: should I be thinking of a custom Interceptor, extending an > existing Interceptor, using Spring security, or something completely > different? > Thanks is advance, > -dave > > Notice: This e-mail message, together with any attachments, contains > information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, > New Jersey, USA 08889), and/or its affiliates (which may be known > outside the United States as Merck Frosst, Merck Sharp & Dohme or > MSD and in Japan, as Banyu - direct contact information for affiliates is > available at http://www.merck.com/contact/contacts.html) that may be > confidential, proprietary copyrighted and/or legally privileged. It is > intended solely for the use of the individual or entity named on this > message. If you are not the intended recipient, and have received this > message in error, please notify us immediately by reply e-mail and > then delete it from your system. _ Want to do more with Windows Live? Learn "10 hidden secrets" from Jamie. http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cn s!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008 Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [S2] Interceptor question
dave- which urls needs to be secured? Struts webapp? All the webapps of your container? everything under Port 80? take a look at http://www.devarticles.com/c/a/Java/Securing-Struts-Applications/ Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. > Subject: [S2] Interceptor question > Date: Tue, 16 Sep 2008 16:37:26 -0400 > From: [EMAIL PROTECTED] > To: user@struts.apache.org; [EMAIL PROTECTED] > > I have a mature, home-grown database-backed authentication & > authorization framework. > It does not conform to JAAS or anything remotely similar. > I'd like to harness in a new struts2 site, because the core > functionality exists, it pre-populated, etc > > At a very high level, would I be able to get some advice on a path > forward: should I be thinking of a custom Interceptor, extending an > existing Interceptor, using Spring security, or something completely > different? > Thanks is advance, > -dave > > Notice: This e-mail message, together with any attachments, contains > information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, > New Jersey, USA 08889), and/or its affiliates (which may be known > outside the United States as Merck Frosst, Merck Sharp & Dohme or > MSD and in Japan, as Banyu - direct contact information for affiliates is > available at http://www.merck.com/contact/contacts.html) that may be > confidential, proprietary copyrighted and/or legally privileged. It is > intended solely for the use of the individual or entity named on this > message. If you are not the intended recipient, and have received this > message in error, please notify us immediately by reply e-mail and > then delete it from your system. _ Want to do more with Windows Live? Learn “10 hidden secrets” from Jamie. http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008
[S2] Interceptor question
I have a mature, home-grown database-backed authentication & authorization framework. It does not conform to JAAS or anything remotely similar. I'd like to harness in a new struts2 site, because the core functionality exists, it pre-populated, etc At a very high level, would I be able to get some advice on a path forward: should I be thinking of a custom Interceptor, extending an existing Interceptor, using Spring security, or something completely different? Thanks is advance, -dave Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system.
Re: [S2] Interceptor Question (Thread Safety)
[...] [this] means that there are no thread safety issues *of the discussed kind* with interceptor instance variables. [...] should have been clear from the discussion context, but thanks for further clarification :) Dave Newton schrieb: > --- Rene Gielen <[EMAIL PROTECTED]> wrote: >> [this] means that there are no thread safety issues >> with interceptor instance variables. > > Well, not in terms of a property of the same name set > in different interceptor references in a config file > (er... it made sense in my head) but interceptors > still need to keep thread safety in mind, just like > servlets or S1 actions--instance variables are still > shared across the applications, it's just that each > interceptor-ref is a separate instance. > > d. > > > > > > Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, > news, photos & more. > http://mobile.yahoo.com/go?refer=1GNXIC > > - > 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]
Re: [S2] Interceptor Question (Thread Safety)
--- Rene Gielen <[EMAIL PROTECTED]> wrote: > [this] means that there are no thread safety issues > with interceptor instance variables. Well, not in terms of a property of the same name set in different interceptor references in a config file (er... it made sense in my head) but interceptors still need to keep thread safety in mind, just like servlets or S1 actions--instance variables are still shared across the applications, it's just that each interceptor-ref is a separate instance. d. Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [S2] Interceptor Question (Thread Safety)
I'll add some words on that to the docs. Am Di, 10.07.2007, 13:42, schrieb Hoying, Ken: > 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: > > > > > > > barfoobar > > /index.jsp > > > > barfoo > > /index.jsp > > > > 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 >> >> 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 >>
RE: [S2] Interceptor Question (Thread Safety)
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: barfoobar /index.jsp barfoo /index.jsp 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 > > 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]
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: barfoobar /index.jsp barfoo /index.jsp 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 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]
RE: [S2] Interceptor Question (Thread Safety)
Can someone provide a definitive answer on this then? It is obviously a key infrastructure and implementation issue. Thank you! -Original Message- From: Musachy Barroso [mailto:[EMAIL PROTECTED] Sent: Monday, July 09, 2007 11:30 AM To: Struts Users Mailing List Subject: Re: [S2] Interceptor Question (Thread Safety) If that's right then I've been wrong for a long time :). I think that interceptor instances are reused between requests. On DefaultActionProxy:prepare: config = configuration.getRuntimeConfiguration().getActionConfig(namespace, actionName); that configuration is not instantiated on each request. musachy On 7/9/07, Hoying, Ken <[EMAIL PROTECTED]> wrote: > > 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] > > -- "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [S2] Interceptor Question (Thread Safety)
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 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] > > -- 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]
Re: [S2] Interceptor Question (Thread Safety)
If that's right then I've been wrong for a long time :). I think that interceptor instances are reused between requests. On DefaultActionProxy:prepare: config = configuration.getRuntimeConfiguration().getActionConfig(namespace, actionName); that configuration is not instantiated on each request. musachy On 7/9/07, Hoying, Ken <[EMAIL PROTECTED]> wrote: 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] -- "Hey you! Would you help me to carry the stone?" Pink Floyd
RE: [S2] Interceptor Question (Thread Safety)
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]
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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
[S2] Interceptor Question (Thread Safety)
>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.
