I found this piece of code in VelocityManager.
if (p.getProperty(Velocity.RESOURCE_LOADER) == null) {
p.setProperty(Velocity.RESOURCE_LOADER, "wwfile, wwclass");
}
if (context.getRealPath("") != null) {
p.setProperty("wwfile.resource.loader.description", "Velocity File
Resource Loader");
p.setProperty("wwfile.resource.loader.class",
"org.apache.velocity.runtime.resource.loader.FileResourceLoader");
p.setProperty("wwfile.resource.loader.path", context.getRealPath(""));
} else if (p.getProperty(Velocity.RESOURCE_LOADER) == null) {
p.setProperty(Velocity.RESOURCE_LOADER, "wwclass");
}
which means (if I understand correctly), that if you don't specify a resource loader
in your velocity.properties, ww2 will set it for you.
The missing thing is the possibility to have
file.resource.loader.cache = true
file.resource.loader.modificationCheckInterval = <some_interval>
But I think it isn't to hard to provide some configuration in webwork.properties.
Something like:
webwork.velocity.template.caching=true
webwork.velocity.template.modificationCheckInterval = <some_interval>
and depeding on the existence of that in webwork.properties, to set those properties.
Something like:
if (context.getRealPath("") != null) {
p.setProperty("wwfile.resource.loader.description", "Velocity File
Resource Loader");
p.setProperty("wwfile.resource.loader.class",
"org.apache.velocity.runtime.resource.loader.FileResourceLoader");
p.setProperty("wwfile.resource.loader.path", context.getRealPath(""));
if
(Configuration.get("webwork.velocity.template.caching").toString().equals("true")) {
p.setProperty("wwfile.resource.loader.cache","true");
String interval =
Configuration.get("webwork.velocity.template.modificationCheckInterval").toString();
if (!interval.equals("")) {
p.setProperty("wwfile.resource.loader.modificationCheckInterval",interval);
}
}
} else if (p.getProperty(Velocity.RESOURCE_LOADER) == null) {
p.setProperty(Velocity.RESOURCE_LOADER, "wwclass");
}
I can try to put this to work, and provide a patch attached to some JIRA issue,
if there will be some interest in including it in ww2.
Other possibility, is to not set a resource loader in velocity.properites, but
set only something like this:
wwfile.resource.loader.cache = true
wwfile.resource.loader.modificationCheckInterval = <some_interval>
I don't know if this will work, I'll give a try, and let you know.
Fernando Martins
On Saturday 31 January 2004 02:59, Dag Liodden wrote:
> "WebRoot" is not magic. It's just where I have put the root in my
> Eclipse project. The velocity loader didn't find my files otherwise and
> I think it's just a Jetty issue (which I start from Eclipse). If you
> deploy you app as a WAR or have you root somewhere else, you can just
> skip / change it.
>
> Dag
>
> Fernando Martins wrote:
> >Maybe the only way of doing this is to have ww2 configure velocity caching
> > based on some velocity.caching = true property in webwork.properties.
> >That way, ww2 can set the correct WebRoot path.
> >Any thoughts?
> >
> >On Friday 30 January 2004 18:28, Fernando Martins wrote:
> >>Some time ago, I also came to the same conclusion that when activating
> >>velocity caching of templates, rendering is done much faster.
> >>One thing I still don't know how to solve is the following:
> >>
> >>In Dag velocity.properties example there is the line:
> >>>file.resource.loader.path = .,WebRoot
> >>
> >>which if I understand correctly is necessary for enabling caching.
> >>Is "WebRoot" some magic word for velocity/ww2 or is just an guideline so
> >>that one should put there specific path where the templates are located.
> >> If so, the problem is I don't want to have hardcoded the WebRoot path,
> >> in the configuration.
> >>
> >>Does anyone know out to enable caching in velocity (using ww2) which
> >>doesn't require such hardcoded path configuration?
> >>Thanks
> >>
> >>On Thursday 08 January 2004 23:46, Patrick Lightbody wrote:
> >>>Dag, this is great work -- could you please open a bug for this?
> >>>
> >>>-----Original Message-----
> >>>From: [EMAIL PROTECTED]
> >>>[mailto:[EMAIL PROTECTED] On Behalf Of
> >>>Dag Liodden
> >>>Sent: Thursday, January 08, 2004 2:37 PM
> >>>To: [EMAIL PROTECTED]
> >>>Subject: Re: [OS-webwork] Xwork/WebWork2 under extreme load
> >>>
> >>>
> >>>I think that using the taglib is slow due to the massive amount of
> >>>template parsing that is associated with rendering of the tags. By
> >>>default, Velocity does not cache templates and so each tag will result
> >>>in loading and parsing the templates. I've done a very simple
> >>>stress-test with profiling and turning on resource increased performance
> >>>
> >>>noticeably on results with extensive use of the taglib (e.g a large
> >>>input form). Mathias, since you obviously have a test-harness ready to
> >>>go, perhaps you could turn caching on and give us some figures?
> >>>
> >>>Below is a simple Velocity configuration that goes into
> >>>velocity.properties in WEB-INF with caching turned on. The modificattion
> >>>
> >>>interval is in seconds and could probably be adjusted up too (I use 2
> >>>seconds since it's adequate for development) - I think zero means never
> >>>refresh but I can't really remember from the top of my head.
> >>>
> >>>-- Snip --
> >>>
> >>>velocimacro.library = VM_global_library.vm,tigris-macros.vm
> >>>
> >>>runtime.log.error.stacktrace = true
> >>>runtime.log.warn.stacktrace = true
> >>>runtime.log.info.stacktrace = true
> >>>runtime.log.invalid.reference = true
> >>>
> >>># Resource loaders
> >>>resource.loader = file, class
> >>>
> >>>file.resource.loader.description = Velocity File Resource Loader
> >>>file.resource.loader.class =
> >>>org.apache.velocity.runtime.resource.loader.FileResourceLoader
> >>>file.resource.loader.path = .,WebRoot
> >>>file.resource.loader.modificationCheckInterval = 2
> >>>file.resource.loader.cache = true
> >>>
> >>>class.resource.loader.description = Velocity Classpath Resource Loader
> >>>class.resource.loader.class =
> >>>org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
> >>>file.resource.loader.modificationCheckInterval = 2
> >>>file.resource.loader.cache = true
> >>>
> >>>velocimacro.permissions.allow.inline = true
> >>>velocimacro.permissions.allow.inline.to.replace.global = true
> >>>velocimacro.permissions.allow.inline.local.scope = false
> >>>
> >>>velocimacro.context.localscope = false
> >>>
> >>>#-----------------------------------------------------------------------
> >>>-----
> >>># INTERPOLATION
> >>>#-----------------------------------------------------------------------
> >>>-----
> >>># turn off and on interpolation of references and directives in string
> >>># literals. ON by default :)
> >>>#-----------------------------------------------------------------------
> >>>-----
> >>>runtime.interpolate.string.literals = true
> >>>
> >>>
> >>>#-----------------------------------------------------------------------
> >>>-----
> >>># RESOURCE MANAGEMENT
> >>>#-----------------------------------------------------------------------
> >>>-----
> >>># Allows alternative ResourceManager and ResourceCache implementations
> >>># to be plugged in.
> >>>#-----------------------------------------------------------------------
> >>>-----
> >>>resource.manager.class =
> >>>org.apache.velocity.runtime.resource.ResourceManagerImpl
> >>>resource.manager.cache.class =
> >>>org.apache.velocity.runtime.resource.ResourceCacheImpl
> >>>
> >>>-- Snip --
> >>>
> >>>Cheers,
> >>>
> >>>Dag
> >>>
> >>>Jason Carreira wrote:
> >>>>I think there's still a major Velocity tuning issue there that we need
> >>>>to address...
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: Francisco Hernandez [mailto:[EMAIL PROTECTED]
> >>>>>Sent: Thursday, January 08, 2004 3:28 PM
> >>>>>To: [EMAIL PROTECTED]
> >>>>>Subject: Re: [OS-webwork] Xwork/WebWork2 under extreme load
> >>>>>
> >>>>>
> >>>>>i've noticed that using webwork2 taglibs is slow.. the more i use the
> >>>>>slower requests get
> >>>>>
> >>>>>BOGAERT Mathias wrote:
> >>>>>>Hi,
> >>>>>>
> >>>>>>I'm currently stress testing my application on WebLogic 8.1 under
> >>>>>>extreme load. It seems Xwork has some blocking issues, especially in
> >>>>>>regard to OGNL (getting/setting values on the stack).
> >>>>>>
> >>>>>>Before I go further to investigate deeply, did anyone see
> >>>>>
> >>>>>this before?
> >>>>>
> >>>>>>And are there any best practices concerning threads and the
> >>>>>
> >>>>>way a web
> >>>>>
> >>>>>>application should be written?
> >>>>>>
> >>>>>>Thanks,
> >>>>>>Mathias Bogaert
> >>>>>>
> >>>>>>
> >>>>>>-------------------------------------------------------
> >>>>>>This SF.net email is sponsored by: Perforce Software.
> >>>>>>Perforce is the Fast Software Configuration Management
> >>>>>
> >>>>>System offering
> >>>>>
> >>>>>>advanced branching capabilities and atomic changes on 50+ platforms.
> >>>>>>Free Eval! http://www.perforce.com/perforce/loadprog.html
> >>>>>>_______________________________________________
> >>>>>>Opensymphony-webwork mailing list
> >>>>>>[EMAIL PROTECTED]
> >>>>>>https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> >>>>>
> >>>>>-------------------------------------------------------
> >>>>>This SF.net email is sponsored by: Perforce Software.
> >>>>>Perforce is the Fast Software Configuration Management System
> >>>>>offering advanced branching capabilities and atomic changes
> >>>>>on 50+ platforms. Free Eval!
> >>>>>http://www.perforce.com/perforce/loadprog.html
> >>>>>
> >>>>>_______________________________________________
> >>>>>Opensymphony-webwork mailing list
> >>>>>[EMAIL PROTECTED]
> >>>>>https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> >>>>
> >>>>-------------------------------------------------------
> >>>>This SF.net email is sponsored by: Perforce Software.
> >>>>Perforce is the Fast Software Configuration Management System offering
> >>>>advanced branching capabilities and atomic changes on 50+ platforms.
> >>>>Free Eval! http://www.perforce.com/perforce/loadprog.html
> >>>>_______________________________________________
> >>>>Opensymphony-webwork mailing list
> >>>>[EMAIL PROTECTED]
> >>>>https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> >>>
> >>>-------------------------------------------------------
> >>>This SF.net email is sponsored by: Perforce Software.
> >>>Perforce is the Fast Software Configuration Management System offering
> >>>advanced branching capabilities and atomic changes on 50+ platforms.
> >>>Free Eval! http://www.perforce.com/perforce/loadprog.html
> >>>_______________________________________________
> >>>Opensymphony-webwork mailing list
> >>>[EMAIL PROTECTED]
> >>>https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> >>>
> >>>
> >>>-------------------------------------------------------
> >>>This SF.net email is sponsored by: Perforce Software.
> >>>Perforce is the Fast Software Configuration Management System offering
> >>>advanced branching capabilities and atomic changes on 50+ platforms.
> >>>Free Eval! http://www.perforce.com/perforce/loadprog.html
> >>>_______________________________________________
> >>>Opensymphony-webwork mailing list
> >>>[EMAIL PROTECTED]
> >>>https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> >>
> >>-------------------------------------------------------
> >>The SF.Net email is sponsored by EclipseCon 2004
> >>Premiere Conference on Open Tools Development and Integration
> >>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> >>http://www.eclipsecon.org/osdn
> >>_______________________________________________
> >>Opensymphony-webwork mailing list
> >>[EMAIL PROTECTED]
> >>https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> >
> >-------------------------------------------------------
> >The SF.Net email is sponsored by EclipseCon 2004
> >Premiere Conference on Open Tools Development and Integration
> >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> >http://www.eclipsecon.org/osdn
> >_______________________________________________
> >Opensymphony-webwork mailing list
> >[EMAIL PROTECTED]
> >https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
