well, Danny, here I am. back to square one!

what I have achieved so far is that I've made changes in the web.xml and in
my action so that whenever Action class throws an exception web.xml settings
redirect user to an error page. this cool. but the real reason I asked this
question is still there.

how do I handle a exception that is thrown out of scriptlet from a JSP page
that is one tile in the layout? did I miss something along the way?

ATTA


----- Original Message -----
From: "Trieu, Danny" <[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Monday, November 18, 2002 2:37 PM
Subject: RE: Howto handle this behavior in Struts+Tiles


> No problem... I've learn from others the same way...
>
> --danny
>
> -----Original Message-----
> From: atta ur-rehman [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 18, 2002 2:37 PM
> To: Struts Users Mailing List
> Subject: Re: Howto handle this behavior in Struts+Tiles
>
>
> Thankyou very much, Danny, for your help and patience!
>
> Regards,
>
> ATTA
>
> ----- Original Message -----
> From: "Trieu, Danny" <[EMAIL PROTECTED]>
> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
> Sent: Monday, November 18, 2002 2:30 PM
> Subject: RE: Howto handle this behavior in Struts+Tiles
>
>
> > You got it ... :)
> >
> > --danny
> >
> > -----Original Message-----
> > From: atta ur-rehman [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, November 18, 2002 2:30 PM
> > To: Struts Users Mailing List
> > Subject: Re: Howto handle this behavior in Struts+Tiles
> >
> >
> > we want to have and execute(...) method in a abstract class so that we
> could
> > through exceptions other than the ones perform(...) could throw? is it
> > correct?
> >
> > ATTA
> > ----- Original Message -----
> > From: "Trieu, Danny" <[EMAIL PROTECTED]>
> > To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
> > Sent: Monday, November 18, 2002 2:05 PM
> > Subject: RE: Howto handle this behavior in Struts+Tiles
> >
> >
> > > Okay,
> > >
> > > If you want to handle where to go next in one place then create the
> > abstract
> > > class and have
> > > All the exception handling extends from it.  All the handler action
> > > need
> > to
> > > do is to do profiling
> > > Of the exception, and the abstract class's perform(...) will catch
> > > the exceptions handle it or Just forward it to the associated VIEW.
> > > This works too, if you want all
> > of
> > > your action
> > > Extends from this abstract action, if this is the case you want,
> > > which I would prefer, then You might want your abstract class to
> > > handle the exception, meaning you
> > want
> > > the abstract class
> > > To catch it, profile/log the exception and then forwad to the VIEW.
> > > If
> > this
> > > is the case then
> > > Your exception handler action doesn't have to do anything but throw
> > > the correct exception so the Abstract action class will catch it and
> > > handle it for you.
> > >
> > > If you are looking at this clearly, what we want to do is to create
> > > a template of execution at The base of all your application
> > > exceptions to handle different kind of exceptions.  And since We can
> > > only do this if exception being throw inside of the execution
> > context
> > > of a dispatched
> > > Action class, exceptions that might happen in the VIEW, the original
> > problem
> > > that init our
> > > Conversation, will not get handled.  And so if we want it to be
> > > control in one place then what Should we do? Ahah.. We use the
> > > web.xml exception mapping to do the work. Meaning, we use The
> > > web.xml exception mapping to map all the exceptions that happen
> > outside
> > > of the Action's
> > > Execution context back into an Action mapping with in turns will re
> > > throw
> > it
> > > so that the
> > > Exception is now within the Action's execution context.  There is
> > > many different way to do This, and it all depends on the need of
> > > your application.  This just an
> > idea
> > > or should I say
> > > Concept of how to handle exceptions and errors within a web
> > > application.
> > >
> > > If you implement this with Struts and Tiles, then is no need for
> > > using the conventional JSP's Page directive to handle error.  There
> > > is a few reasons why I don't like this is error handling Logic are
> > > coupling with JSPs every where and it is hard to manage and
> > reuse.
> > > Where as if you
> > > Follow my approach, you can pretty much go to one or two place to
> > > see how all the error being Handled, and if you decided to reuse it
> > > all that is need to do is to
> > modify
> > > your strusts-config.xml,
> > > Web.xml and Wala... You have it up runing.
> > >
> > > Let me know if anything else I can help you with ... :)
> > >
> > > --danny
> > >
> > > Ps. Don't know how advance this technique is, but I do hope that
> > > Chuck Struts book, and Ted/Credic/..'s Struts book mention about
> > > best practice of handling erro and exception within web application.
> > >
> > > -----Original Message-----
> > > From: atta ur-rehman [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, November 18, 2002 1:22 PM
> > > To: Struts Users Mailing List
> > > Subject: Re: Howto handle this behavior in Struts+Tiles
> > >
> > >
> > > Hi Danny,
> > >
> > > I'm confused already!!!
> > >
> > > here is the abstract action class with an abstract execute method:
> > >
> > > --------------------------------------------------------------------
> > > --
> > > ----
> > -
> > > import javax.servlet.http.*;
> > > import org.apache.struts.action.*;
> > >
> > > public abstract class AbstractErrorHandlerAction extends Action {
> > >
> > >   public abstract void execute(ActionMapping mapping, ActionForm form,
> > >       HttpServletRequest request , HttpServletResponse response)
> > > throws Exception; }
> > > --------------------------------------------------------------------
> > > --
> > > ----
> > -
> > >
> > > now should all my actions extend this class? or its only the action
> > handler
> > > action that would extend this class? moreover, I don't see throws
> > > clause
> > in
> > > the perform(...) method of Action class?
> > >
> > > So, am I completely lost? I hope you won't mind my simplistic
> > > questions!!!
> > >
> > > ATTA
> > >
> > > ----- Original Message -----
> > > From: "Trieu, Danny" <[EMAIL PROTECTED]>
> > > To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
> > > Sent: Monday, November 18, 2002 1:05 PM
> > > Subject: RE: Howto handle this behavior in Struts+Tiles
> > >
> > >
> > > > I thinks so ...
> > > >
> > > > Good luck...:)
> > > >
> > > > --danny
> > > >
> > > > -----Original Message-----
> > > > From: atta ur-rehman [mailto:[EMAIL PROTECTED]]
> > > > Sent: Monday, November 18, 2002 1:05 PM
> > > > To: Struts Users Mailing List
> > > > Subject: Re: Howto handle this behavior in Struts+Tiles
> > > >
> > > >
> > > > okay, let me give it a try and I'll get back to you! thanks.
> > > >
> > > > by the way, do you if this feature is available thru servlet 2.2
> > > > specs?
> > > >
> > > > ATTA
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Trieu, Danny" <[EMAIL PROTECTED]>
> > > > To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
> > > > Sent: Monday, November 18, 2002 11:54 AM
> > > > Subject: RE: Howto handle this behavior in Struts+Tiles
> > > >
> > > >
> > > > > You are almost close ... :) Yes my point 3 is that mapping in
> > > > > the web.xml. But Instead of going to the JSP,
> > > > > <location>/ErrorPage.jsp</location>, you
> > > > would
> > > > > want
> > > > > To go to <location>/errors/catchError.do</location>, which map
> > > > > it to a Action that You extended from your abstract action
> > > > > class. This action would do all
> > > > the
> > > > > necessary
> > > > > Stuff with your Exception if there is one or create a new
> > > > > exception and throw it.
> > > > >
> > > > > --danny
> > > > >
> > > > > -----Original Message-----
> > > > > From: atta ur-rehman [mailto:[EMAIL PROTECTED]]
> > > > > Sent: Monday, November 18, 2002 11:42 AM
> > > > > To: Struts Users Mailing List
> > > > > Subject: Re: Howto handle this behavior in Struts+Tiles
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > This definitely is helpful. As I'm not very experiences in
> > > > > Struts, does
> > > > your
> > > > > point 3 refers to
> > > > >
> > > > > <error-page>
> > > > >     <exception-type>java.lang.Exception</exception-type>
> > > > >     <location>/ErrorPage.jsp</location>
> > > > > </error-page>
> > > > >
> > > > > construct in "web.xml" or is it something different? If its the
> > > > > same
> > > > thing,
> > > > > how do I know if my JSP container supports this feature or not.
> > > > > I'm asking this because we are running ServletExec 3.1 that is
> > > > > compliant to Servlet
> > > > 2.2
> > > > > only.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > ATTA
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Trieu, Danny" <[EMAIL PROTECTED]>
> > > > > To: "'Struts Users Mailing List'"
> > > > > <[EMAIL PROTECTED]>
> > > > > Sent: Monday, November 18, 2002 11:15 AM
> > > > > Subject: RE: Howto handle this behavior in Struts+Tiles
> > > > >
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > 1.0 doesn't support declarative exception handling, but it
> > > > > > doesn't prevent you from Doing so...:)  Anyway, what I would
> > > > > > do
> > > > > > is: 1) Implement an abstract Action have and Abstract method
> > > > > > execute(...) throw Exception.  2) Implement the
> > > > > perform(...)
> > > > > > method
> > > > > > That will call you're the abstract excecute(...) method, and
> > > > > > catch all or any specific Exception and return the associated
> > > > > > forward to the specific View(JSP) as needed.
> > > > > > 3) Map all/any error-code and exception mapping in your
> > > > > > web.xml to an
> > > > > Action
> > > > > > that
> > > > > > Extended from your abstract exception.  This exception can be
> > > > > > generic or specific to A particular mapping, it will profile
> > > > > > the exception and re-throw or create
> > > > > a
> > > > > > new exception
> > > > > > And throw it, so that the perform method will catch this
> > > > > > exception and
> > > > > route
> > > > > > it to the
> > > > > > Targeted VIEW.
> > > > > >
> > > > > > Hope this would help,
> > > > > >
> > > > > > --danny
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: atta ur-rehman [mailto:[EMAIL PROTECTED]]
> > > > > > Sent: Monday, November 18, 2002 10:57 AM
> > > > > > To: Struts Users Mailing List
> > > > > > Subject: Re: Howto handle this behavior in Struts+Tiles
> > > > > >
> > > > > >
> > > > > > Thanks, Danny, for the detailed response.
> > > > > > We're running Struts 1.0.x. Does it support ExceptionHandler
> > > > > > paradigm? If
> > > > > so
> > > > > > could you please point towards some starting points.
> > > > > >
> > > > > > Thanks again.
> > > > > >
> > > > > > ATTA
> > > > > >
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Trieu, Danny" <[EMAIL PROTECTED]>
> > > > > > To: "'Struts Users Mailing List'"
> > > > > > <[EMAIL PROTECTED]>
> > > > > > Cc: "Mebed, Waheed" <[EMAIL PROTECTED]>
> > > > > > Sent: Monday, November 18, 2002 10:36 AM
> > > > > > Subject: RE: Howto handle this behavior in Struts+Tiles
> > > > > >
> > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > Usually exception that being thrown by the VIEW(JSP) are
> > > > > > > rendering related exception. This could be tags/Scriptlet
> > > > > > > that access resource, JavaBeans, fails. Meaning the Resource
> > > > > > > is not there. And when these thing happen with composite
> > > > > > > view thing became A bit tricky.  First of all, within the
> > > > > > > container, the layout, of the composite view You don't where
> > > > > > > exception might be thrown.  Second, the page directive
> > > > > for
> > > > > > > 'errorPage'
> > > > > > > Can only be set at the outter most container, the layou, and
> > > > > > > not within
> > > > > > any
> > > > > > > of its
> > > > > > > Contained JSP.  Since, you never know when response has been
> > > > > > > committed to the client Browser.  And if response has
> > > > > > > already committed to the clien browser, any attemp to
> > > > > > > Forward to a different resource is an IllegalStateException.
> > > > > > > A quick solution to your Problem is to only have the page
> > > > > > > directive for your JSP is in the
> > > > outer
> > > > > > most
> > > > > > > container,
> > > > > > > The layout.
> > > > > > >
> > > > > > > My approach to handling the front-end exception in Struts1+
> > > > > > > is having a sub-module for Handling exception with a set of
> > > > > > > custom or generic ExceptionHandler, with action mapping That
> > > > > > > will capture the exception, do exception profiling or
> > > > > > > anything neccessarry, and use Struts declarative exception
> > > > > > > handling to map it to a user friendly
> > > > View
> > > > > > for
> > > > > > > displaying
> > > > > > > Specific error pages.  This has to work with the Web
> > > > > > > application error mapping in the Web.xml deployment
> > > > > > > descriptor, to map different error-code and exception
> > > > > > to
> > > > > > > the right
> > > > > > > Action mapping in your exception sub-module that will handle
> > > > > > > the
> > > > > > exception.
> > > > > > > I think
> > > > > > > This is a much cleaner way to haddle exception since it
> > > > > > > promote encapsulation of exception Handling into one central
> > > > > > > place, the sub-module, that can be manage easily and
> > > > > > > consistent Through out the entire application.  Plus,
> > > > > > > exception handler can be
> > > > > reused
> > > > > > > in different
> > > > > > > Web application with the entire enterprise.
> > > > > > >
> > > > > > > Hope this would help,
> > > > > > >
> > > > > > > -danny
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: atta ur-rehman
> > > > > > > [mailto:[EMAIL PROTECTED]]
> > > > > > > Sent: Monday, November 18, 2002 9:52 AM
> > > > > > > To: struts users mailing list
> > > > > > > Subject: Howto handle this behavior in Struts+Tiles
> > > > > > >
> > > > > > >
> > > > > > > Dear all,
> > > > > > >
> > > > > > > Here is my "layout.jsp" file:
> > > > > > >
> > > > > > > <%@ page errorPage="ErrorPage.jsp" %>
> > > > > > >
> > > > > > >      <tiles:insert attribute="menu"/>
> > > > > > >      <tiles:insert attribute="body"/>
> > > > > > >      <tiles:insert attribute="footer"/>
> > > > > > >
> > > > > > > The "menu" tile is a JSP page that could throw an exception.
> > > > > > > Now whenever
> > > > > > an
> > > > > > > exception is thrown on the "menu" tile I want to goto JSP
> > > > > > > Error Page. What
> > > > > > I
> > > > > > > get instead is this exception:
> > > > > > >
> > > > > > > [Exception in:/main-menu.jsp] reset() failed - data has
> > > > > > > already been sent
> > > > > > to
> > > > > > > client java.lang.IllegalStateException: reset() failed -
> > > > > > > data has already been sent to client.
> > > > > > >
> > > > > > > Could you please help me with this one? What do I need to
> > > > > > > fix this
> > > > > > problem.
> > > > > > > By the way "menu.jsp" contains <%@ page
> > > > > > > errorPage="ErrorPage.jsp" %> directive. And currently if
> > > > > > > there is an exception on "layout.jsp" Error
> > > > > > Page
> > > > > > > does show up with appropriate error message.
> > > > > > >
> > > > > > > TIA,
> > > > > > >
> > > > > > > ATTA
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > To unsubscribe, e-mail:
> > > > > > <mailto:[EMAIL PROTECTED]>
> > > > > > > For additional commands, e-mail:
> > > > > > <mailto:[EMAIL PROTECTED]>
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > > <mailto:[EMAIL PROTECTED]>
> > > > > > For additional commands, e-mail:
> > > > > > <mailto:[EMAIL PROTECTED]>
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > <mailto:[EMAIL PROTECTED]>
> > > > > > For additional commands, e-mail:
> > > > > <mailto:[EMAIL PROTECTED]>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > > <mailto:[EMAIL PROTECTED]>
> > > > > For additional commands, e-mail:
> > > > > <mailto:[EMAIL PROTECTED]>
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <mailto:[EMAIL PROTECTED]>
> > > > > For additional commands, e-mail:
> > > > <mailto:[EMAIL PROTECTED]>
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > > <mailto:[EMAIL PROTECTED]>
> > > > For additional commands, e-mail:
> > > > <mailto:[EMAIL PROTECTED]>
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <mailto:[EMAIL PROTECTED]>
> > > > For additional commands, e-mail:
> > > <mailto:[EMAIL PROTECTED]>
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail:
> > > <mailto:[EMAIL PROTECTED]>
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to