You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by jonah benton <jo...@jonah.com> on 2002/04/03 01:53:54 UTC
Is Template thread safe?
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.
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.
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?
Thanks, and as this is my first post, thanks to Geir for a great
technology.
Jonah
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: null in velocity
Posted by Sven Meier <sv...@meiers.net>.
Hi,
the reason for this is that velocityContext doesn't accept NULL value in the
put() method, see:
http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg05700.html
The thread ends with:
"After a talk here we all agreed on Geir's proposal. Setting a variable to
NULL will
remove it from the context."
.. but I don't know what became of it.
I've solved this with a overridden put() in my own subclass of
velocityContext.
Sven
----- Original Message -----
From: Jing Chen <ji...@marketderby.com>
To: Velocity Users List <ve...@jakarta.apache.org>
Sent: Thursday, April 04, 2002 4:24 AM
Subject: null in velocity
>
> Hi there,
>
> Dose velocity support null? e.g.
>
> #set( $msgs = $requ.getMessages())
>
> getMessages() returns an Object[], now, if $msgs has some value of
Object[],
> and getMessages() returns null, then the $msgs keeps the original value,
it
> cannot change to null, dose velocity handle such problems?
>
> thanks
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
null in velocity
Posted by Jing Chen <ji...@marketderby.com>.
Hi there,
Dose velocity support null? e.g.
#set( $msgs = $requ.getMessages())
getMessages() returns an Object[], now, if $msgs has some value of Object[],
and getMessages() returns null, then the $msgs keeps the original value, it
cannot change to null, dose velocity handle such problems?
thanks
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is Template thread safe?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 2:38 PM, "Huy K Dung" <hd...@lending4all.com> wrote:
> How do i encode URLs in Velocity Macro? I am using Tomcat and Turbine.
>
I would figure that turbine would have that available as a tool. If not, I
always grab Jon's encoder out of the Anakia package and drop it into the
context...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Now what do we do?"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Is Template thread safe?
Posted by Huy K Dung <hd...@lending4all.com>.
How do i encode URLs in Velocity Macro? I am using Tomcat and Turbine.
Re: velstruts
Posted by Mark de Reeper <ma...@yahoo.com>.
The context variables magic is handled by the ChainedContext that is part of
the view tools, see org.apache.velocity.tools.view.context.ChainedContext. It
searches all of the scopes, applications, request, session as well as the
toolbox entries for the variable.
It is created in the VelocityViewServlet when the createContext is called.
--- "Charles N. Harvey III" <ch...@alloy.com> wrote:
> I finally decided to try out the velocity-struts merger. The examples
> are great and very clear. There is only one bit that I don't get and
> I'm sure its in a doc somewhere.
>
> Where do the context variables come from?
>
> When you look at a jsp page it has all that:
> <%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
> garbage. But the .vm page has no such reference. But it uses the same
> variable names as the bean in the context.
>
> <logic:present name="user"> == #if( $user )
>
> So where did $user come from? I have looked all through the source code
> and there is not one context.put();. So something is either happening
> in the VelocityViewServlet or in a config file that I don't know about.
> And how does it know which "taglibs" to use?
>
>
> I have been trying to write my own controller for a while but don't really
> trust myself. So I have been experimenting with different MVC models.
> From ActionServlet to Struts to WebWork. I like the simplicity of WebWork
> but am having a hard time convincing others of its usefullness. Same with
> ActionServlet. But since neither has the popularity of Struts I started
> messing with the velstruts combination. And it works basically the same
> as WebWork - which is great.
>
> I know I am asking two questions at once, but are there any opinions out
> there
> about which model is easiest? It may not matter, I have some pretty rigid
> (and faint of heart) people to convince.
>
> Thanks again Velocitors!
>
> Charlie
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
velstruts
Posted by "Charles N. Harvey III" <ch...@alloy.com>.
I finally decided to try out the velocity-struts merger. The examples
are great and very clear. There is only one bit that I don't get and
I'm sure its in a doc somewhere.
Where do the context variables come from?
When you look at a jsp page it has all that:
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
garbage. But the .vm page has no such reference. But it uses the same
variable names as the bean in the context.
<logic:present name="user"> == #if( $user )
So where did $user come from? I have looked all through the source code
and there is not one context.put();. So something is either happening
in the VelocityViewServlet or in a config file that I don't know about.
And how does it know which "taglibs" to use?
I have been trying to write my own controller for a while but don't really
trust myself. So I have been experimenting with different MVC models.
>From ActionServlet to Struts to WebWork. I like the simplicity of WebWork
but am having a hard time convincing others of its usefullness. Same with
ActionServlet. But since neither has the popularity of Struts I started
messing with the velstruts combination. And it works basically the same
as WebWork - which is great.
I know I am asking two questions at once, but are there any opinions out
there
about which model is easiest? It may not matter, I have some pretty rigid
(and faint of heart) people to convince.
Thanks again Velocitors!
Charlie
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Is Template thread safe?
Posted by "Charles N. Harvey III" <ch...@alloy.com>.
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" <ch...@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" <jo...@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:
> > >> <ma...@jakarta.apache.org>
> > >> For additional commands, e-mail:
> > >> <ma...@jakarta.apache.org>
> > >>
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> >
> > --
> > Geir Magnusson Jr.
> geirm@optonline.net
> > System and Software Consulting
> > My inner cowboy needs to yodel.
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is Template thread safe?
Posted by jonah benton <jo...@jonah.com>.
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" <ch...@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" <jo...@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:
> >> <ma...@jakarta.apache.org>
> >> For additional commands, e-mail:
> >> <ma...@jakarta.apache.org>
> >>
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> My inner cowboy needs to yodel.
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is Template thread safe?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 9:27 AM, "Charles N. Harvey III" <ch...@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" <jo...@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:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
My inner cowboy needs to yodel.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Is Template thread safe?
Posted by "Charles N. Harvey III" <ch...@alloy.com>.
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.
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" <jo...@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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Is Template thread safe?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/2/02 6:53 PM, "jonah benton" <jo...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>