Thank you all for your input!
I do realize that our use case is somewhat odd, as we have multiple webapps
that have shared resources and are related in that sense.
For now, we should go for the duplication of resources (using Tomcat 7).
However, the webAppMount option looks like a fair option to me, once we
have migrated to Tomcat 8.

Regards,

Maarten



2014/1/1 Christopher Schultz <ch...@christopherschultz.net>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Leo,
>
> On 12/31/13, 3:58 PM, Leo Donahue wrote:
> > On Dec 31, 2013 3:15 AM, "Maarten van Hulsentop"
> > <maar...@vanhulsentop.nl> wrote:
> >>
> >> Hello,
> >>
> >> We are using Tomcat to host a number of web applications as a
> >> uniform solution. We trying to implement something that seems to
> >> be an odd requirement, evh it is really a use case for us.
> >>
> >> We would like to define a single [default] error page for all
> >> web applications residing on this Tomcat instance. After some
> >> experimentation and googling around, it seems that there is no
> >> clear-cut solution for
> > this.
> >> I see a few options;
> >>
> >> - Let the global conf/web.xml define error pages for all web
> >> applications at once. However these are always relative to the
> >> web application context, and require every web application to
> >> pack the error pages again, which is
> > a
> >> duplicate of resources and defeats the DRY principle.
> >
> > I asked a question similar to this a while back regarding JSF
> > templates.
> >
> > If you pick a location to share this resource among all web apps,
> > then your web apps aren't self contained.
> >
> > The solution is in your build / deploy process.
>
> +1
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJSxGvAAAoJEBzwKT+lPKRYWxsQALL6eBfL6J9Gv1Lkw1YY4sHo
> BmVEDiOW2fKpI8U7XJgWeGOJosN0Pd7hrBh4NP8KZtqP8Xx+t7yf+R0iIaftp6a9
> cN237abc629k5x8k3Cg5XwY94mVMVYRTbLu4BnlsERVCVskw+A4dhcAfwwdJRykc
> fg0FbLN0WV33uYz7zFsSl0hxP2Yhxl1ZQBocn8OgwdiEkO17K6NLZhfD54AX3W5i
> CfyXRImO6hdpHg3+XTgEQvyfP0/Ydw4n7B8XqRBN9fjOWc2hQp+SYR6Th8BrPWz1
> tRLDR07SmN3BlwSikAiiX7tibzWAfLBK5ENDJ2nUVWhAlp4A9Hbz6W+eOrHu1Bzy
> ghYVs+MMWqd0axBomKVvBq4giL1jhSB2fMno6HdLup/+FF4cdGmfK3eWM5h15rwq
> +hoXjJguZIA2riKlbn5oPKYTEpiP65ufZ5Wa2ylY5KOgQTvENYWgYNj/3p3E9gQY
> PIh9IFUjSXaeG4dZnx9ouUNGO8cBaFPYiBfTaaPyY0DRsatV96z6zCKu249GEcgM
> GZ1gumDJN0mbfsUayqGfBkhneUi83xwDItejjYxyhlxMv3bYesMxGcnmH1bN5UlC
> n/s438m6CpfvIVTq/aQH0AZqStOeVKR5uBX6nqF+yFb7IWa2XpbVonAjYjlsVMDk
> IaUOf1dAf8ISd41svgSc
> =qThL
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Reply via email to