velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jonah benton <jo...@jonah.com>
Subject Re: Is Template thread safe?
Date Wed, 03 Apr 2002 18:40:03 GMT

I found VelocityServlet to be close to but not quite what I needed for
my specific application requirements, but I believe it can support the
sort of friendly error display I was talking about, where friendly means
that thrown exceptions are caught and a special vtl error template is
sent back to the user instead of the requested page. 

Note that the exceptions are what I'm concerned about presenting to
developers. Warnings that appear in the logs are not so interesting to
my developers. 

I think the following would be sufficient to implement this support in
an extension of VelocityServlet. 

1. Make 3 error templates

Make one template for ParseError exceptions (the most common), one for
ResourceNotFound exceptions, and one for general parse-time Exceptions.
In my case, the templates are just VTL pages that expect the context to
contain an Exception and the HttpServletRequest.

In the parse exception template, the VTL also expects to get a helper
object that can parse the ParseErrorException error message to extract
line and column, and a file access object to give the template access to
the file system, so it can display the contents of the template and
point out the location of the parse error. These objects are trivial to
write; I can forward them if you like.

2. Make a method called getTemplateNoEx

This should catch and ignore all exceptions from calling getTemplate():

public Template getTemplateNoEx( String name ) {
	Template t = null;
	try {
		t = getTemplate( name );
	}
	catch( Exception e ) {
		// ignore
		t = null;
	}
	return t;
}


3. Override handleRequest( HttpServletRequest req, HttpServletResponse
res, Context ctx ) with something that catches the pre-execution
exceptions and returns the appropriate error template when they occur:

Template t;
try {
	t = getTemplate( req.getServletPath() );
}
catch( ParseErrorException pe ) {
	ctx.put( "Exception", pe );
	ctx.put( "Request", req );
	ctx.put( "ParseErrorHelper", new ParseErrorHelper() );
	ctx.put( "FileSystemHelper", new FileSystemHelper() );
	t = getTemplateNoEx( "/path/to/parseErrorTemplate.vtl" );
}
catch( ResourceNotFoundException re ) {
	ctx.put( "Exception", re );
	ctx.put( "Request", req );
	t = getTemplateNoEx( "/path/to/notFoundTemplate.vtl" );
}
catch( Exception e ) {
	ctx.put( "Exception", e );
	ctx.put( "Request", req );
	t = getTemplateNoEx( "/path/to/generalErrorTemplate.vtl" );
}
if (t == null) {
	// rethrow out to the error()
        throw new Exception ("handleRequest returned null" );
}

return t;

===

Hope that helps,

Jonah



On Wed, 2002-04-03 at 06:33, Geir Magnusson Jr. wrote:
> On 4/3/02 9:27 AM, "Charles N. Harvey III" <charlieh@alloy.com> wrote:
> 
> > I have a question about errors related to this thread.
> > I would like to display the error in the .vm to the browser instead of just
> > to the log file.  I will have many developers working on many templates and
> > only the app guys will really have access to the logs.
> > 
> > So is there a way to display the error inline?  As in, instead of the
> > rendered
> > variable (or control statement) the error is displayed?  Or, can I pass all
> > errors to an error template like Jonah asked about and display the error
> > template?
> > 
> > I am imagining that I just need to know where the errors get handled in my
> > extension of VelocityServlet so I can catch them and put them into a context
> > and
> > then render the error template.
> 
> Right now, the VelocityServlet is pretty primitive about error handling,
> just doing what the velocity properties tell it to.
> 
> A first thought is you could have your class implement the
> o.a.v.r.log.LogSystem interface, and then use that as the logger - then you
> can catch every log message and blather to the output.
> 
> However, for an environment with multiple requests going through the same
> servlet at the same time, it will be a muddled mess, so unless you have a
> nice dev environment where people are separated, this idea is actually a bad
> one :)
> 
> 
> > 
> > Thanks.
> > 
> > Charlie
> > 
> >> -----Original Message-----
> >> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> >> Sent: Tuesday, April 02, 2002 8:37 PM
> >> To: velocity-user@jakarta.apache.org
> >> Subject: Re: Is Template thread safe?
> >> 
> >> 
> >> On 4/2/02 6:53 PM, "jonah benton" <jonah@jonah.com> wrote:
> >> 
> >>> 
> >>> Hi,
> >>> 
> >>> I have a quick question- is Template thread safe?- stemming from a
> >>> slightly involved background problem.
> >>> 
> >>> I have a servlet application in which I'd like to be able to send VTL
> >>> template-based responses when velocity-detected errors occur in normal
> >>> template processing. For instance, when velocity detects a syntax error
> >>> in the requested template, I'd like to load and send a special VTL page
> >>> that displays information about the error.
> >>> 
> >> 
> >> So far, so good.
> >> 
> >>> While this two-layer scheme works well for developers, it requires two
> >>> layers of exception handling in the servlet to catch possible errors.
> >>> One layer catches exceptions thrown during normal request processing,
> >>> and one layer catches exceptions thrown during error page processing.
> >> 
> >> Sort of - you can catch the syntax errors and not let them escape the
> >> 'handleRequest()' method (assuming you are using VelocityServlet...)
> >> 
> >>> Yuck!
> >>> 
> >>> The various encapsulation schemes I've considered all strike me as
> >>> involving too much complexity, except for one- loading and parsing the
> >>> error templates at initialization time. If I can keep parsed Template
> >>> instances as instance vars in the servlet, then merge those, I can keep
> >>> to one exception handling layer.
> >>> 
> >>> Is Template designed to let me do this, or does the engine hand out
> >>> cloned instances of Template to different threads?
> >> 
> >> Same instance.  Perfectly threadsafe.  That's actually what the
> >> caching does
> >> - it keeps one parsed copy and uses it for all requests.  The template
> >> itself is actually stateless - it's the context that you send
> >> through it at
> >> render time that can be modified...
> >> 
> >>> Thanks, and as this is my first post, thanks to Geir for a great
> >>> technology.
> >> 
> >> Thank you for the kind words, but there are many contributors to Velocity.
> >> I am just the noisiest... :)
> >> 
> >> --
> >> Geir Magnusson Jr.                                     geirm@optonline.net
> >> System and Software Consulting
> >> 
> >> The cost of synchronization is much less that the cost of stupidity.
> >> 
> >> 
> >> --
> >> To unsubscribe, e-mail:
> >> <mailto:velocity-user-unsubscribe@jakarta.apache.org>
> >> For additional commands, e-mail:
> >> <mailto:velocity-user-help@jakarta.apache.org>
> >> 
> > 
> > 
> > --
> > To unsubscribe, e-mail:
> > <mailto:velocity-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:velocity-user-help@jakarta.apache.org>
> > 
> 
> -- 
> Geir Magnusson Jr.                                     geirm@optonline.net
> System and Software Consulting
> My inner cowboy needs to yodel.
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:velocity-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:velocity-user-help@jakarta.apache.org>
> 



--
To unsubscribe, e-mail:   <mailto:velocity-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:velocity-user-help@jakarta.apache.org>


Mime
View raw message