Re: Hiding :8080 port in URL [attention mod_jk devs]

[BuildSmart]

On Oct 19, 2007, at 17:05:58, Christopher Schultz wrote:

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

Dale,

BuildSmart wrote:

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

environment variables.

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

Did you modify the native mod_jk module for Apache httpd or did you
modify the Java-based connector in Tomcat?

I use a the same unmodified connector but I have an additional class that add/extends functionality, the module passes all the environment variables (whether the script uses them or not) so that I can get the DOCUMENT_ROOT and swap it for the docroot, then process the script which Tomcat believes is in it's document root.

folks?

If the former, would you care to share some of your work with the mod_jk

As I said, when I'm done I'll be happy to release a package, the mod_jk group can pick through the code and borrow whatever they like or they can just use my module instead of hacking theirs. The end package might not be ajp13 compliant/compatible and I wont know until I have the end product but we'll see how it goes.

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'm not sure I get it... you want to run Tomcat from inside Apache's
DocumentRoot? What's stopping you from doing that, now (aside from the
fact that it's not a very good idea)?

I have another version that doesn't use the workers.properties file

to set up everything if you wish.

workers.properties is not necessary with mod_jk: you can use directives

and

1.3.33 virtualhost document roots and it does work with basic scripts

environment native to apache.

a modified Ajp13Servlet class to allow serving the scripts from apache 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

I think I still don't get it. What scripts are you talking about? JSPs?

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.

handles PHP pages by handing-off processing to the php binary.
Interesting. Sort of a "mod_java". How do you handle JSPs that require
support libraries? Or those that use includes?

Aah... you are using Tomcat in the same way that mod_php (for instance)

The process works in the same way that php does, when a file is included it is loaded from the apache document root (because I modify the docroot) so it's not an issue. In my WAR I have the smithcf engine and it appears to process those scripts in the same manner and the includes is working with those as well. Basically I wanna do what mod_jrun and Adobe CF or mod_servletexec and BlueDragon does with Smith CF (a free CF engine) but both bod_jrun and mod_servletexec aren't free to use in a production environment and I couldn't find any free software that achieves this task hence my project. While I started with a modified mod_jk, I'm also looking at the older mod_jserv as a possible alternative if I can achieve the same results without having to do any special classes to make it work then I might look at utilizing it.

It's kinda like enabling php in apache 1.3.33, I can add my .jsp and

adding .php scripts.

.cfm scripts to the virtualhost document roots and they work just like

or if you want to run servlets. Perhaps you don't care about those
situations (because you can always use full-blown Tomcat with webapps,
etc.).

I think you might run into problems when the JSPs require more support,

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

any of the scripts.

listen on localhost only on port 9079 and the war never physically sees

code deployed in the WAR file processes the scripts? I would imagine
that you'd have to load and process the scripts in order to evaluate
them and produce content...

Do you mean that the WAR file does not /contain/ any scripts, or that no

The WAR contains the smithcf engine and the administration interface (as an embedded servlet) and a helloworld.jsp and helloworld.cfm script but no other script content, the engine loads and processes the scripts based on the URI but instead of grabbing the scripts from the Tomcat document root it changes the document root to the apache document root for the virtualhost executing the URI.

Currently I've dropped Tomcat to work with jetty 6.1.5 without any

will work with any deployment method by the inclusion of these
additional classes.

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

Jetty might actually offer a better target because (last I checked,

so you can save yourself a lot of complexity: you get a leaner, meaner
script processing machine.

don't flame me if I'm wrong) Jetty only supports one deployed webapp per instance, and you don't need the ability to deploy more than one webapp,

I believe (starting with) jetty 6.1.5 supports contexts so multiple webapps can be deployed.

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

forget it (so you can gain access to the deployment environment) and

reside within the apache virtualhosts making deployment that much
cleaner and easier to manage.

achieve the same results of configuring Tomcat for one virtualhost and then they only have to work with the apache virtualhosts and the scripts

Interesting.

- -chris

-- Dale

I'm looking for an easy to implement solution where I don't have to configure anything more than apache virtual hosts to achieve a useable solution. I'll be the first to admit that I know next to nothing about configuring mod_jk and Tomcat but if I have 1000 apache virtual hosts I certainly don't want to have to configure Tomcat for every one of them. I'm also not the greatest java programmer (most of what I have java related has been done with the help of a friend who's much better than I), I use snoop.jsp and a self-written snooper.jsp to tell me stuff but even then I can't see all of the variables that apply to what I'm doing (cause I don't have a cheat sheet that tells what calls will give me the info I want to see). Now, someone else says my concept can be implemented strictly by a class file that scans apache config files and changes the docroot with the apache DOCUMENT_ROOT based on the virtualhost being accessed but I couldn't figure this out myself and the person who claims it's possible states it's a tried and tested POC but couldn't offer any evidence to back the claim. In any event, I should have something publicly releasable before the end of the year.

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