-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 11/3/14 5:16 PM, Mark Eggers wrote: > Chris, > > On 11/3/2014 1:33 PM, Christopher Schultz wrote: >> Vince, > >> On 11/3/14 4:12 PM, vince.w...@thomsonreuters.com wrote: >>> Even Tomcat newbies have to do real work that will find its >>> way to a real server. > >>> Either of the benefits you described as a) and b) mean >>> CATALINA_HOME and CATALINA_BASE need to be separate on a real >>> server. > >>> I would rather get it straight from the outset rather than mess >>> about with a configuration that is going nowhere. > >> Separating a unified Tomcat deployment into CATALINA_HOME and >> CATALINA_BASE is pretty trivial. Your configuration isn't "going >> nowhere". > >> Do you know what's worse than a simple configuration to start >> that can grow into a complex one? One that is so complex you >> can't even get started. Have you ever configured Weblogic? There >> is (or was, back in circa 2001 when I had the misfortune of >> working on that platform) no such thing as "unzip and run >> bin/startup.sh to launch the server". No, you basically had to go >> and get trained (at a high cost, by corporate trainers, of >> course) to do anything at all with the darned thing. > > > Other application servers are equally unpleasant in my experience. > >> If you want to talk about a configuration that is going nowhere, >> anything that is automatically done by Eclipse, NetBeans, etc. >> is not going anywhere. > > By default, NetBeans does absolutely nothing to change the Tomcat > configuration. Even if you decide to use a separate CATALINA_HOME > and CATALINA_BASE, NetBeans follows the model detailed in > RUNNING.txt. > > >>> NetBeans separates out CATALINA_HOME and CATALINA_BASE, either >>> automatically making its own decisions about the content of >>> CATALINA_BASE or manually by allowing you to specify your own >>> hand crafted directory. > >>> I just made the switch from letting NetBeans populate >>> CATALINA_BASE, to doing it myself. Naturally I want to avoid >>> having the same files appear in both directories so I went for >>> minimal content. > >>> How much easier it would be if the Tomcat distribution had the >>> correct separation build in. > >> It would be harder for newbies and no real benefit to experts. > >> Let me show you the difference in complexity between deploying >> Tomcat with a unified versus split configuration: > >> Unified ------- > >> $ wget http://host/path/to/tomcat-x.y.z.tar.gz $ tar xzf >> http://host/path/to/tomcat-x.y.z.tar.gz $ >> tomcat-x.y.z/bin/startup.sh > >> Woot! > >> Separated --------- $ wget >> http://host/path/to/tomcat-x.y.z.tar.gz $ tar xzf >> http://host/path/to/tomcat-x.y.z.tar.gz $ mkdir -p >> my-tomcat-base/conf $ mkdir -p my-tomcat-base/log $ mkdir -p >> my-tomcat-base/work $ mkdir -p my-tomcat-base/temp $ mkdir -p >> my-tomcat-base/webapps $ cp tomcat-x.y.z/conf/server.xml >> my-tomcat-base/conf $ cp tomcat-x.y.z/conf/web.xml >> my-tomcat-base/conf (the above step may not actually be >> necessary) $ cp tomcat-x.y.z/webapps/ROOT my-tomcat-base/webapps >> $ export CATALINA_HOME=`pwd`/tomcat-x.y.z $ export >> CATALINA_BASE=`pwd`/my-tomcat-base $ >> $CATALINA_HOME/bin/startup.sh > >> Done. > > > This is not so bad for a person used to the command line, but > getting a developer on any platform to do this is going to be a > challenge. I presented those examples in CLI terms because they are brief, concise, and correct. The Nullsoft Installer basically does that same stuff but with safety gear surrounding it. > If that developer is only familiar with Windows or the Macintosh at > a user level, you've placed an almost insurmountable burden in > getting Tomcat to run. While a Mac installer might be nice, it's really not hard to "unzip" and then "bin/startup.sh" on Mac. I'd argue that about Windows, but I recently did some consulting with a company full of Windows administrators and when I dropped to the command-line to "get some real work done" (my words to them), they all got a panicked expression on their faces. I guess without a point-and-click interface, some folks are just lost. >> So, that's not all that complicated when you think about it, but >> to ask someone who knows nothing about a command-line, working >> effectively in an operating system, etc. and only knows about >> programming in Java -- maybe only servlet programming in Java -- >> to configure the server in the split case is confusing as all >> hell. > > > +1 > >> Anyone downloading a ZIP or tar archive containing a Tomcat >> installation would be confused if the archive contained not one >> but two top-level directories. Also, it would overwrite your >> split-configuration if you unpacked that archive in the same >> directory as when you first started. > >> An installer program would have to explain what in the world the >> split configuration was. Have you ever tried to tell someone how >> to set up their email? POP versus IMAP? Most users have >> absolutely no idea what that is, and mail programs give no clue >> as to which one to choose. The same would be true of >> CATALINA_HOME versus CATALINA_BASE. (Besides, I truly doubt that >> any expert system administrators are using the Tomcat Windows >> Installer to install/upgrade their systems. Maybe I'm wrong, but >> then again I can't imagine running a Windows server in >> production. I value my sleep and prefer to build new things >> instead of holding together configurations with chewing gum and >> duct tape. Oh, and rebooting all the time.) > > > I (sadly) run a few Windows servers in production. I've not tried > CATALINA_HOME / CATALINA_BASE in conjunction with the service > install, since those systems are quite static. However, even > updating Java on those systems is a bit of a pain. Can Windows do parallel versions of Java anymore? You used to be able to do it, and then people ended up with every patch version of Java between 1.6.0 and 1.6.55 installed side-by-side and that caused some irritation. Then the Java installer started deleting the old versions that were installed, which of course will break anything that doesn't "search" for the currently installed (or updated) Java version. It looks like Apple got the Java deployment strategy right: install whatever you want and have a utility that knows where to find JVMs that match certain criteria. > Rebooting is also not nice for reliability / availability numbers. (I just meant that rebooting is evidently a way of life for Windows admins. Everyone I know that admins anything other than a desktop system seems to have to reboot either weekly or nightly just to keep things running without weird stuff "happening". Our *NIX servers run for months or years without being rebooted. Only upgrading the kernel really requires a reboot.) >> Anyhow, we can debate this all you want, but I will be -0 or >> even -1 to a default split-configuration of Tomcat unless someone >> has a really good idea for how to make it make sense to anyone on >> their first-touch. > > If I was a voting member, I would definitely be -1 for this change. > It makes the default use case (get up and running quickly) much > more difficult, and provides no advantage for those people who do > make use of CATALINA_HOME / CATALINA_BASE. > > Maybe a step-by-step Wiki article is in order. I've often thought that burying the split-configuration in RUNNING.txt was not a great strategy. It's nice to have it *in* the downloadable package, but having it online (with hyperlinks, in-depth discussion of the hows and whys, etc.) would be great, too. The problem is with documentation getting out of sync. Someone updates the RUNNING.txt file but not the web site or vice-versa. Yes, there's some oversight from other committers and members of the community, but everyone is a volunteer and sometimes we're not all paying close attention. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUWAfLAAoJEBzwKT+lPKRY7nQQAJRNmv/8oK2qBahwUOaS0xBF IFkYKl8ftdNVc+XRG914KV6M+SfOu6gQB2yaqS2S4wCoE9sSnTVbbAxkmhP2vVZG RTaCFnc7ZPawhiRolMCPRycPipc/2Bgl5RkhMDVmEJ4ntg1LL3YKseqSBQabtPWS /LiRgd53RsQxbboqC9BYgCMiQ/wIEofz7vopPdVvBxkjLI5kvZ7PqoqXcdKkF2RY bpiu+fb8CaC0kdkZPZrsOhUwlce/MzhsTs7xKgco3EKwNJfBefw7/cZZiWidoZqh 2ENzafG76ySxmwLx3xEqXmGrO8vKEh2qB8u7BTu+C7EtNwF7T5rX+1WDywlnhq/R fioC0GVneGagjfG0NQ49T7tueI6bo8l6UdG52JByx3BAkcAcYmFR1J4XTlcfxdoG uA6rEe2Rk4iIcRKEMVK5xwmqFQLrmqUvoB2JTW2t10F4BrglPP8UZVA9GudJ7NgQ dVzhz1s30Xs3qqJgj1kAJxhpmwlydZ+7nQkNU9VsledGT5cpZBks7HJtbNv+ZdsQ jey0vtIMven+gjt7qqaUXF7XBZDfP7NxTWD1jq/FsG9Z9rMKkz6gvDLcf4JWpo+a 4VrsOU4w1X+6uLHZscp0BhavuBlfydj43uwoXG/06MtlndcgvR1pNflMztt3sI8n BItN1OnqxXIcumXr/cWq =4Weg -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
