Re: Servlet filter as front controller
I have mentioned this before in another thread that Struts2 is breaking Servlet specification 2.4 in this regard, but have heard no comment on it which means two things either I have a point or I am way off. In Servlet specification 2.4 filters are not supposed to be accessed directly as a resource. And anything other than a jsp page need to have a Servlet mapping in order to make it accessible (as per specification). Struts 1 had ActionServlet to which *.action or *.do mapping was done. This sort of deviation from sped is causing some folks issues when it comes to using some appservers that follow the spec and you have to resort to all sort of hacks to get around it. --- On Wed, 10/7/09, Arthur Neves arthu...@gmail.com wrote: From: Arthur Neves arthu...@gmail.com Subject: Re: Servlet filter as front controller To: Struts Users Mailing List user@struts.apache.org Received: Wednesday, October 7, 2009, 11:57 PM With the filter struts2 can intercept all request. I think it's more difficult to do thinks like, the namespace struct with a servlet,i dont have sure though. On Wed, Oct 7, 2009 at 2:58 PM, Unmesh joshi unmesh_jo...@hotmail.comwrote: Hi,Struts2 uses servlet filter org.apache.struts2.dispatcher.ng.filter.StrutsExecuteFilter as front controller, rather than having a servlet act as front controller. Is there any specific advantage of using servlet filter over servlet (as in struts 1.1)? Thanks,Unmesh _ Great events make grand headlines – read them all on MSN India http://in.msn.com __ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Servlet filter as front controller
I was thinking about this issue recently and wondered if simply mapping a do-nothing servlet to * would workaround this... I thought about trying it, but I only have tomcat and jetty handy for testing, and this doesn't seem to be an issue on either one. Although, a do-nothing servlet would probably solve the other problem of mapping welcome-files to index.action. -Wes On Thu, Oct 8, 2009 at 8:36 AM, Struts Two struts...@yahoo.ca wrote: I have mentioned this before in another thread that Struts2 is breaking Servlet specification 2.4 in this regard, but have heard no comment on it which means two things either I have a point or I am way off. In Servlet specification 2.4 filters are not supposed to be accessed directly as a resource. And anything other than a jsp page need to have a Servlet mapping in order to make it accessible (as per specification). Struts 1 had ActionServlet to which *.action or *.do mapping was done. This sort of deviation from sped is causing some folks issues when it comes to using some appservers that follow the spec and you have to resort to all sort of hacks to get around it. --- On Wed, 10/7/09, Arthur Neves arthu...@gmail.com wrote: From: Arthur Neves arthu...@gmail.com Subject: Re: Servlet filter as front controller To: Struts Users Mailing List user@struts.apache.org Received: Wednesday, October 7, 2009, 11:57 PM With the filter struts2 can intercept all request. I think it's more difficult to do thinks like, the namespace struct with a servlet,i dont have sure though. On Wed, Oct 7, 2009 at 2:58 PM, Unmesh joshi unmesh_jo...@hotmail.comwrote: Hi,Struts2 uses servlet filter org.apache.struts2.dispatcher.ng.filter.StrutsExecuteFilter as front controller, rather than having a servlet act as front controller. Is there any specific advantage of using servlet filter over servlet (as in struts 1.1)? Thanks,Unmesh _ Great events make grand headlines – read them all on MSN India http://in.msn.com __ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com - 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
Re: Servlet filter as front controller
Dummy servlet should do it (as mentioned by WES), I know this in case of WAS where you are going to create plugin-xml file for your HTTP server. Without a dummy servlet mapped to *.action or *.do, Http server would fail to route any request that is mapped to *.action or *.do in the filter. --- On Thu, 10/8/09, Wes Wannemacher w...@wantii.com wrote: From: Wes Wannemacher w...@wantii.com Subject: Re: Servlet filter as front controller To: Struts Users Mailing List user@struts.apache.org Received: Thursday, October 8, 2009, 1:15 PM I was thinking about this issue recently and wondered if simply mapping a do-nothing servlet to * would workaround this... I thought about trying it, but I only have tomcat and jetty handy for testing, and this doesn't seem to be an issue on either one. Although, a do-nothing servlet would probably solve the other problem of mapping welcome-files to index.action. -Wes On Thu, Oct 8, 2009 at 8:36 AM, Struts Two struts...@yahoo.ca wrote: I have mentioned this before in another thread that Struts2 is breaking Servlet specification 2.4 in this regard, but have heard no comment on it which means two things either I have a point or I am way off. In Servlet specification 2.4 filters are not supposed to be accessed directly as a resource. And anything other than a jsp page need to have a Servlet mapping in order to make it accessible (as per specification). Struts 1 had ActionServlet to which *.action or *.do mapping was done. This sort of deviation from sped is causing some folks issues when it comes to using some appservers that follow the spec and you have to resort to all sort of hacks to get around it. --- On Wed, 10/7/09, Arthur Neves arthu...@gmail.com wrote: From: Arthur Neves arthu...@gmail.com Subject: Re: Servlet filter as front controller To: Struts Users Mailing List user@struts.apache.org Received: Wednesday, October 7, 2009, 11:57 PM With the filter struts2 can intercept all request. I think it's more difficult to do thinks like, the namespace struct with a servlet,i dont have sure though. On Wed, Oct 7, 2009 at 2:58 PM, Unmesh joshi unmesh_jo...@hotmail.comwrote: Hi,Struts2 uses servlet filter org.apache.struts2.dispatcher.ng.filter.StrutsExecuteFilter as front controller, rather than having a servlet act as front controller. Is there any specific advantage of using servlet filter over servlet (as in struts 1.1)? Thanks,Unmesh _ Great events make grand headlines – read them all on MSN India http://in.msn.com __ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com - 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 __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Servlet filter as front controller
With the filter struts2 can intercept all request. I think it's more difficult to do thinks like, the namespace struct with a servlet,i dont have sure though. On Wed, Oct 7, 2009 at 2:58 PM, Unmesh joshi unmesh_jo...@hotmail.comwrote: Hi,Struts2 uses servlet filter org.apache.struts2.dispatcher.ng.filter.StrutsExecuteFilter as front controller, rather than having a servlet act as front controller. Is there any specific advantage of using servlet filter over servlet (as in struts 1.1)? Thanks,Unmesh _ Great events make grand headlines – read them all on MSN India http://in.msn.com
RE: Servlet Filter?
Frank, thanks for the link to javawebparts. The source code there helped me a great deal. Dakota, thanks for that very detailed explanation of creating my own dispatcher, but I chose to use a filter for now. I'm just not ready to go change the buttons and existing actions at the moment. I'll look at the code you provided and maybe if I get ahead of timeline (yah, right) I'll make the move. So, I'm the big ding bat. I totally whiffed on the what are you going to map to comment made by Frank because I was under the impression that you could define url-mappings with something like /Enroll*.do. I decided to just do a path.startswith(/Enroll) to determine whether to make the check for the session bean. It seems to be working. I started out with configurable paths and ignorelists, but then thought you know what, this is a very specialized filter, I don't want someone to fiddle with configuration parms without thinking about it. My next question is whether there's a mechanism by which I can stick an ActionError in the request so that the error page can display a message to the user using the familiar Struts html:messages tag. Q -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Friday, April 07, 2006 10:03 PM To: Struts Users Mailing List Subject: Re: Servlet Filter? Yeah, that's all reasonable. Well, back to the filter then :) One thing you may want to do is have a look at the filters in Java Web Parts (http://javawebparts.sourceforge.net). We have them all implemented with some added flexibility in mapping to paths. At least that way you can only fire it when really appropriate... well... in reality, it's *still* firing, but hopefully doing a lot less work than it might otherwise need to. You can rip off the code for that extra ability (it's in the FilterHelpers class). Then again, I may be micro-optimizing here... maybe for what your filter is doing it won't be that heavyweight anyway. Sounds like that may be the case. So, even if you mapped it to *.do for instance, it might not really be a problem. Frank Quinn Stone wrote: OK. I contemplated creating a base class, but didn't like the idea of having to create a basically empty Action class for Actions that use ActionForward to forward to a jsp for display without calling an Action. And, frankly, thought it would be more complex to go learn the order of method calls of LookupDispatchAction to figure out what to override and when and how I return without bypassing some necessary processing. Sometimes I like the easy way out (as long as it's not crappy). Q -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Friday, April 07, 2006 8:24 PM To: Struts Users Mailing List Subject: Re: Servlet Filter? Hi Quinn, Quinn Stone wrote: 1. Does the Servlet filter seem a good solution? Yes, but not quite as described, and ironically its because of the answer to #2 :) 2. If I throw an EnrollmentDingBat exception from said Servlet Filter, will a handler defined in global-exceptions catch it? My suspicion is that the filter might executing too early, before struts mechanics cut in. No, it won't. As you suspect, the filter fires before Struts gets involved. However, what you *can* do, is simply forward somewhere from the filter. It could be straight to a JSP, or it could be to an Action mapping, whatever is appropriate. I think using a filter is generally a decent idea, but one thing to consider: what are you going to map it to? It sounds like you have many possible URLs that you would need to check, hence the reason for wanting some central checkpoint in the first place. The problem is, the filter is of course going to fire for *any* mapped request indiscriminately. While filters, unless poorly written, tend to not add a horrible amount of overhead, you may not want to add any at all where it isn't necessary. So, onto #3... No, three questions: 3. Any better ideas? I would probably do it instead with a custom Action base class that your other Actions extend from. Then, only extend from it those Actions where this check is needed. I mean, if you determine its needed for all of them, or nearly all of them, then I'd probably go with the filter. If you can narrow it down to just a handful though, the custom base Action might be a better answer. Q HTH, Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
RE: Servlet Filter?
On Mon, April 10, 2006 2:09 am, Quinn Stone said:
Frank, thanks for the link to javawebparts. The source code there helped
me a
great deal.
Good deal, glad to hear it!
My next question is whether there's a mechanism by which I can stick an
ActionError in the request so that the error page can display a message to
the
user using the familiar Struts html:messages tag.
Take a look at the addMessages() method of the base Action class in the
Struts source. No, wait, I'll save you the time... from 1.2.4...
protected void addMessages(HttpServletRequest request, ActionMessages
messages) {
if (messages == null){
// bad programmer! *slap*
return;
}
// get any existing messages from the request, or make a new one
ActionMessages requestMessages =
(ActionMessages)request.getAttribute(Globals.MESSAGE_KEY);
if (requestMessages == null){
requestMessages = new ActionMessages();
}
// add incoming messages
requestMessages.add(messages);
// if still empty, just wipe it out from the request
if (requestMessages.isEmpty()) {
request.removeAttribute(Globals.MESSAGE_KEY);
return;
}
// Save the messages
request.setAttribute(Globals.MESSAGE_KEY, requestMessages);
}
Add this to your filter, import the appropriate classes (Globals,
ActionMessages) and you should be all set. Use it just like you would in
your Action.
Q
Frank
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet Filter?
Don't use LookupDispatchAction. That is an obsolete solution. Check the archives on options. Don't pay attention to the nasty talk in the archives, just go check out the solutions. On 4/7/06, Quinn Stone [EMAIL PROTECTED] wrote: OK. I contemplated creating a base class, but didn't like the idea of having to create a basically empty Action class for Actions that use ActionForward to forward to a jsp for display without calling an Action. And, frankly, thought it would be more complex to go learn the order of method calls of LookupDispatchAction to figure out what to override and when and how I return without bypassing some necessary processing. Sometimes I like the easy way out (as long as it's not crappy). Q -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Friday, April 07, 2006 8:24 PM To: Struts Users Mailing List Subject: Re: Servlet Filter? Hi Quinn, Quinn Stone wrote: 1. Does the Servlet filter seem a good solution? Yes, but not quite as described, and ironically its because of the answer to #2 :) 2. If I throw an EnrollmentDingBat exception from said Servlet Filter, will a handler defined in global-exceptions catch it? My suspicion is that the filter might executing too early, before struts mechanics cut in. No, it won't. As you suspect, the filter fires before Struts gets involved. However, what you *can* do, is simply forward somewhere from the filter. It could be straight to a JSP, or it could be to an Action mapping, whatever is appropriate. I think using a filter is generally a decent idea, but one thing to consider: what are you going to map it to? It sounds like you have many possible URLs that you would need to check, hence the reason for wanting some central checkpoint in the first place. The problem is, the filter is of course going to fire for *any* mapped request indiscriminately. While filters, unless poorly written, tend to not add a horrible amount of overhead, you may not want to add any at all where it isn't necessary. So, onto #3... No, three questions: 3. Any better ideas? I would probably do it instead with a custom Action base class that your other Actions extend from. Then, only extend from it those Actions where this check is needed. I mean, if you determine its needed for all of them, or nearly all of them, then I'd probably go with the filter. If you can narrow it down to just a handful though, the custom base Action might be a better answer. Q HTH, Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - 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] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~
Re: Servlet Filter?
) {
methodName = buttonValue;
break;
}
}
}
return methodName.substring(0,methodName.indexOf('.'));
}
protected Method getMethod(String name)
throws NoSuchMethodException {
synchronized(methods) {
Method method = (Method) methods.get(name);
if (method == null) {
method = clazz.getMethod(name, types);
methods.put(name, method);
}
return (method);
}
}
protected ActionForward unspecified(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
String message = messages.getMessage( dispatch.parameter,
mapping.getPath(), getMethodName(request,mapping));
throw new ServletException(message);
}
protected ActionForward cancelled(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
return null;
}
}
Essentially, all you do is iterate through the parameters until you get to
one that ends with .dispatch. Easy, right. This is the real solution to
all the complexities of LookupDispatchAction. Note that you allow a Struts
mapping parameter to override. This is a bit of sophistication you can
dump. I like it though.
On 4/7/06, Quinn Stone [EMAIL PROTECTED] wrote:
OK. I contemplated creating a base class, but didn't like the idea of
having to
create a basically empty Action class for Actions that use ActionForward
to
forward to a jsp for display without calling an Action. And, frankly,
thought it
would be more complex to go learn the order of method calls of
LookupDispatchAction to figure out what to override and when and how I
return
without bypassing some necessary processing. Sometimes I like the easy way
out
(as long as it's not crappy).
Q
-Original Message-
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Sent: Friday, April 07, 2006 8:24 PM
To: Struts Users Mailing List
Subject: Re: Servlet Filter?
Hi Quinn,
Quinn Stone wrote:
1. Does the Servlet filter seem a good solution?
Yes, but not quite as described, and ironically its because of the
answer to #2 :)
2. If I throw an EnrollmentDingBat exception from said Servlet Filter,
will a
handler defined in global-exceptions catch it? My suspicion is that
the
filter
might executing too early, before struts mechanics cut in.
No, it won't. As you suspect, the filter fires before Struts gets
involved.
However, what you *can* do, is simply forward somewhere from the filter.
It could be straight to a JSP, or it could be to an Action mapping,
whatever is appropriate.
I think using a filter is generally a decent idea, but one thing to
consider: what are you going to map it to? It sounds like you have many
possible URLs that you would need to check, hence the reason for wanting
some central checkpoint in the first place. The problem is, the
filter is of course going to fire for *any* mapped request
indiscriminately. While filters, unless poorly written, tend to not add
a horrible amount of overhead, you may not want to add any at all where
it isn't necessary. So, onto #3...
No, three questions:
3. Any better ideas?
I would probably do it instead with a custom Action base class that your
other Actions extend from. Then, only extend from it those Actions
where this check is needed. I mean, if you determine its needed for all
of them, or nearly all of them, then I'd probably go with the filter.
If you can narrow it down to just a handful though, the custom base
Action might be a better answer.
Q
HTH,
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
-
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]
--
You can lead a horse to water but you cannot make it float on its back.
~Dakota Jack~
Re: Servlet Filter?
Hi Quinn, Quinn Stone wrote: 1. Does the Servlet filter seem a good solution? Yes, but not quite as described, and ironically its because of the answer to #2 :) 2. If I throw an EnrollmentDingBat exception from said Servlet Filter, will a handler defined in global-exceptions catch it? My suspicion is that the filter might executing too early, before struts mechanics cut in. No, it won't. As you suspect, the filter fires before Struts gets involved. However, what you *can* do, is simply forward somewhere from the filter. It could be straight to a JSP, or it could be to an Action mapping, whatever is appropriate. I think using a filter is generally a decent idea, but one thing to consider: what are you going to map it to? It sounds like you have many possible URLs that you would need to check, hence the reason for wanting some central checkpoint in the first place. The problem is, the filter is of course going to fire for *any* mapped request indiscriminately. While filters, unless poorly written, tend to not add a horrible amount of overhead, you may not want to add any at all where it isn't necessary. So, onto #3... No, three questions: 3. Any better ideas? I would probably do it instead with a custom Action base class that your other Actions extend from. Then, only extend from it those Actions where this check is needed. I mean, if you determine its needed for all of them, or nearly all of them, then I'd probably go with the filter. If you can narrow it down to just a handful though, the custom base Action might be a better answer. Q HTH, Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Servlet Filter?
OK. I contemplated creating a base class, but didn't like the idea of having to create a basically empty Action class for Actions that use ActionForward to forward to a jsp for display without calling an Action. And, frankly, thought it would be more complex to go learn the order of method calls of LookupDispatchAction to figure out what to override and when and how I return without bypassing some necessary processing. Sometimes I like the easy way out (as long as it's not crappy). Q -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Friday, April 07, 2006 8:24 PM To: Struts Users Mailing List Subject: Re: Servlet Filter? Hi Quinn, Quinn Stone wrote: 1. Does the Servlet filter seem a good solution? Yes, but not quite as described, and ironically its because of the answer to #2 :) 2. If I throw an EnrollmentDingBat exception from said Servlet Filter, will a handler defined in global-exceptions catch it? My suspicion is that the filter might executing too early, before struts mechanics cut in. No, it won't. As you suspect, the filter fires before Struts gets involved. However, what you *can* do, is simply forward somewhere from the filter. It could be straight to a JSP, or it could be to an Action mapping, whatever is appropriate. I think using a filter is generally a decent idea, but one thing to consider: what are you going to map it to? It sounds like you have many possible URLs that you would need to check, hence the reason for wanting some central checkpoint in the first place. The problem is, the filter is of course going to fire for *any* mapped request indiscriminately. While filters, unless poorly written, tend to not add a horrible amount of overhead, you may not want to add any at all where it isn't necessary. So, onto #3... No, three questions: 3. Any better ideas? I would probably do it instead with a custom Action base class that your other Actions extend from. Then, only extend from it those Actions where this check is needed. I mean, if you determine its needed for all of them, or nearly all of them, then I'd probably go with the filter. If you can narrow it down to just a handful though, the custom base Action might be a better answer. Q HTH, Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - 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: Servlet Filter?
Yeah, that's all reasonable. Well, back to the filter then :) One thing you may want to do is have a look at the filters in Java Web Parts (http://javawebparts.sourceforge.net). We have them all implemented with some added flexibility in mapping to paths. At least that way you can only fire it when really appropriate... well... in reality, it's *still* firing, but hopefully doing a lot less work than it might otherwise need to. You can rip off the code for that extra ability (it's in the FilterHelpers class). Then again, I may be micro-optimizing here... maybe for what your filter is doing it won't be that heavyweight anyway. Sounds like that may be the case. So, even if you mapped it to *.do for instance, it might not really be a problem. Frank Quinn Stone wrote: OK. I contemplated creating a base class, but didn't like the idea of having to create a basically empty Action class for Actions that use ActionForward to forward to a jsp for display without calling an Action. And, frankly, thought it would be more complex to go learn the order of method calls of LookupDispatchAction to figure out what to override and when and how I return without bypassing some necessary processing. Sometimes I like the easy way out (as long as it's not crappy). Q -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Friday, April 07, 2006 8:24 PM To: Struts Users Mailing List Subject: Re: Servlet Filter? Hi Quinn, Quinn Stone wrote: 1. Does the Servlet filter seem a good solution? Yes, but not quite as described, and ironically its because of the answer to #2 :) 2. If I throw an EnrollmentDingBat exception from said Servlet Filter, will a handler defined in global-exceptions catch it? My suspicion is that the filter might executing too early, before struts mechanics cut in. No, it won't. As you suspect, the filter fires before Struts gets involved. However, what you *can* do, is simply forward somewhere from the filter. It could be straight to a JSP, or it could be to an Action mapping, whatever is appropriate. I think using a filter is generally a decent idea, but one thing to consider: what are you going to map it to? It sounds like you have many possible URLs that you would need to check, hence the reason for wanting some central checkpoint in the first place. The problem is, the filter is of course going to fire for *any* mapped request indiscriminately. While filters, unless poorly written, tend to not add a horrible amount of overhead, you may not want to add any at all where it isn't necessary. So, onto #3... No, three questions: 3. Any better ideas? I would probably do it instead with a custom Action base class that your other Actions extend from. Then, only extend from it those Actions where this check is needed. I mean, if you determine its needed for all of them, or nearly all of them, then I'd probably go with the filter. If you can narrow it down to just a handful though, the custom base Action might be a better answer. Q HTH, Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Servlet filter
We used a filter for the same purpose...works like a charm I presume the configuration is pretty simple.configure it in the web.xml using the filter tags and make sure the filter class is present in your web app -Original Message- From: Shilpa Vaidya [mailto:[EMAIL PROTECTED] Sent: Thursday, June 03, 2004 3:41 PM To: 'Struts Users Mailing List' Subject: Servlet filter hey all, Preventing users from accesing action. I am writing a web app to manage administrators and profiles. Administrators may access to the web app based on the profiles they have. The profiles, determine which pages the administrator might access. The profiles, and authorizations, might change online during work, so I need to check authorization to access a page (Action) on each access.If I understand correct, then, the actionServlet, first process the form bean, and then the action.. But, if the user is not authorized to access a specific page (Action), I need to forward him to an UnAuthorized error page, before thr formAction bean is filled. I would like to use a servlet filter. This filter checks the users rights and instanciates a HttpServletRequest-Wrapper.But am not sure how - .Can anyone help.Till then me trying to study the ServletFilter examples here n there. Shilpa -- This e-mail message may contain confidential, proprietary or legally privileged information. It should not be used by anyone who is not the original intended recipient. If you have erroneously received this message, please delete it immediately and notify the sender. The recipient acknowledges that ICICI Bank or its subsidiaries and associated companies, (collectively ICICI Group), are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of ICICI Group.Before opening any attachments please check them for viruses and defects. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet filter
Shilpa, We are doing just that. A filter comes into effect before the control goes to the servlet. So if you can stop the user at the filter level you are actually saving some processing. We are checking for the presence of session in the filter. Brati Sankar Ghosh Tata Consultancy Services Mailto: [EMAIL PROTECTED] Website: http://www.tcs.com Shilpa Vaidya [EMAIL PROTECTED] 06/03/2004 03:41 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To 'Struts Users Mailing List' [EMAIL PROTECTED] cc Subject Servlet filter hey all, Preventing users from accesing action. I am writing a web app to manage administrators and profiles. Administrators may access to the web app based on the profiles they have. The profiles, determine which pages the administrator might access. The profiles, and authorizations, might change online during work, so I need to check authorization to access a page (Action) on each access.If I understand correct, then, the actionServlet, first process the form bean, and then the action.. But, if the user is not authorized to access a specific page (Action), I need to forward him to an UnAuthorized error page, before thr formAction bean is filled. I would like to use a servlet filter. This filter checks the users rights and instanciates a HttpServletRequest-Wrapper.But am not sure how - .Can anyone help.Till then me trying to study the ServletFilter examples here n there. Shilpa -- This e-mail message may contain confidential, proprietary or legally privileged information. It should not be used by anyone who is not the original intended recipient. If you have erroneously received this message, please delete it immediately and notify the sender. The recipient acknowledges that ICICI Bank or its subsidiaries and associated companies, (collectively ICICI Group), are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of ICICI Group.Before opening any attachments please check them for viruses and defects. ForwardSourceID:NTA91E DISCLAIMER: The information contained in this message is intended only and solely for the addressed individual or entity indicated in this message and for the exclusive use of the said addressed individual or entity indicated in this message (or responsible for delivery of the message to such person) and may contain legally privileged and confidential information belonging to Tata Consultancy Services. It must not be printed, read, copied, disclosed, forwarded, distributed or used (in whatsoever manner) by any person other than the addressee. Unauthorized use, disclosure or copying is strictly prohibited and may constitute unlawful act and can possibly attract legal action, civil and/or criminal. The contents of this message need not necessarily reflect or endorse the views of Tata Consultancy Services on any subject matter. Any action taken or omitted to be taken based on this message is entirely at your risk and neither the originator of this message nor Tata Consultancy Services takes any responsibility or liability towards the same. Opinions, conclusions and any other information contained in this message that do not relate to the official business of Tata Consultancy Services shall be understood as neither given nor endorsed by Tata Consultancy Services or any affiliate of Tata Consultancy Services. If you have received this message in error, you should destroy this message and may please notify the sender by e-mail. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Servlet filter
Thanks brati, r u writing a servlet filter . how did u approach it. can u show me a starting point. shilpa -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, June 03, 2004 5:59 PM To: Struts Users Mailing List Cc: 'Struts Users Mailing List' Subject: Re: Servlet filter Shilpa, We are doing just that. A filter comes into effect before the control goes to the servlet. So if you can stop the user at the filter level you are actually saving some processing. We are checking for the presence of session in the filter. Brati Sankar Ghosh Tata Consultancy Services Mailto: [EMAIL PROTECTED] Website: http://www.tcs.com Shilpa Vaidya [EMAIL PROTECTED] 06/03/2004 03:41 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To 'Struts Users Mailing List' [EMAIL PROTECTED] cc Subject Servlet filter hey all, Preventing users from accesing action. I am writing a web app to manage administrators and profiles. Administrators may access to the web app based on the profiles they have. The profiles, determine which pages the administrator might access. The profiles, and authorizations, might change online during work, so I need to check authorization to access a page (Action) on each access.If I understand correct, then, the actionServlet, first process the form bean, and then the action.. But, if the user is not authorized to access a specific page (Action), I need to forward him to an UnAuthorized error page, before thr formAction bean is filled. I would like to use a servlet filter. This filter checks the users rights and instanciates a HttpServletRequest-Wrapper.But am not sure how - .Can anyone help.Till then me trying to study the ServletFilter examples here n there. Shilpa -- This e-mail message may contain confidential, proprietary or legally privileged information. It should not be used by anyone who is not the original intended recipient. If you have erroneously received this message, please delete it immediately and notify the sender. The recipient acknowledges that ICICI Bank or its subsidiaries and associated companies, (collectively ICICI Group), are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of ICICI Group.Before opening any attachments please check them for viruses and defects. ForwardSourceID:NTA91E -- This e-mail message may contain confidential, proprietary or legally privileged information. It should not be used by anyone who is not the original intended recipient. If you have erroneously received this message, please delete it immediately and notify the sender. The recipient acknowledges that ICICI Bank or its subsidiaries and associated companies, (collectively ICICI Group), are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of ICICI Group.Before opening any attachments please check them for viruses and defects.
RE: Servlet filter
A filter will only work with servlet
containers implementing servlet specifications 2.3.
We have a general filter which is extended
by other filters doing various actions like xml processing,session validations
and security logic.
Here is the generic filter code.
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import java.io.IOException;
import javax.servlet.ServletException;
import pims.util.Logger;
public class PimsGenericFilter implements
Filter
{
private FilterConfig filterConfig;
public void init(FilterConfig
config)
{
filterConfig = config;
}
public FilterConfig getFilterConfig()
{
return filterConfig;
}
public void setFilterConfig(FilterConfig
filterconfig)
{
filterConfig = filterconfig;
}
public void doFilter(final ServletRequest
request,final ServletResponse response, FilterChain chain)
throws IOException,
ServletException
{
chain.doFilter(request,response);
}
public void destroy()
{
filterConfig = null;
}
}
Brati Sankar Ghosh
Tata Consultancy Services
Mailto: [EMAIL PROTECTED]
Website: http://www.tcs.com
Shilpa Vaidya
[EMAIL PROTECTED]
06/03/2004 06:06 PM
Please respond to
Struts Users Mailing List [EMAIL PROTECTED]
To
'Struts Users Mailing
List' [EMAIL PROTECTED]
cc
Subject
RE: Servlet filter
Thanks brati,
r u writing a servlet filter .
how did u approach it.
can u show me a starting point.
shilpa
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 03, 2004 5:59 PM
To: Struts Users Mailing List
Cc: 'Struts Users Mailing List'
Subject: Re: Servlet filter
Shilpa,
We are doing just that. A filter comes into effect before the control
goes
to the servlet. So if you can stop the user at the filter level you are
actually saving some processing. We are checking for the presence of session
in the filter.
Brati Sankar Ghosh
Tata Consultancy Services
Mailto: [EMAIL PROTECTED]
Website: http://www.tcs.com
Shilpa Vaidya [EMAIL PROTECTED]
06/03/2004 03:41 PM
Please respond to
Struts Users Mailing
List [EMAIL PROTECTED]
To 'Struts Users Mailing List' [EMAIL PROTECTED]
cc
Subject Servlet filter
hey all,
Preventing users from accesing action. I am writing a web app to
manage
administrators and profiles.
Administrators may access to the web app based on the profiles they
have.
The profiles, determine which pages the administrator might access.
The
profiles, and authorizations, might change online during work, so
I need
to
check authorization to access a page (Action) on each access.If
I
understand
correct, then, the actionServlet, first process the form bean, and
then
the
action..
But, if the user is not authorized to access a specific page (Action),
I
need to forward him to an UnAuthorized error page, before thr formAction
bean is filled.
I would like to use a servlet filter. This filter checks the users
rights
and instanciates a HttpServletRequest-Wrapper.But am not sure how
- .Can
anyone help.Till then me trying to study the ServletFilter examples
here n
there.
Shilpa
--
This e-mail message may contain confidential, proprietary
or legally
privileged information. It
should not be used by anyone who is not the original intended recipient.
If you have erroneously
received this message, please delete it immediately and notify the
sender.
The recipient
acknowledges that ICICI Bank or its subsidiaries and associated
companies,
(collectively ICICI
Group), are unable to exercise control or ensure or guarantee
the
integrity of/over the contents of the information contained in e-mail
transmissions and further acknowledges that any views
expressed in this message are those of the individual sender and
no
binding nature of the message shall be implied or assumed unless the sender
does so expressly with due authority of ICICI Group.Before opening any
attachments please check them for viruses and defects.
ForwardSourceID:NTA91E
--
This e-mail message may contain confidential, proprietary or legally
privileged information. It
should not be used by anyone who is not the original intended recipient.
If you have erroneously
received this message, please delete it immediately and notify the sender.
The recipient
acknowledges that ICICI Bank or its subsidiaries and associated companies,
(collectively ICICI
Group), are unable to exercise control or ensure or guarantee the
integrity of/over the contents of the information contained in e-mail transmissions
and further acknowledges that any views
expressed in this message are those of the individual sender and no binding
nature of the message shall be implied or assumed unless the sender does
so expressly with due authority of ICICI Group.Before opening any attachments
please check them for viruses and defects
