RE: common image practice?
Hi, Ben's exactly right. More than deaf ears: rejecting fingers (the ones that close issues as RESOLVED-WONTFIX ;)). Yoav Shapira http://www.yoavshapira.com -Original Message- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: Thursday, December 02, 2004 5:00 PM To: Tomcat Users List Subject: Re: common image practice? On Thu, 2004-12-02 at 16:49, Rhino wrote: 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. I think your time would be better spent lobbying to get this put into the Servlet Spec (but I think that would be a waste of time too) because Tomcat development is driven by the Servlet/JSP specs. Since this isn't in the specs and since it goes against the the J2EE principal of self contained apps, my guess is that it would fall on deaf ears in either camp. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: common image practice?
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. 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. 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... Nix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: common image practice?
On Thu, Dec 02, 2004 at 12:51:21AM -0700, 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,
True.
: and duplicating logos in every project also
: seems wrong.
Why so? If you come from a strong C, C++, or systems management
background, it may be a little tough to swallow at first. Those are
venues in which file-level sharing and reuse are helpful. (Sort of.
Trying to get apps to share libraries works just fine until version skew
rears its ugly head. You'll eventually reach the same impasse trying to
get webapps to share static content.)
Java webapps are different: each one is supposed to be a self-contained
package that can be dropped into a container for execution. Even the
use of {tomcat}/shared/lib is discouraged, as it places a webapp
dependency outside of the webapp itself.
You could address your problem at build time instead of runtime: have
Ant (or whatever) pull the common data into the webapp before it
packages the WAR file. If you mix this with your version control
system, different apps could have different versions of these files as
their needs diverge.
-QM
--
software -- http://www.brandxdev.net
tech news -- http://www.RoarNetworX.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: common image practice?
On Thu, Dec 02, 2004 at 12:51:21AM -0700, 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 You could address your problem at build time instead of runtime: have Ant (or whatever) pull the common data into the webapp before it packages the WAR file. If you mix this with your version control system, different apps could have different versions of these files as their needs diverge. i'd second that. in your source control repository you can happily have a branch for common files. but when it comes to building the web apps, each build would suck in that common branch. if you need to update those common files, do it to the source control verson and rebuild the webapps. FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE --- QAS Ltd. Developers of QuickAddress Software a href=http://www.qas.com;www.qas.com/a Registered in England: No 2582055 Registered in Australia: No 082 851 474 --- /FONT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
Re: common image practice?
QM wrote:
On Thu, Dec 02, 2004 at 12:51:21AM -0700, 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,
True.
: and duplicating logos in every project also
: seems wrong.
Why so? If you come from a strong C, C++, or systems management
background, it may be a little tough to swallow at first. Those are
venues in which file-level sharing and reuse are helpful. (Sort of.
Trying to get apps to share libraries works just fine until version skew
rears its ugly head. You'll eventually reach the same impasse trying to
get webapps to share static content.)
I do come from that background, and I understand what you are saying
about version skew. What I'm looking at though are logos and for example
valid xhtml png file that w3c provides if you pass their validator.
They have no logic to them, and will never change. Also a logo, and even
CSS stylesheets, are something I would really hate to duplicate...doing
so means that if it changes I can't forget to update all of them at the
same time. Building a single integrated app would fix this, but then it
just gets to be bloated.
Java webapps are different: each one is supposed to be a self-contained
package that can be dropped into a container for execution. Even the
use of {tomcat}/shared/lib is discouraged, as it places a webapp
dependency outside of the webapp itself.
Unfortunately, this shared directory doesn't seem to work for anything
but classes. Image files have no way of being deposited here. I totally
agree on the use of that directory for logic/classes, but I'd love to
see a search path for image files and maybe CSS files where it first
searches inside the app context, and then in the shared/ directory.
Doesn't seem possible.
You could address your problem at build time instead of runtime: have
Ant (or whatever) pull the common data into the webapp before it
packages the WAR file. If you mix this with your version control
system, different apps could have different versions of these files as
their needs diverge.
Having it update at runtime makes theme changes easier, though not much.
The other concern here is file space from duplication of resources.
Although I currently do not foresee CSS and theme images as being too
large to do this, it can easily end up that way in the future. Right now
I'm leaning towards adding the images to each app, but I'm not
completely comfortable with this.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: common image practice?
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]
Re: common image practice?
Rhino wrote: 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. ... I probably will, but I'd look kind of silly if there were already a solution (I'm new to tomcat) :P 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: common image practice?
On Thu, 2004-12-02 at 16:49, Rhino wrote: 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. I think your time would be better spent lobbying to get this put into the Servlet Spec (but I think that would be a waste of time too) because Tomcat development is driven by the Servlet/JSP specs. Since this isn't in the specs and since it goes against the the J2EE principal of self contained apps, my guess is that it would fall on deaf ears in either camp. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: common image practice?
On Thu, Dec 02, 2004 at 12:51:21AM -0700, 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, An approach I took to a different problem may work. I needed to upload and serve out images for an app. I did not want to include the images in the app and did not want them to be removed or overwritten on redeploy of an app. I wrote a small class to access a directory that would store the images and another to take request for these images and retrieve them from the external directory. I could see creating a small class that looked into a common folder and served these items. Note: My solution is NOT portable and I have total control on the server. If you would like further details ... Option 2: Have a separate app that does nothing but serves up these common items. The path in your pages would then be absolute urls and not relative. (I have seen several IP paths like this as well.) Option 3: Store it in a database that all apps have access to. This would at least meet spec. You could have a class that polls the database on some interval (daily) and holds the objects in memory to serve them as needed. Doug www.parsonstechnical.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: common image practice?
Depending on how many you are talking about you could have a dedicated image host (or virtual host) which solely serves images. PJ 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. - 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]
Re: common image practice?
On Thu, Dec 02, 2004 at 02:36:35PM -0700, D. Stimits wrote: : I do come from that background, So did I, which is why I brought it up. =) When in Rome... : Having it update at runtime makes theme changes easier, though not much. Ah, I see -- if you mean that your webapps run in an exploded-dir format (instead of a packed/sealed WAR file) then this may be tempting. I aim for full WAR files for all but the development phase. It's cleaner, it enforces the self-contained idea, and (IIRC) it's the only webapp format the spec requires containers to support. : The other concern here is file space from duplication of resources. If you're writing Java webapps, tacking a few kb (or even a few hundred kb) onto each WAR file isn't a big deal. -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
common image practice?
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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
