Would the following be an acceptable solution?

We change the
Constants.message(key,args,verbosityLevel) method
behavior so that if getString(key,args) throws
a missing resource exception that it logs using the
key itself as the log message. Note that this would
also require changing the getString() method to throw
the MissingResourceException instead of the Error
object that it currently throws.  

Looking at this, I am not sure why an Error is being
thrown here (in Constants.getString()).  If Jasper is
operating in JspServlet mode inside some other
container (i.e. WebLogic, JRun, whatever) then should
it necessarily throw an Error?  According to the spec,
Errors are reserved for conditions that are so serious
that they should normally not be caught by the
application.  I.E., they should bring the JVM down. 
The fact that Jasper (a servlet) is unable to find a
String in it's resource file sounds more like enough
error to throw a RuntimeException or even a
ServletException, but not an Error.  That would allow
the containing ServletEngine to handl the error to
Jasper without bringing down other servlets - without
having to catch 'Error'.

I think the right way to handle this is to change the
getString() to just throw the
MissingResourceException.  This requires no change to
the interfaces.

Then in org.apache.jasper.Constants change message()
to:

    public static final void message(
                                   String key, 
                                   Object[] args, 
                                   int
verbosityLevel){
        if (jasperLog == null)
          jasperLog = Log.getLog("JASPER_LOG", null);

        if (jasperLog != null){
          try{
              jasperLog.log(
                        getString(key,args),
                        verbosityLevel);
          }catch(MissingResourceException e){
              jasperLog.log(
                        key,verbosityLevel);
          }
    }


This should work 99% of the time the way you describe
with much less pain in implementation.

Feedback welcome.  If no one sends a -1 on this, I can
put this patch in fairly rapidly in tc3.3.

Mel


--- "Julien, Timothy" <[EMAIL PROTECTED]> wrote:
> I believe there is a bug in Jasper when resources
> (such as web.xml's dtd)
> can't be loaded.
> The basic problem is that keys are getting passed
> into Constants.getString()
> which aren't keys in the message resources file. 
> This happens because of
> some exception handling, which basically constructs
> an invalid key - namely,
> a *value* in the message resources file.
> 
> JspUtil.parseXMLDocJaxp(String, InputStream)
> {
>       try
>       {
>               ...
>       }
>       catch(IOException io)
>       {
>             throw new
>
JasperException(Constants.getString("jsp.error.parse.xml",
> new Object[] {
>                 uri, io.toString()
>             }));
>       }
> }
> and then lower down the call stack:
> 
> public TldLocationsCache(ServletContext ctxt)
> {
>      mappings = new Hashtable();
>      try
>      {
>          processWebDotXml(ctxt);
>          processJars(ctxt);
>      }
>      catch(JasperException ex)
>      {
>          Constants.message(ex.getMessage(), 1);
>      }
> }
> 
> The trouble is that ex.getMessage() here contains a
> *value* from the message
> resource file, (as looked up in the first caught
> Exception) not a *key*.
> 
> One fix would be in JspUtil.parseXMLDocJaxp(String,
> InputStream) to pass
> only the key (jsp.error.parse.xml) as the
> JasperException's message - and
> delay the lookup.  But then you lose some
> information (i.e., io.String()).
> 
> Maybe a better solution is to set a flag on
> JasperException which marks its
> message as being either key or value - so that
> Constants.getString can be
> called only when necessary.  I realize this would
> effect alot of code.
> 
> anyway, I'm happy to help in any way with the fix.
> Tim Julien
> HP Middleware
> 
> 


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Reply via email to