Kees Jan Koster schrieb:
> Dear Simon,
>
>> I have embedded the jspwiki project within my own webapp, to provide a
>> help engine. The jspwiki project provides java classes (in a jarfile)
>> plus some .jsp files and assorted resource-files (images, scripts, etc).
>> Currently I put all the java classes as a jarfile in my classpath (ok),
>> and also unpack the jsp and resource files into my webapp's content
>> directory (ugly).
>
> Could you elaborate on why using a separate webapp/war-file for the
> wiki is not working for you?
>
> In your shoes I would probably do just that. Break out the help engine
> into its own webapp for people to install separately.
(a) For convenience. We provide hosted services for our customers, and
frequently update the applications. It's nicer to just redeploy the app
(one webapp) than to redeploy the app plus its corresponding help-webapp
version.
(b) We often host multiple webapps in the same container. So we have
/finance webapp
/personnel webapp
/stockmanagement webapp
It's not so nice to also have to manage a separate help webapp for each
one (and choose a path for it, and configure each deployed webapp to
generate the right url to access the appropriate help-url prefix).
(c) We would prefer to only allow access to the help for logged-in users
(which then allows us to use the wiki ACL features to control access to
different pages based on user roles). Having a separate help app means
the user has to re-authenticate unless we start using "single-signon".
And most importantly, we override about 5 of the jsp files from the
standard distro. By having a mechanism that first looks in the
filesystem, then in the classpath, I would love to check in *just* the
modified files to our version-control as part of the webapp, and for
other cases simply have the default file pulled from the standard
jspwiki jarfile.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
