URL and mod_jk
Hi guys, in my project, I very often use absolute url. They have a form like: http://domain/foo/bar/resources/org.apache.wicket.Application//path/to/my/file.png I recently installed Apache and mod_jk. Are this kind of url valid to be served through mod_jk? Because it explicitly reference wicket (web framwork), and I've guesssed that the request will be forwarded from mod_jk to tomcat, and then to wicket... How can I see what is being served by mod_jk and what by tomcat? Any mod_jk log somewhere? thank you - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL and mod_jk
Piller Sébastien wrote: Hi guys, in my project, I very often use absolute url. They have a form like: http://domain/foo/bar/resources/org.apache.wicket.Application//path/to/my/file.png I recently installed Apache and mod_jk. Are this kind of url valid to be served through mod_jk? Because it explicitly reference wicket (web framwork), and I've guesssed that the request will be forwarded from mod_jk to tomcat, and then to wicket... How can I see what is being served by mod_jk and what by tomcat? Any mod_jk log somewhere? See: JkLogFile Just to see what serves what: configure an access log for httpd and for Tomcat. If you want to get all the details on a test system: JkLogLevel debug. Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hiding :8080 port in URL [attention mod_jk devs]
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
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
