It sounds to me like you've hit on something that lots of people would use. Why not put this forward as a feature request? Perhaps the good folks at Apache will add some kind of shared image directory to Tomcat. It won't help you today but this sounds like something that could be added fairly easily if it doesn't violate the architecture of Tomcat in some important way.
Rhino ----- Original Message ----- From: "D. Stimits" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Thursday, December 02, 2004 4:27 PM Subject: Re: common image practice? > Nikola Milutinovic wrote: > > D. Stimits wrote: > > > >> I'm looking for a "good" or "best" practice to deal with site-wide > >> logo type files...things that will never change, and that every app > >> will want access to. This is on linux, but enabling sym links just > >> seems to be an admin/backup complexity, and duplicating logos in every > >> project also seems wrong. I see the shared directory looks ideal, but > >> apparently this is only for classes or libraries. Perhaps a simple > >> logo loader class in the shared folder would be most convenient, but I > >> have to wonder if loading something as simple as a small logo should > >> have to use the overhead of going through a class. > > > > > > You could place logos and such common stuff in a separate "globa" path, > > otside all webapps (like in the webserver ROOT). This is totally > > un-self-contained. > > I'd like to do this, but I was under the impression that a > webapps/<app>/ was the context of one application and that file paths > outside of this context would not be allowed (I'm thinking in terms of > JSP's right now). > > > > > A slight imprvement is to have a set of common classes that know what > > that "global" path is, could be configurable. That would make you > > semi-self-contained. > > This seems to be an easy alternative, but then it requires what is > probably a lot of overhead relative to just loading a small logo type > file directly. > > > > > A completely self contained solution is hard to achieve, if not > > impossible. How can anything OUTSIDE your webapp be a part of > > self-contained module. I mean, it's outside... > > I was hoping that the "global" solution above would be possible with > some sort of tomcat configuration. The existing shared/ subdirectory > would be ideal, except that it only searches for classes there. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
