On 05/03/2013 04:20 AM, Jürgen Weber wrote:
I'm not sure if we should really build a war. What's the point of having a war if you have to unpack it anyway? And a zip can contain everything in a toplevel folder, a war not.
Not having a war won't allow devs to quickly run JSPWiki on embedded Tomcat via mvn tomcat7:run-war or standalone via mvn tomcat7:redeploy. I don't want to have to manually copy-and-paste into the Tomcat directory during iterative development.
But if you build a war, it should be ready to run. So I'd suggest to deliver two packages: 1) a ready-to run war, including all corepages (deliver language corresponding to browser settings), tempdir=javax.servlet.context.tempdir and log into container log. A first time user / evaluator should be successful on the first try after dropping the war into tomcat/webapps or jboss/standalone/deployments
I believe we have that in trunk today, the jspwiki.properties was updated by Juan Pablo with workable default values that allow you to start JSPWiki OOTB (i.e., http://localhost:8080/JSPWiki URL, JSPWikiWorkDir or whatever in your OS user home directory) without needing to configure anything. It wasn't like that a few months back though.
b) a zip like the current war, which the user unzips into webapps and configures. I'd also suggest to use org.apache.catalina.loader.VirtualWebappLoader (or org.apache.geronimo.system.sharedlib.SharedLib) to have jspwiki.properties outside of the war. Unfortunately for webapp-security you still have to edit web.xml
AFAIK, a WAR *is* a ZIP, it just has a different file extension and follows a certain directory structure. I'm not sure of the willingness of Tomcat (or any other servlet container) to automatically expand a ZIP-named file like it does a WAR once placed in webapps. Also, people intuitively know what to do with a WAR file, but not with a ZIP (do I need to expand it in its own directory to get a WAR potentially inside it? Does the ZIP include an instance of Tomcat for me?) causing initial confusion.
I like the idea of having jspwiki.properties (or at least one's overrides to jspwiki.properties) outside of the WAR (my comment at the end). However, those classes (catalina/geronimo) would seem to place an undesirable dependency on the servlet container one uses--hopefully there's a more portable way to do that.
The property for tempdir could be removed, a servlet container provides a javax.servlet.context.tempdir context attribute that points to a temp dir.
Certainly nice to delegate to the servlet container, but I've found altering context files to be messier than a JSPWiki config file, when you delete the WAR frequently the context file automatically gets deleted by Tomcat causing you to lose your configuration (that happened with me just yesterday with Roller, which presently and unfortunately requires SSL-relying SMTP servers to be configured via Tomcat context file.)
Also jspwiki.properties should give a hint or best practice where to put the content directory (I have /projects/jspwiki/JSPWiki and /projects/jspwiki/content outside of the appserver tree). What do you think? Juergen
I haven't gotten to it yet, but I like Roller's solution, where they have one big predefined configuration file you never need to alter placed in the WAR (like our jspwiki.properties but read-only), but in Tomcat's home/lib folder (not under webapps) you place a usually 10-15 line roller-custom.properties file where you enter your overrides to the Roller defaults (necessary overrides like DB config and Mail server information plus any of another 100 or so preferences if you wish to override the defaults). This way when you place a new Roller war in Tomcat the defaults in home/lib carry over to the new WAR without needing to re-enter the overrides *within* the WAR each time, annoying for anyone.
(Drawback with that approach is that while mvn tomcat7:redeploy works fine with standalone Tomcat I don't yet know how to deploy via mvn tomcat7:run-war, because with an embedded Tomcat there's no lib directory for me to put the roller-custom.properties in. I assume the Maven Tomcat plugin has some config solution somewhere for that though...)
Apache Karaf does a similar thing, a large config.properties you don't touch and an empty custom.properties, where any value you place in the latter overrides whatever is in the former. It keeps configuration to one small file instead of needing to wade through a large config file to make desired alterations, and allows new default properties to be added by the development team in the big file without requiring a user to have to go back to the new big file and re-enter his overrides there.
Regards, Glen
