Re: Hiding :8080 port in URL

[BuildSmart]

On Oct 19, 2007, at 15:10:10, Christopher Schultz wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

BS,

BuildSmart wrote:

Use mod_jk to resolve this, also, if you want to try a module that is
specific to ajp13, I created the following
mod_ajp13 (http://amavis-stats.com/downloads/mod_ajp13.tar.gz - with

contains the ajp13 related code so I can write a new module that will

in the Tomcat document roots so that configuration only requires
configuring apache virtualhosts.

load balance support), it's basically a stripped down mod_jk that only allow the integration to apache for virtualhosts so that the pages can be served by apache from the virtualhost document roots and not stored

size of the shared library. Is that really useful?

What is this all about? I think the only thing you've done is reduce the

Let me try again.

Yes, for the purpose of my project I then added a native debug interface and significant amount of debugging features so that I could walk an entire transaction from start to finish and see what's going on and to change the expected behavior my modification of the transaction and the environment variables. It is my intention with the help of this module to create a new module that will allow execution from the apache document root rather than deployed from within Tomcat. I have another version that doesn't use the workers.properties file and a modified Ajp13Servlet class to allow serving the scripts from apache 1.3.33 virtualhost document roots and it does work with basic scripts that I have been testing with which brings me to the point where I am no longer serving the pages from within Tomcat, only making the deployment environment native to apache. What I have so far is the following, a smithcf-1.3b4.war in Tomcat 4.1, apache serving java and coldfusion scripts from the apache virtualhost document roots but using the war to compile and process the scripts as if they were native to the war by environment modification. The advantage here is that I don't have to define additional roots per virtualhosts or do proxy work whenever I add/modify/remove an apache virtualhost, I don't have to do anything with Tomcat other than deploy my war and then configure apache as needed. If you can't see the advantages here try adding 100 apache virtualhosts and give them each an index.jsp file in the apache virtualhost document root which are all different physical locations and each has different content (but all are named index.jsp), create only one virtualhost in Tomcat and the deployed war does not have any scripts, start Tomcat and apache, process the index.jsp scripts per virtualhost if you can (all on port 80). In my war, I have an index.jsp that outputs "Welcome to my engine" and does nothing else, it's never executed from apache, every apache virtualhost has in it's document root an index.jsp file that is specific/unique to it's virtualhost and it's processed as if it was in the war and I'm not using mod_rewrite or mod_proxy or any weird stuff in the war. It's kinda like enabling php in apache 1.3.33, I can add my .jsp and .cfm scripts to the virtualhost document roots and they work just like adding .php scripts. Actually, I haven't done anything special to the Tomcat configuration except to enable ajp13 on localhost only on port 8079 and for it to listen on localhost only on port 9079 and the war never physically sees any of the scripts. Currently I've dropped Tomcat to work with jetty 6.1.5 without any special modification aside from adding a custom jar file with my extra servlet classes in attempt to achieve the same results so that my module will work with any deployment method by the inclusion of these additional classes. Actually I'm finding that jetty is much easier to work with than Tomcat from a deployment standpoint but that's only because it's a simple to configure server. When I get it refined enough to offer a public release I'll post something to this list since I know that others would like to achieve the same results of configuring Tomcat for one virtualhost and forget it (so you can gain access to the deployment environment) and then they only have to work with the apache virtualhosts and the scripts reside within the apache virtualhosts making deployment that much cleaner and easier to manage.

- -chris

-- Dale

PGP.sig
Description: This is a digitally signed message part