The need for war

[Jürgen Weber <ju...@jwi.de>]

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

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

The property for tempdir could be removed, a servlet container
provides a javax.servlet.context.tempdir context attribute that points
to a temp dir.

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

Re: The need for war

[Juan Pablo Santos Rodríguez <ju...@gmail.com>]

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 <gl...@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
>
>

Re: The need for war

[Glen Mazza <gl...@gmail.com>]

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

Re: The need for war

[Jürgen Weber <ju...@jwi.de>]

Please let me clarify:
I suggested a ready-to run war for end users. This means no Maven.
Just deploy the war to your appserver. Nothing more. No fighting with
Maven's firewall settings.

The current war has no content pages. Those would have to be included.

The idea of a zip on the other hand is that experienced users have to
unzip it and configure the resulting JSPWiki.

Resources like jspwiki.properties being found outside of the war has
to be configured for each container, but not in the war. For Tomcat
this is in server.xml, for Geronimo in the deployment plan. For JBoss
7 and later you have to use module dependencies (which unfortuately
have to be put into an ear).

Juergen