I agree that mod_jk is easy to maintain but that initial build / install is way too painful
and I think, IMHO, is due to an organizational issue. Having just gone through this
here are my thoughts.
Bring native/native2 as a top level directory. When I did a google search to find install
notes from other people, they all start out be telling you to cd to the native2 directory.
Having unnecessary directory levels adds just a little to the confusion, but sometimes
its the little things that can tip the cup. Maintianing a standard directory structure such
as src / build would also help. It took me a while to find out that the module I compiled
in native2 was in the build directory in the parent.
On this same thought, there are multiple copies of build.properties on the different
levels. I assume you only need to edit the property file where you are starting the
build from and it will propagate during the build. I'm still confused on that one.
In build.properties, stay away from using environment variables unless they are commented
very well. It is much simpler to edit one file and run a build script. More users than not probably
rely on the fact that tomcat will figure out where tomcat home is while the build script won't. Also
I think that the full directory path stands out better as an "Edit Me" item.
Put the bin directory back in (with ant.jar) and the build.sh / build.bat files. Not every installation
will have Java and ANT installed in a ready to use on a global basis form. All java projects should
assume that only the JDK is installed.
Since the documentation on mod_jk2 is not necessarily up to date, it would of been nice to keep
the mod_jk configuration interfaces so that examples in already published books would still work.
My casual glance at the source seems to indicated that the old and new could be both added.
If the old interface was used, emit a deprecated message in the log.
Regards John G
Shapira, Yoav wrote:
Hi,
FYI, mod_proxy is being very actively developed and enhanced at the moment, to address some of these concerns. There's no time decided yet for its next release, but I imagine it's not far away.
Yoav Shapira Millennium Research Informatics
-----Original Message-----
From: Endre St�lsvik [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 09, 2004 5:22 AM
To: Tomcat Users List
Subject: RE: Why is Tomcat/Connector Installation So Incredibly Painful??
|
| Well, that's subjective, so I won't argue. I find it not only elegant,
| but far better than one thread pool for the whole server, but it's a
| matter of stylistic preference. I'm glad you found a good solution that
| works for you, and as I said before your other argument about the
| server-side redirects is strong and convincing.
As you already have to convince Apache of which server it is, it is just a
matter of stating to your connector which server it is, too (you can
override the connector's assumptions in your connector-definition,
right?).
Well, for me both arguments are just as convincing. I will probably
stick with mod_jk, even though I always cringe when thinking about the
next installation of any such installation.
It would, however, be great if mod_proxy was extended with some features
that made it "compatible" with Tomcat's requirements - so that both these
arguments vanished. These features would probably be great for many proxy
environments, in particular where the back-end system also is active.
Endre
---------------------------------------------------------------------
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
