On 12/23/2013 03:51 AM, Ichiro Furusato wrote:
I just realised (after re-reading this away from my office) that you didn't
mean ./webapps/wiki/WEB-INF/lib/
but rather ./tomcat7/lib/. I'm not familiar with Apache Roller's approach,
but in a number of the environments
I know of (i.e., that either we manage or have been involved in) we
generally don't have permissions on the
./tomcat7/lib/ directory or anything outside of ./webapps/ and may not be
permitted to do app-level
customisations in that directory.
Yes, like OpenShift, but they define a workaround:
http://web-gmazza.rhcloud.com/blog/gmazza/entry/apache-roller-on-openshift#step4.
Or, give that file to the admin for them to place in the /lib folder.
I believe you can still put your customization file in WEB-INF, as I
wrote, but you just need to give it the new name. Or, you can set the
-Djspwiki.custom.config property, as I listed at [3] below:
http://mail-archives.apache.org/mod_mbox/jspwiki-dev/201308.mbox/%3C5201C24C.8020803%40gmail.com%3E
...at the point of starting the Java instance that will be running the
webapp, to have it point to the new location.
Altering the Tomcat tree outside of the ./webapp/ directory (where app
developers get to install their software)
seems a strange choice. Yes, for those who have root control over their
servers there'll be no permissions
issue, but putting application-level configuration in ./tomcat7/lib/
(rather than say, ./tomcat7/conf/) is going to
raise a few eyebrows.
I dunno, Roller's being doing that for a decade and it's gotten no
complaints. Roller even puts JARs (mail and JDBC) in the
TOMCAT_HOME/lib and additional configuration (SMTP, JNDI) in the
TOMCAT_HOME/conf folders.
So while I don't have a vote I'd vote a -1 on this decision and on the
difficulties it will create in the upcoming
Change Requests we'll be making.
Hmm, you voted +1 earlier when I first made this proposal:
http://mail-archives.apache.org/mod_mbox/jspwiki-dev/201308.mbox/%3CCAFKb9FPFQrkbhoD6eSWST2VbGTybY0bz-vY1fSBps%3Dx9vJmGdw%40mail.gmail.com%3E
The old approach of jspwiki.properties in
the ./webapps/wiki/WEB-INF/
directory is for us a much-preferred way of setting web application
properties. I know how difficult it is to
convince people to change things but this is certainly one thing I would
change (and may have to in order
to install JSPWiki where permissions don't permit otherwise -- or go to the
trouble of hand-modifying the
war file, which is what we've been doing for the past few months, not
realising this was not a bug or pilot
error, but the new design).
No, the new design is eliminate the need for WAR surgery (1) by allowing
your to keep your config out of the WAR, also, (2) to allow the user
to list just those values from the default file he chooses to override,
instead of needing to maintain a copy of the entire jspwiki.properties
file (shrinking the file 80-90% in the process), and (3) allow the user
to rapidly deploy new upgrades of JSPWiki without needing to re-insert
his properties file each time.
Glen
Ichiro
On Mon, Dec 23, 2013 at 12:19 AM, Glen Mazza <glen.ma...@gmail.com> wrote:
We made a change a few months back to Apache Roller-style configuration,
you should be leaving the ini/jspwiki.properties file alone and instead
place a jspwiki-custom.properties file in Tomcat's "lib" folder, containing
just the values you're choosing to override from that default file. The
jspwiki-custom.properties file *could* contain the entire
jspwiki.properties file but really only needs to contain your overrides --
the default ini/ file will be used for any value you don't declare in your
custom properties file.
I'm assume you're referring to your replacement file when you mention
WEB-INF/jspwiki.properties file, I I believe you can also place the
jspwiki-custom.properties file there (actually, just need to rename your
jspwiki.properties override to this new name), but the new design allows
you to leave the WAR alone by using the Tomcat "lib" folder instead, and
you can keep updating/replacing the WAR without needing to re-insert your
custom file each time.
Glen
On 12/22/2013 04:42 AM, Ichiro Furusato wrote:
Hi,
Just a note regarding my experience installing the new version, which
might
be pilot error.
I don't get a vote but this experience might suggest a problem with the
release, dunno.
After building the war I moved its content to my tomcat webapps directory
but found from
the error logs that JSPWiki was prioritising the ./ini/jspwiki.properties
in the jar file over the
one on the file system at WEB-INF/jspwiki.properties. The solution was to
overwrite the
one in the jar file with my customised version, everything now works fine.
But that prioritisation seems somehow wrong. Anyone else notice this, or
am
I simply doing
something wrong? [must be hundreds of times I've done an installation but
it's late and I'm
tired and I may be overlooking something obvious...]
Cheers,
Ichiro
On Sat, Dec 21, 2013 at 12:02 PM, Juan Pablo Santos Rodríguez <
juanpablo.san...@gmail.com> wrote:
This is a release vote for Apache JSPWiki, version 2.10.0. The vote will
be
open for at least 72 hours from now.
It fixes the following issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?
projectId=12310732&version=12323941
Note that we are voting upon the source (tag), binaries are provided for
convenience.
Everybody is encouraged to vote.
Source and binary files:
http://people.apache.org/~juanpablo/releases/2.10.0-rc1
The tag to be voted upon:
http://svn.apache.org/repos/asf/jspwiki/tags/jspwiki_2_10_0_rc1
JSPWiki's KEYS file containing PGP keys we use to sign the release:
http://www.apache.org/dist/jspwiki/KEYS
*** Please download, test and vote:
[ ] +1 Approve the release
[ ] 0 Don't mind
[ ] -1 Disapprove the release (please provide specific comments)
br,
juan pablo
