You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2007/10/19 23:05:58 UTC
Re: Hiding :8080 port in URL [attention mod_jk devs]
-----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
> 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.
Did you modify the native mod_jk module for Apache httpd or did you
modify the Java-based connector in Tomcat?
If the former, would you care to share some of your work with the mod_jk
folks?
> 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
workers.properties is not necessary with mod_jk: you can use directives
to set up everything if you wish.
> 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.
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.
Aah... you are using Tomcat in the same way that mod_php (for instance)
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?
> 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.
I think you might run into problems when the JSPs require more support,
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.).
> 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.
Do you mean that the WAR file does not /contain/ any scripts, or that no
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...
> 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.
Jetty might actually offer a better target because (last I checked,
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,
so you can save yourself a lot of complexity: you get a leaner, meaner
script processing machine.
> 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.
Interesting.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHGRw29CaO5/Lv0PARAhMTAJ9oxN1z09uBFmJ+5Ukb3pBprwwj6gCdFMQJ
ArbvG2jww1Dav9lCyFVQntc=
=VYBX
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: removing :xxxx port requirement in URL [update]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dale,
BuildSmart wrote:
> It looks like my current solution only works with Tomcat 4.1 (I didn't
> try anything older).
>
> I'm wondering how to resolve this, I doubt they'd make changes in the
> source to allow the ability to modify the docroot without affecting
> other directory designations because I need it for my module.
Maybe they would. Feel free to start another thread (I don't think
anyone else is reading this one anymore) asking that question (maybe
even on the dev list instead of the user list). Another option is to
file a bug report (enhancement request) that asks for a way to do what
you need to do.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHH0pC9CaO5/Lv0PARAgiUAJ9bHq8a1ZBtl6a18c1c8gdqPTCxUACfXuZd
l+jKiGw06W40nmBkw7Ekvnw=
=sJB4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: removing :xxxx port requirement in URL [update]
Posted by BuildSmart <bu...@daleenterprise.com>.
I was beginning to be happy with the results of my work and was
enjoying the ability to have apache serve the .jsp files from any of
it's virtualhost document roots and not the Tomcat docroot and only
having one Tomcat virtualhost defined allowed me to design an admin
interface on the defined Tomcat port.
I was thinking it was time to start planning out a release package
when I decided to try using Tomcat 5 instead of Tomcat 4 (which is
vendor supplied) and I'm disappointed to find out that the changes in
the class files have combined the docroot, work and scratch dir
variable initialization so changing docroot dynamically on the fly
doesn't work cause it then complains about no WEB-INF and no work dir
and exits with a 500 error msg.
I thought to be safe I'd try Tomcat 6 (forced me to use JSDK 1.5) and
it exhibits the same issue.
It looks like my current solution only works with Tomcat 4.1 (I
didn't try anything older).
I'm wondering how to resolve this, I doubt they'd make changes in the
source to allow the ability to modify the docroot without affecting
other directory designations because I need it for my module.
Maybe using Tomcat was a poor choice based on the current available
config state or maybe there is another method in the newer Tomcat's
to achieve the docroot change without disrupting the others or maybe
I should consider dropping it as a possible method of implementation?
-- Dale
Re: Hiding :8080 port in URL [attention mod_jk devs]
Posted by BuildSmart <bu...@daleenterprise.com>.
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
>> 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.
>
> 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.
>
> If the former, would you care to share some of your work with the
> mod_jk
> folks?
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
>
> workers.properties is not necessary with mod_jk: you can use
> directives
> to set up everything if you wish.
>
>> 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.
>
> 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.
>
> Aah... you are using Tomcat in the same way that mod_php (for
> instance)
> 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?
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
>> .cfm scripts to the virtualhost document roots and they work just
>> like
>> adding .php scripts.
>
> I think you might run into problems when the JSPs require more
> support,
> 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.).
>
>> 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.
>
> Do you mean that the WAR file does not /contain/ any scripts, or
> that no
> 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...
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
>> 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.
>
> Jetty might actually offer a better target because (last I checked,
> 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,
> so you can save yourself a lot of complexity: you get a leaner, meaner
> script processing machine.
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
>> 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.
>
> Interesting.
>
> - -chris
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.
-- Dale