velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Charles N. Harvey III" <charl...@alloy.com>
Subject RE: Is Template thread safe?
Date Fri, 05 Apr 2002 01:57:55 GMT
jonah,
this was _extremely_ helpful and just what i was looking for.  thanks so
much for this.

charlie

> -----Original Message-----
> From: jonah benton [mailto:jonah@jonah.com]
> Sent: Wednesday, April 03, 2002 1:40 PM
> To: Velocity Users List
> Subject: Re: Is Template thread safe?
>
>
>
> 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>
>


--
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