On Tue, Sep 22, 2009 at 4:12 PM, André Warnier <a...@ice-sa.com> wrote: > Leon Rosenberg wrote: > ... >> >> As for preventing decompilation, how many people/companies are >> actually delivering a war which they need to protect from decompiling? >> How many people would install such a product, one they can't configure >> anymore, one that is even infectable by viruses? >> >> This just sounds plain wrong :-) > > Leon, > I can't comment on the speed aspect etc.. > But I have a number of corporate customers who have sub-contracted their IT > infrastructure to an external service company. > In my experience these external people then, usually, tend to adopt the > "umbrella" attitude, whereby they want every other external software > supplier to supply their software in a manner that will cause themselves the > least work and the least trouble. In other words, their ideal is that the > software be delivered in the form of a single executable, pre-parameterised > so that they don't even have to choose options in an installer, and that > they would not bear any responsibility if anything should not work as > expected. > They are certainly not interested in even having to think about tricky > customising options. > I am not saying that these are my preferred kind of customers. > (I prefer smart ones, up to a point). > But this is a "use case" for the proposed package, it seems to me.
I work with external operations departments a lot. Many of them aren't the brightest but they all manage to a) untar a previously configured and tared tomcat and b) replace a war file or untar and relink a package. And they all learned shutdown.sh and startup.sh. However, in most companies I observe that operation takes over tomcat configuration (playing with gc and memory settings etc) and development simply delivers a war, which is injected with configuration by the operation department. But well, people may still find this feature useable :-) regards Leon > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
