incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juan Pablo Santos Rodríguez <juanpablo.san...@gmail.com>
Subject Re: The need for war
Date Fri, 03 May 2013 11:37:28 GMT
Hi!

two quick notes (@work so apologies on brevity):

regarding the ready-to-run war, for testing purposes, IMO mvn
tomcat7:run-war would be the way to go for people interested in dev. Users
not interested in compiling source, right now, could use current
JSPWiki.war, as is, it uses some reasonable defaults, so (I think) it's
usable for testing purposes. I agree that adding some additional hints on
startup regarding where are the core pages expected to be found or the
initial config may help, but corepages location must be given at
Install.jsp which is automatically given at first run (which, if I recall
correctly, also generates the jspwiki.properties used by the application).
Exactly, what would you expect to encounter when running the war for the
first time?

as for the properties file, it is possible to have it outside the war via
context init-parameter, "-D" parameter or via tomcat context file (cannot
look to specifics right now) and it's also possible to have one "master"
file with some "child" properties files, overwritting "master" values; cfr.
with https://issues.apache.org/jira/browse/JSPWIKI-568 and
http://doc.jspwiki.org/2.4/wiki/InstallingJSPWikiStepByStep#section-InstallingJSPWikiStepByStep-UsingCascadingAndVariablePropertiesForReducingAdministration


br,
juan pablo

On Fri, May 3, 2013 at 12:49 PM, Glen Mazza <glen.mazza@gmail.com> wrote:

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message