Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: 
 <50462.170.201.180.136.1186067689.squirrel@webmail.chiron.lunarpages.com>
In-Reply-To: 
     <46BB113A91AE694EB5BE73A9C030EC9283CC39@lsbexc05.london-scottish.com>
References: 
    <46BB113A91AE694EB5BE73A9C030EC9283CC39@lsbexc05.london-scottish.com>
Date: Thu, 2 Aug 2007 11:14:49 -0400 (EDT)
Subject: RE: DownloadAction and a normal Forward
From: "Frank W. Zammetti" <fzlists@omnytex.com>
To: "Struts Users Mailing List" <user@struts.apache.org>
Cc: "Struts Users Mailing List" <user@struts.apache.org>
User-Agent: SquirrelMail/1.4.9a
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

The thing is, I'm not entirely sure there's another viable option.  I
could certainly see extending DownloadAction in some way so that there is
kind of a verify() method called first that detects the problem that your
checking for (the if(problem) statement)... if a problem is detected,
i.e., file doesn't exist or something, then do the forward.  That should
avoid the NPE (I think), but then your probably overwriting the page on
the browser, so maybe that's worse.  In any case, that's no quick fix
since there's some R&D involved.

The only thing I can think of is if you can detect you have a problem
before the download call... could you maybe do an AJAX call before the
download call to see if the file is available and downloadable?  If so,
then make the actual download request.  Or possibly make the download link
point to a regular Action that does that check, then forwards to the
mapping leading to the DownloadAction?  That way the check and the
download are in the same request... I'm not sure that would work frankly
though and I think you'd have the same problem as I mentioned earlier.

Yeah, you may have to live with the NPE... I guess if it's an exceptional
situation and isn't going to happen often it may not be a big deal.  If
it's frequent though, I think I'd do some more creative thinking to avoid
it somehow.

Frank

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Author of "Practical Ajax Projects With Java Technology"
 (2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
 (2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
 Supplying the wheel, so you don't have to reinvent it!

On Thu, August 2, 2007 4:17 am, Gundersen, Richard wrote:
> Hi Frank, Paul
>
> Thanks again for the tips. The thing is, having a NPE isn't actually a
> problem for me. I am quite (well, not entirely) happy for the code to
> throw it since by that time, my RequestDispatcher.forward method has
> already got my request to the browser by then, and the user is viewing
> the JSP. The fact that the DownloadAction still thinks it needs to do
> something with a dummy StreamInfo isn't such a big deal to be honest. It
> can fail for all I care since it doesn't stop the system from working (I
> know, it's not the right attitude :-)
>
> But, right now I am more concerned about whether using
> RequestDispatcher.forward is a safe (and/or best) way to redirect the
> request out of the DownloadAction and back to a real JSP.
>
> Appreciate your thoughts.
>
> Richard Gundersen
> Java Developer
>
> Email: richard.gundersen@london-scottish.com
> Phone: 01618302398
> Fax: 01618342536
> London Scottish Bank plc
> 24 Mount Street
> Manchester
> M2 3LS
>
> -----Original Message-----
> From: Frank W. Zammetti [mailto:fzlists@omnytex.com]
> Sent: Thursday, August 02, 2007 3:16 AM
> To: Struts Users Mailing List
> Subject: Re: DownloadAction and a normal Forward
>
> Hehe, your going after the *right* answer Paul :)
>
> It's clear the caller of getStreamInfo() doesn't like getting null back,
>
> that was the case originally... now, the NPE must be getting thrown from
>
> elsewhere after Richard returned the "dummied" StreamInfo object (I
> would have been surprised if constructing one with two null arguments
> *didn't* move the NPE elsewhere, but I was hoping!).
>
> Frank
>
> Paul Benedict wrote:
>> Who is throwing the NPE? I can't tell by your code what's causing it.
>>
>> On 8/1/07, Frank W. Zammetti <fzlists@omnytex.com> wrote:
>>> You know, I just reread what your trying to do... have you tried
> using a
>>> global exception handler?  I'm not sure you'll be able to catch the
>>> exception with one, but if you give it a try and you can, there you
> go,
>>> you can forward as desired from there.
>>>
>>> --
>>> Frank W. Zammetti
>>> Founder and Chief Software Architect
>>> Omnytex Technologies
>>> http://www.omnytex.com
>>> AIM/Yahoo: fzammetti
>>> MSN: fzammetti@hotmail.com
>>> Author of "Practical Ajax Projects With Java Technology"
>>> (2006, Apress, ISBN 1-59059-695-1)
>>> and "JavaScript, DOM Scripting and Ajax Projects"
>>> (2007, Apress, ISBN 1-59059-816-4)
>>> Java Web Parts - http://javawebparts.sourceforge.net
>>> Supplying the wheel, so you don't have to reinvent it!
>>>
>>> On Wed, August 1, 2007 10:38 am, Gundersen, Richard wrote:
>>>> Hi
>>>>
>>>> Thanks for the reply. Tried it and it still gives me a NullPointer.
>>>> Maybe that's not such a problem though - since the browser still
>>>> redirects to the JSP I want.
>>>>
>>>> However, I was wondering if it's possible to use a
> ResourceStreamInfo to
>>>> redirect to an ActionForward (which ultimately leads to a JSP).
> Would
>>>> this be preferable to using RequestDispatcher.forward(request,
>>>> response)?
>>>>
>>>> Richard Gundersen
>>>> Java Developer
>>>>
>>>> Email: richard.gundersen@london-scottish.com
>>>> Phone: 01618302398
>>>> Fax: 01618342536
>>>> London Scottish Bank plc
>>>> 24 Mount Street
>>>> Manchester
>>>> M2 3LS
>>>>
>>>> -----Original Message-----
>>>> From: Frank W. Zammetti [mailto:fzlists@omnytex.com]
>>>> Sent: Wednesday, August 01, 2007 2:47 PM
>>>> To: Struts Users Mailing List
>>>> Cc: user@struts.apache.org
>>>> Subject: Re: DownloadAction and a normal Forward
>>>>
>>>> It's not the *right* answer, and I'm not sure it won't cause some
> other
>>>> exception anyway (in fact, I'd bet it would), but what if instead of
>>>> returning null you instead do:
>>>>
>>>> return new ByteArrayStreamInfo(null, null);
>>>>
>>>> ?
>>>>
>>>> Frank
>>>>
>>>> --
>>>> Frank W. Zammetti
>>>> Founder and Chief Software Architect
>>>> Omnytex Technologies
>>>> http://www.omnytex.com
>>>> AIM/Yahoo: fzammetti
>>>> MSN: fzammetti@hotmail.com
>>>> Author of "Practical Ajax Projects With Java Technology"
>>>>  (2006, Apress, ISBN 1-59059-695-1)
>>>> and "JavaScript, DOM Scripting and Ajax Projects"
>>>>  (2007, Apress, ISBN 1-59059-816-4)
>>>> Java Web Parts - http://javawebparts.sourceforge.net
>>>>  Supplying the wheel, so you don't have to reinvent it!
>>>>
>>>> On Wed, August 1, 2007 9:24 am, Gundersen, Richard wrote:
>>>>> Hi
>>>>>
>>>>> I'm using a DownloadAction to generate a PDF and return it the the
>>>>> browser. If there is a problem generating the PDF however, I want
> to
>>>>> redirect the user to a specific JSP.
>>>>>
>>>>> What's the best way of doing this? At the moment I am using
>>>>>
>>>>>
>>>>> protected StreamInfo getStreamInfo(ActionMapping mapping,
> ActionForm
>>>>> form,
>>>>>                                        HttpServletRequest request,
>>>>> HttpServletResponse response) {
>>>>> ...
>>>>> ...
>>>>> ...
>>>>>      if(problem)
>>>>>
>>>>>
>>>>
> servlet.getServletContext().getRequestDispatcher("/admin.do?doAction=alr
>>>>> eadyPrinted").forward(request, response);
>>>>>              return null;
>>>>>      }
>>>>>      else {
>>>>>              return new ByteArrayStreamInfo(contentType,
> myPdfBytes);
>>>>>      }
>>>>> }
>>>>>
>>>>> This works, but I always get a NullPointer, because I'm returning
> null
>>>>> to satisfy the method signature. The exception doesn't cause a
> problem
>>>>> for the user though, because the forward has already happened by
> then
>>>>> (and the user is happily viewing the JSP)
>>>>>
>>>>> Is there a better way to do this though - perhaps with
>>>>> ResourceStreamInfo instead?
>>>>>
>>>>> Regards
>>>>>
>>>>> Richard Gundersen
>>>>> Java Developer
>>>>>
>>>>> Email: richard.gundersen@london-scottish.com
>>>>> Phone: 01618302398
>>>>> Fax: 01618342536
>>>>> London Scottish Bank plc
>>>>> 24 Mount Street
>>>>> Manchester
>>>>> M2 3LS
>>>>>
>>>>>
>>>>> *** Disclaimer ***
>>>>>
>>>>> This electronic communication is confidential and for the exclusive
>>>> use of
>>>>> the addressee. It may contain private and confidential information.
>>>> The
>>>>> information, attachments and opinions contained in this E-mail are
>>>> those
>>>>> of its author only and do not necessarily represent those of London
>>>>> Scottish Bank PLC or any other members of the London Scottish
> Group.
>>>>>
>>>>> If you are not the intended addressee, you are prohibited from any
>>>>> disclosure, distribution or further copying or use of this
>>>> communication
>>>>> or the information in it or taking any action in reliance on it. If
>>>> you
>>>>> have received this communication in error please notify the
>>>> Information
>>>>> Security Manager at ISM@London-Scottish.com as soon as possible and
>>>> delete
>>>>> the message from all places in your computer where it is stored.
>>>>>
>>>>> We utilise virus scanning software but we cannot guarantee the
>>>> security of
>>>>> electronic communications and you are advised to check any
> attachments
>>>> for
>>>>> viruses. We do not accept liability for any loss resulting from any
>>>>> corruption or alteration of data or importation of any virus as a
>>>> result
>>>>> of receiving this electronic communication.
>>>>>
>>>>> Replies to this E-mail may be monitored for operational or business
>>>>> reasons. London Scottish Bank PLC is regulated by the Financial
>>>> Services
>>>>> Authority.
>>>>>
> ______________________________________________________________________
>>>>> This email has been scanned by the MessageLabs Email Security
> System.
>>>>>
>>>>>
> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>
>>>>>
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>>
> ______________________________________________________________________
>>>> This email has been scanned by the MessageLabs Email Security
> System.
>>>> For more information please visit http://www.messagelabs.com/email
>>>>
> ______________________________________________________________________
>>>>
>>>> *** Disclaimer ***
>>>>
>>>> This electronic communication is confidential and for the exclusive
> use
>>> of
>>>> the addressee. It may contain private and confidential information.
> The
>>>> information, attachments and opinions contained in this E-mail are
> those
>>>> of its author only and do not necessarily represent those of London
>>>> Scottish Bank PLC or any other members of the London Scottish Group.
>>>>
>>>> If you are not the intended addressee, you are prohibited from any
>>>> disclosure, distribution or further copying or use of this
> communication
>>>> or the information in it or taking any action in reliance on it. If
> you
>>>> have received this communication in error please notify the
> Information
>>>> Security Manager at ISM@London-Scottish.com as soon as possible and
>>> delete
>>>> the message from all places in your computer where it is stored.
>>>>
>>>> We utilise virus scanning software but we cannot guarantee the
> security
>>> of
>>>> electronic communications and you are advised to check any
> attachments
>>> for
>>>> viruses. We do not accept liability for any loss resulting from any
>>>> corruption or alteration of data or importation of any virus as a
> result
>>>> of receiving this electronic communication.
>>>>
>>>> Replies to this E-mail may be monitored for operational or business
>>>> reasons. London Scottish Bank PLC is regulated by the Financial
> Services
>>>> Authority.
>>>>
> ______________________________________________________________________
>>>> This email has been scanned by the MessageLabs Email Security
> System.
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>
>>
>>
> ------------------------------------------------------------------------
>>
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.5.476 / Virus Database: 269.11.0/929 - Release Date:
> 7/31/2007 5:26 PM
>
> --
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM/Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
> Author of "Practical Ajax Projects With Java Technology"
>   (2006, Apress, ISBN 1-59059-695-1)
> and "JavaScript, DOM Scripting and Ajax Projects"
>   (2007, Apress, ISBN 1-59059-816-4)
> Java Web Parts - http://javawebparts.sourceforge.net
>   Supplying the wheel, so you don't have to reinvent it!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
> *** Disclaimer ***
>
> This electronic communication is confidential and for the exclusive use of
> the addressee. It may contain private and confidential information. The
> information, attachments and opinions contained in this E-mail are those
> of its author only and do not necessarily represent those of London
> Scottish Bank PLC or any other members of the London Scottish Group.
>
> If you are not the intended addressee, you are prohibited from any
> disclosure, distribution or further copying or use of this communication
> or the information in it or taking any action in reliance on it. If you
> have received this communication in error please notify the Information
> Security Manager at ISM@London-Scottish.com as soon as possible and delete
> the message from all places in your computer where it is stored.
>
> We utilise virus scanning software but we cannot guarantee the security of
> electronic communications and you are advised to check any attachments for
> viruses. We do not accept liability for any loss resulting from any
> corruption or alteration of data or importation of any virus as a result
> of receiving this electronic communication.
>
> Replies to this E-mail may be monitored for operational or business
> reasons. London Scottish Bank PLC is regulated by the Financial Services
> Authority.
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org