for VelocityTools 2 (the WebappResourceLoader), this would look like this:
resource.loader = webapp
webapp.resource.loader.class =
org.apache.velocity.tools.view.WebappResourceLoader
and would look for templates in the webapp's root. if you want to,
for instance, hide the templates in ${webappRoot}/WEB-INF/templates,
then do this:
webapp.resource.loader.path = /WEB-INF/templates/
multiple paths are supported, just like FileResourceLoader. caching
and reloading only work in an exploded WAR deployment, of course.
i've never compared performance, but it's really outside the concern
of the loader. the difference is that you are getting data from
ServletContext.getResourceAsStream() instead FileInputStream. so, to
compare performance would just be to compare getting resources from
your servlet container vs getting them direct from the file system. i
can't imagine there is a noteworthy difference.
On Fri, May 2, 2008 at 12:06 PM, csanders <[EMAIL PROTECTED]> wrote:
> You wouldn't happen to have a sample velocity.properties file using
> WebappResourceLoader would you ?
>
> Thanks,
> Charlie
>
>
>
> Nathan Bubna wrote:
>
> > On Fri, May 2, 2008 at 7:50 AM, csanders <[EMAIL PROTECTED]> wrote:
> >
> >
> > > Is there anyway we can set relative paths in this file ?
> > >
> > >
> >
> > in which file? in velocity.properties?
> >
> >
> >
> > > This is the only configuration file out of dozens that doesn't support
> this and its making deployment a serious pain.
> > >
> > >
> > >
> >
> > are you deploying to a servlet container? if so, then the
> > FileResourceLoader is not your friend. you should be using the
> > WebappLoader (aka WebappResourceLoader) that is part of the
> > VelocityTools project. It uses servlet context relative paths.
> >
> >
> >
> > > Or can I use environmental variables in this file ? That would work
> also.
> > >
> > >
> > >
> >
> > sounds like a useful thing to me!
> >
> >
> >
> > > If not - how much development would it take to get this to work ? It
> might be worth it for us to contribute this to Velocity.
> > >
> > >
> > >
> >
> > i don't think it would be all that hard to add support for including
> > environmental variables in the properties. you would pretty much just
> > watch for properties either coming in or going out of RuntimeInstance
> > for environment variables and do the replacement there. It would
> > probably be easiest to do this in RuntimeInstance#getProperty.
> >
> >
> >
> >
> > > Thanks,
> > > Charlie
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
