Re: strange behaviours of tiles

[Thomas Corte <Th...@knipp.de>]

Hi,

Laurie Harper wrote:

> Tiles can sometimes 'swallow' errors rendering a JSP without logging 
> them, returning empty pages. Double check your logs first to see if the 
> problem *is* being logged, but if not a couple of approaches you can try 
> to track down the problem:
> 
>  - try loading your JSPs directly if you can (i.e. without going through 
> Tiles). That may not be trivial if your JSPs need data prepopulated by 
> Struts actions though.
> 
>  - try wrapping the content of each JSP with a try / catch (using the 
> JSTL tags or runtime scriptlets) and log any exceptions; this can help 
> you see them before they get swallowed by the Struts/Tiles request 
> processing machinery
> 
>  - try stepping through your JSPs in a debugger. It *really* helps if 
> you have an IDE that supports this well, since just stepping through the 
> Java code generated from the JSP isn't very helpful

I know that this thread is quite old, but I still wonder whether there 
is a better solution for this. It's quite tedious to find errors in JSPs 
when the Tiles framework swallows exceptions completely. Is there a 
patch available that keeps Tiles from doing this?

Regards,

-- 
Thomas

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

Re: strange behaviours of tiles

[Thomas Corte <Th...@knipp.de>]

Hi,

Thomas Corte schrieb:

> I know that this thread is quite old, but I still wonder whether there 
> is a better solution for this. It's quite tedious to find errors in JSPs 
> when the Tiles framework swallows exceptions completely. Is there a 
> patch available that keeps Tiles from doing this?

Nevermind... I found out that a line like

   log4j.logger.org.apache.struts.taglib.tiles=ERROR, A1

in the log4j.properties of the web app at least ensures that any 
exception is properly written to the Tomcat log, which is enough to 
carry one from there.

-- 
Thomas

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