RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c
On Sun, 21 Jul 2002, Mladen Turk wrote: All that I'm trying is to skip the need to use the Apache machanism for the uri-space-file-space translation. If the TC says that _its_ uri-space can be translated to the file-space only than map_to_storage can provide the real finfo and serve the static context. What I'm trying to say: - if you don't serve static files with apache - there is no problem, anything goes to tomcat ( dirs, etc ). - if you do serve static files with apache, then you need to use _both_ file info and mappings to deal with directories. Or just forward the directory to tomcat as a simple solution. You need file info for the static files ( if index.html is found, it must be used ) and mappings for dynamic files ( /examples/index.jsp may be mapped with a servlet mapping to a generated index$jsp.class - and the file itself doesn't exists ). Look how the mod_proxy is implemented. All the mapping is done through mod_proxy directives, as in our case through workers2.properties I think we shouldn't allow that mod_dir provides the default context using dir walking even for a situation where the tc's uri-space can be translated to the local file system. The TC should decide in that case what to do with a such request. Whether it will serve the index.jsp or something else its up to it thought. That's one solution - i.e. let tomcat handle directories. It's the simplest solution. Given that tomcat will issue a redirect, apache will still serve index.html as static file. If you want to see the directory list served by apache - then you can't avoid using both finfo and mappings, that's what the servlet spec requires. The directory browsing in either case should go through TC and not through mod_autoindex. I don't agree - while it is easier to go through TC, it is also a valid solution to let apache serve the file. But mod_autoindex won't work corectly - because servlet spec requires a different behavior for 'dirs' than what all web servers do. That's unfortunate - but we can't change it. Short term - I would vote for passing dirs to TC, long term or if someone really have the time we should let apache do it. ( same is true for IIS, NES, etc ). Costin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Sunday, July 21, 2002 5:47 PM To: Tomcat Developers List Subject: RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c On Sun, 21 Jul 2002, Mladen Turk wrote: We have a two situations, with the TC on the same box as apache, and on the remote one. Well, that is only the partially correct, cause the load balancing brakes that. Actually, I think we have 2 situations: - one if the webapp files are on the apache server file and jk is configured to let apache serve static files. The app may be load balanced and all dynamic resources ( including index.jsp ) will be served by one or more tomcats ( and you don't even need to run tomcat on the apache server - just to have the static files ). - if you don't keep the static files on the apache server, or you don't use apache for static files - the problem is trivial, you just forward everthing to tomat anyway. In the first case, there are 2 possible solutions: - for directories, just forward to tomcat. That's simple. - if you want apache to serve the dir, you must implement what the servlet spec requires: take the list of index files and check if any can be found. That involves both static and dynamic resources. If no index file or dynamic resource is found - apache can display the dir. If an index file is found - and is static, apache can display it. If index.jsp is found ( or another dynamic one ) - tomcat will handle it using the normal lb. Costin So what we have is the following for example /someapp/ --/somelocation1/someapp/ --/somelocation2/someapp/ --10.0.0.1/someapp/ --10.0.0.2/someapp/ ...etc Basically this is something like a reverse proxy situation. All that has to be mapped inside the apache's directory tree at the /opt/apache2 but can go to the any physical location above, or any virtual one. You can serve the static mime-type context only from the first two cases. The Load balancer have no idea about the fact where the app is located (local or remote), so the .gif will get served according to the lb state, not its potential context performance, but that is another story. Your patches brakes the entire lb concept, and that is the reason that I don't like it. Its not the problem with the static context (probably it's a performance gain), but the default index.jsp will get served only from the local TC no matter what the lb thinks about that. He may mark the 10.0.0.2 as a active env, and you will map that to a local
RE: cvs commit:jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c
I think I understand what you're trying to say and I wouldn't like to introduce a piece of code that fixes one thing and breaks a bunch of them (load balancing, virtual serving etc.). Let me submit this analysis. The static, local (to Apache) copy of index.jsp (or whatever other file) will get picked up (i.e. its existence will be recognised by mod_dir) only if: - it actually exists (otherwise r-finfo.filetype will be 0) - DirectoryIndex is set to pick the file up So, if you have a load balancing scenario or virtual serving, don't use DirectoryIndex and/or don't put files in you local file system, but use other mechanisms (precompiled JSP's or let Tomcat pick the default file up) for that. It is unrealistic to expect from Apache to pick up virtual files, invisible to it from within the file system. And since it's Apache that's doing mod_dir here, I don't think that we should go very far into virtual land. One other thing also. In the actual code, the file to be picked up is now set as an absolute file name. However, if I do this at the end of jk_map_to_storage(): -- r-filename = (char *)apr_filename_of_pathname(r-uri); -- (i.e. make the file what it used to be, just make r-finfo.filetype = 1), the whole thing still works (minus the aliases, which is just a plain bug). So, jk_handler() is making its own choice about what file (physical or virtual) is going to get served, it doesn't rely on info in r-filename at all. The only difference is that mod_dir gets that 1 set in jk_map_to_storage() (done in the 'what if' sub request of mod_dir) and then engages a real request a bit earlier. This is a request with handler type jakarta-servlet and goes through mod_jk again. So, I'm not sure that things would get broken anyway. But, it's a possibility, in which case just don't use DirectoryIndex, since it doesn't make sense anyway. The old code (in mod_jk for Apache2 and mod_jk2 for Apache2) breaks DirectoryIndex as compared to Apache 1.3.x and mod_jk 1.x. We can make a few choices here: - fix aliasing in the patch and explain to people how it really works - let the patch into mod_jk 1.2.0, but not 2.x - kick the patch out of both - kick the patch out of both and change how 1.3.x/1.x combo works too and then let people know about it I can live with any of the above since I fully control my own environment and can adjust accordingly. Bojan On Sun, 2002-07-21 at 21:20, Mladen Turk wrote: Just to prove the concept put the following in your workers2.properties [uri:/*.jsp] info=Extension mapping And then try your patches. We are obviously having some concept misunderstanding. I don't say that I'm happy with the current implementation of mod_jk2 and how it deals with the rewriting, but I think we shouldn't try to clarify that a bit. The problem is far more complex then it may look. We have a two situations, with the TC on the same box as apache, and on the remote one. Well, that is only the partially correct, cause the load balancing brakes that. So what we have is the following for example /someapp/ --/somelocation1/someapp/ --/somelocation2/someapp/ --10.0.0.1/someapp/ --10.0.0.2/someapp/ ...etc Basically this is something like a reverse proxy situation. All that has to be mapped inside the apache's directory tree at the /opt/apache2 but can go to the any physical location above, or any virtual one. You can serve the static mime-type context only from the first two cases. The Load balancer have no idea about the fact where the app is located (local or remote), so the .gif will get served according to the lb state, not its potential context performance, but that is another story. Your patches brakes the entire lb concept, and that is the reason that I don't like it. Its not the problem with the static context (probably it's a performance gain), but the default index.jsp will get served only from the local TC no matter what the lb thinks about that. He may mark the 10.0.0.2 as a active env, and you will map that to a local /somelocation1. What we need IMO is that lb informs the map_to_storage whether we are serving local or remote, so that we don't force the local context all the time if present. I mentioned in the previous e-mails that aliases have not been covered with this patch at all (that's why Mark's having problems with them). They would have to be dealt with as well. As I said (perhaps I'm totally wrong) you shouldn't suppose that the context is inside the local file system. It has nothing to do with the static context serving, and you don't have enough info to decide where the context is situated. My suggestion are: 1. Let see how can we get the info whether the context is from local or remote storage (and then use the map_to_storage accordingly) 2. Let the TC decide what the default served file will be for a particular uri (Dropping the entire
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c
On Mon, 2002-07-22 at 01:39, [EMAIL PROTECTED] wrote: I think Mladen chose the wrong example, but he is right. Think about the case when pre-compiled JSPs are used. In this case index.jsp is converted to a servlet - in the deployed application there is no 'index.jsp' file, just a servlet and a mapping for /index.jsp to the generated servlet. If there is no physical file, then nothing will get done by the patch at all (since r-finfo.filetype is 0). It won't affect mod_dir's old behaviour at all. I'm not sure how that changes things... This is another mismatch between the servlet spec and the common practice on all web servers. DirectoryIndex works with files for all servers that I know. The servlet spec extends the concept - and tries to decouple itself from the file system. I don't think it is easy ( or possible ?) with the current spec to get Apache to serve dirs. At least it won't work with using only file system info. I guess I was aiming at this: - if all files are physical and local, then mod_dir and DirectoryIndex are fine and make sense - if all files are not physical and local, mod_dir and DirectoryIndex don't make sense and should not be used Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit:jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c
On Mon, 2002-07-22 at 04:14, Mladen Turk wrote: All that I'm trying is to skip the need to use the Apache machanism for the uri-space-file-space translation. What are the benefits of having Apache if you don't use it for all you can (in cases where you can)? I view Apache/Tomcat combo as a single web application server and I want each part to do what they can do best. From my own performance benchmarks, I can tell that it takes Tomcat significantly longer to do anything as compared to Apache. Which should not be view as a fault of Tomcat at all. Tomcat provides comfort for application development, but that should be used only when it's really needed. If the TC says that _its_ uri-space can be translated to the file-space only than map_to_storage can provide the real finfo and serve the static context. Look how the mod_proxy is implemented. All the mapping is done through mod_proxy directives, as in our case through workers2.properties I think we shouldn't allow that mod_dir provides the default context using dir walking even for a situation where the tc's uri-space can be translated to the local file system. The TC should decide in that case what to do with a such request. Whether it will serve the index.jsp or something else its up to it thought. I think I understand a bit better where you're coming from. I have things like this in my jk.conf: -- JkMount /*.jsp ajp13 JkMount /*.vm ajp13 -- Which makes only files with *.jsp and *.vm extensions Tomcat's URI space. So, it is Apache that decides first what should go to Tomcat at all, and to do that it uses it's own machinery (i.e. DirectoryIndex). What Tomcat then does with that URI is its own business. Imagine a load balancing scenario where Apache/Tomcat pairs are clustered and all files a local. All of the above would still make perfect sense. The directory browsing in either case should go through TC and not through mod_autoindex. Again, I'm not sure why would that be a must for all cases. I don't want Java engaged if C does can do the job and faster. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
bojan 2002/07/21 15:34:25
Modified:jk/native/apache-2.0 mod_jk.c
Log:
Instead of mixing URI's with filenames, which was wrong, just use filenames to stat.
This will also take care of aliases, but be warned - URI will still be passed to
Tomcat unchanged.
Revision ChangesPath
1.50 +25 -14jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.49
retrieving revision 1.50
diff -u -r1.49 -r1.50
--- mod_jk.c 21 Jul 2002 06:50:02 - 1.49
+++ mod_jk.c 21 Jul 2002 22:34:25 - 1.50
@@ -1618,24 +1618,35 @@
static int jk_map_to_storage(request_rec *r)
{
if (apr_table_get(r-notes, JK_WORKER_ID)) {
-char *uri_p=r-uri;
-/* This is old code which doesn't seem to work well with mod_dir
-r-filename = (char *)apr_filename_of_pathname(r-uri); */
+/* First find just the name of the file, no directory */
+r-filename = (char *)apr_filename_of_pathname(r-uri);
-/* Absolute paths cannot be merged */
-while (*uri_p == '/') ++uri_p;
+/* Ony if valid sub-request, most likely from mod_dir */
+if (r-main r-main-filename *r-main-filename){
-/* Need absolute path to stat */
-if (apr_filepath_merge(r-filename, ap_document_root(r), uri_p,
- APR_FILEPATH_SECUREROOT | APR_FILEPATH_TRUENAME,
- r-pool)
-!= APR_SUCCESS){
- return DECLINED;
-}
+/* The filename from the main request will be set to what should
+ * be picked up, aliases included. Tomcat will need to know about
+ * those aliases or things won't work for them. Normal files should
+ * be fine. */
+
+/* Need absolute path to stat */
+if (r-main-filename[strlen(r-main-filename)-1] == '/'){
+if (apr_filepath_merge(r-filename,
+ r-main-filename, r-filename,
+ APR_FILEPATH_SECUREROOT |
+ APR_FILEPATH_TRUENAME,
+ r-pool)
+!= APR_SUCCESS){
+ return DECLINED;
+}
+} else {
+r-filename = apr_pstrdup(r-pool, r-main-filename);
+}
-/* Stat the file so that mod_dir knows it's there */
-apr_stat(r-finfo, r-filename, APR_FINFO_TYPE, r-pool);
+/* Stat the file so that mod_dir knows it's there */
+apr_stat(r-finfo, r-filename, APR_FINFO_TYPE, r-pool);
+}
return OK;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c
I have reworked the code to take care of aliases (i.e. to use what Apache already knows about them from the main request). Please note that URI will be left unchanged, so unless Tomcat knows about the aliases as well, nothing will get served. I will not commit the change to mod_jk2 since there are major objections to the code in the first place. Please consider this as just an attempt to correct the brain dead code that involved DocumentRoot, rather then actual file location and mixing URI's with filenames, nothing more. Bojan On Mon, 2002-07-22 at 08:34, [EMAIL PROTECTED] wrote: bojan 2002/07/21 15:34:25 Modified:jk/native/apache-2.0 mod_jk.c -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10789] - Setting DirectoryIndex of index.jsp does not get served by jk2
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10789. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10789 Setting DirectoryIndex of index.jsp does not get served by jk2 --- Additional Comments From [EMAIL PROTECTED] 2002-07-21 22:49 --- Mark, I have made some changes to mod_jk, not mod_jk2. You might want to take those changes and try them with your aliases. Please note that URI will be left unchanged, so your instance of Tomcat needs to know about it. The alias processing only covers files on the file system, it doesn't involve changing the URI's. I won't commit anything to mod_jk2 since there have been major objections from other commiters about the code. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c
On 22 Jul 2002, Bojan Smojver wrote: If there is no physical file, then nothing will get done by the patch at all (since r-finfo.filetype is 0). It won't affect mod_dir's old behaviour at all. I'm not sure how that changes things... My question was: if you have a precompiled index.jsp, there will be no file - only a servlet-map with uri=/index.jsp and the servlet name. DirectoryIndex will not find index.jsp, and will assume there is no index - and serve the dir. Which is wrong. The indexes as defined by the servlet spec may be real files or virtual (mapped) resources. I guess I was aiming at this: - if all files are physical and local, then mod_dir and DirectoryIndex are fine and make sense If you can make sure that all paths are checked for both static and mapped resources - yes, you can use mod_dir. - if all files are not physical and local, mod_dir and DirectoryIndex don't make sense and should not be used I don't think this is an issue we should discuss - this case is already solved, if no files on the apache machine there is nothing we can do but forward. The lb case is also not an issue - if there are local static files, apache can serve them - and dynamic resources are handled by tomcat lb. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
Quoting [EMAIL PROTECTED]: On 22 Jul 2002, Bojan Smojver wrote: If there is no physical file, then nothing will get done by the patch at all (since r-finfo.filetype is 0). It won't affect mod_dir's old behaviour at all. I'm not sure how that changes things... My question was: if you have a precompiled index.jsp, there will be no file - only a servlet-map with uri=/index.jsp and the servlet name. DirectoryIndex will not find index.jsp, and will assume there is no index - and serve the dir. Which is wrong. Which is how it used to be in the old code anyway. And that means that DirectoryIndex should not be used if you don't have physical files in the right places (with the current patch level in mod_jk 1.2.x for Apache 2) or in virtual places (with the future code, that you're proposing, which will be capable of asking TC about such files). The indexes as defined by the servlet spec may be real files or virtual (mapped) resources. I guess I was aiming at this: - if all files are physical and local, then mod_dir and DirectoryIndex are fine and make sense If you can make sure that all paths are checked for both static and mapped resources - yes, you can use mod_dir. OK, if you want to write something along those lines, I have no problems with that. It's best of both worlds in that case. I'm guessing that you'd have to ask TC if there are files out there that match, right? Because this is not a real request (not in jk_map_to_storage() anyway), but 'what if', jk_handler() doesn't get called, so it would have to be done in some other way. - if all files are not physical and local, mod_dir and DirectoryIndex don't make sense and should not be used I don't think this is an issue we should discuss - this case is already solved, if no files on the apache machine there is nothing we can do but forward. The lb case is also not an issue - if there are local static files, apache can serve them - and dynamic resources are handled by tomcat lb. That sounds good to me. Bojan PS. Note that mod_jk 1.2.0 doesn't use DocumentRoot as the base for the request any more (that was clearly a bug). I fixed that this morning. I have not done any changes to mod_jk2. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c
On Mon, 22 Jul 2002, Bojan Smojver wrote: Which is how it used to be in the old code anyway. And that means that DirectoryIndex should not be used if you don't have physical files in the right places (with the current patch level in mod_jk 1.2.x for Apache 2) or in virtual places (with the future code, that you're proposing, which will be capable of asking TC about such files). I think DirectoryIndex shouldn't be used until we get the right code to deal with both static and mapped resources. I'm not saying the old code is right - it obviously isn't. OK, if you want to write something along those lines, I have no problems with that. It's best of both worlds in that case. I'm guessing that you'd have to ask TC if there are files out there that match, right? Because this is not a real request (not in jk_map_to_storage() anyway), but 'what if', jk_handler() doesn't get called, so it would have to be done in some other way. First, I don't think this will be written in the short term, it's quite difficult. You don't need to ask tomcat - jk should have all the mappings, and it can already map any URI. All it has to do is: - for each index: -- concatenate with the current uri -- do the jk mapping ( or internal redirect if you use Location instead of the internal mapper ). If a match is found - forward to tomcat. -- check if a file exists. If yes - serve it as static ( since we already checked all servlet mappings ). - if no match is found, use mod_dir to display the directory. But in the short term, I think we should just let tomcat deal with that, until we have the fix. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
Quoting [EMAIL PROTECTED]: You don't need to ask tomcat - jk should have all the mappings, and it can already map any URI. All it has to do is: - for each index: -- concatenate with the current uri -- do the jk mapping ( or internal redirect if you use Location instead of the internal mapper ). If a match is found - forward to tomcat. -- check if a file exists. If yes - serve it as static ( since we already checked all servlet mappings ). - if no match is found, use mod_dir to display the directory. But in the short term, I think we should just let tomcat deal with that, until we have the fix. Are you referring here to mod_jk2 only or both mod_jk 1.2.0 and mod_jk2? Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
bojan 2002/07/21 19:48:11
Modified:jk/native/apache-2.0 mod_jk.c
Log:
Be a bit more specific about what is a directory.
Revision ChangesPath
1.51 +10 -13jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.50
retrieving revision 1.51
diff -u -r1.50 -r1.51
--- mod_jk.c 21 Jul 2002 22:34:25 - 1.50
+++ mod_jk.c 22 Jul 2002 02:48:11 - 1.51
@@ -1622,8 +1622,9 @@
/* First find just the name of the file, no directory */
r-filename = (char *)apr_filename_of_pathname(r-uri);
-/* Ony if valid sub-request, most likely from mod_dir */
-if (r-main r-main-filename *r-main-filename){
+/* Ony if sub-request for a directory, most likely from mod_dir */
+if (r-main r-main-filename
+ap_is_directory(r-pool, r-main-filename)){
/* The filename from the main request will be set to what should
* be picked up, aliases included. Tomcat will need to know about
@@ -1631,17 +1632,13 @@
* be fine. */
/* Need absolute path to stat */
-if (r-main-filename[strlen(r-main-filename)-1] == '/'){
-if (apr_filepath_merge(r-filename,
- r-main-filename, r-filename,
- APR_FILEPATH_SECUREROOT |
- APR_FILEPATH_TRUENAME,
- r-pool)
-!= APR_SUCCESS){
- return DECLINED;
-}
-} else {
-r-filename = apr_pstrdup(r-pool, r-main-filename);
+if (apr_filepath_merge(r-filename,
+ r-main-filename, r-filename,
+ APR_FILEPATH_SECUREROOT |
+ APR_FILEPATH_TRUENAME,
+ r-pool)
+!= APR_SUCCESS){
+ return DECLINED;
}
/* Stat the file so that mod_dir knows it's there */
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c
On Mon, 22 Jul 2002, Bojan Smojver wrote: You don't need to ask tomcat - jk should have all the mappings, and it can already map any URI. All it has to do is: - for each index: -- concatenate with the current uri -- do the jk mapping ( or internal redirect if you use Location instead of the internal mapper ). If a match is found - forward to tomcat. -- check if a file exists. If yes - serve it as static ( since we already checked all servlet mappings ). - if no match is found, use mod_dir to display the directory. But in the short term, I think we should just let tomcat deal with that, until we have the fix. Are you referring here to mod_jk2 only or both mod_jk 1.2.0 and mod_jk2? I think it could be done for jk2 ( but not easy ). I'm not sure about 1.2 - just forwarding and letting tomcat handle it is not the worse thing. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
Quoting [EMAIL PROTECTED]: Are you referring here to mod_jk2 only or both mod_jk 1.2.0 and mod_jk2? I think it could be done for jk2 ( but not easy ). I'm not sure about 1.2 - just forwarding and letting tomcat handle it is not the worse thing. How about I try to fix it properly in mod_jk 1.2.0 and let you guys do whatever you like in mod_jk2? Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11025] New: - IOException at sun.net.www.protocol.http.HttpURLConnection.getInputStream
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11025. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11025 IOException at sun.net.www.protocol.http.HttpURLConnection.getInputStream Summary: IOException at sun.net.www.protocol.http.HttpURLConnection.getInputStre am Product: Tomcat 4 Version: 4.0.3 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I use apache tomcat/4.0.3 lite edition for jdk1.4. Apache Tomcat/4.0.3 - HTTP Status 500 - Internal Server Error type Exception report message Internal Server Error description The server encountered an internal error (Internal Server Error) that prevented it from fulfilling this request. exception java.io.IOException: Server returned HTTP response code: 500 for URL: http://.../ at sun.net.www.protocol.http.HttpURLConnection.getInputStream (HttpURLConnection.java:691) at exam.AdminObj.getUrlResp(AdminObj.java:59) at org.apache.jsp.stat_0005fquery$jsp._jspService(stat_0005fquery$jsp.java:262) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service (JspServlet.java:202) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:243) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:190) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:566) at org.apache.catalina.valves.CertificatesValve.invoke (CertificatesValve.java:246) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2343) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:566) at org.apache.catalina.valves.ErrorDispatcherValve.invoke (ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:564) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:564) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.connector.http.HttpProcessor.process (HttpProcessor.java:1012) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1107) at java.lang.Thread.run(Thread.java:536) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11025] - IOException at sun.net.www.protocol.http.HttpURLConnection.getInputStream
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11025. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11025 IOException at sun.net.www.protocol.http.HttpURLConnection.getInputStream [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c
On Mon, 22 Jul 2002, Bojan Smojver wrote: Quoting [EMAIL PROTECTED]: Are you referring here to mod_jk2 only or both mod_jk 1.2.0 and mod_jk2? I think it could be done for jk2 ( but not easy ). I'm not sure about 1.2 - just forwarding and letting tomcat handle it is not the worse thing. How about I try to fix it properly in mod_jk 1.2.0 and let you guys do whatever you like in mod_jk2? If you need this fix - of course I'm +1. Let me know if I can help. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11026] New: - After days' running, Apache Tomcat deny offer service.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11026. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11026 After days' running, Apache Tomcat deny offer service. Summary: After days' running, Apache Tomcat deny offer service. Product: Tomcat 4 Version: 4.0.3 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Blocker Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I use Apache Tomcat 4.0.3 lite edition for JDK1.4.0. after days' running, Apache Tomcat deny offer service. I have encountered this problem for 2 times. Apache Tomcat/4.0.3 - HTTP Status 500 - Internal Server Error type Exception report message Internal Server Error description The server encountered an internal error (Internal Server Error) that prevented it from fulfilling this request. exception java.io.IOException: Server returned HTTP response code: 500 for URL: http://... (a servlet) at sun.net.www.protocol.http.HttpURLConnection.getInputStream (HttpURLConnection.java:691) at exam.AdminObj.getUrlResp(AdminObj.java:59) at org.apache.jsp.stat_0005fquery$jsp._jspService(stat_0005fquery$jsp.java:262) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service (JspServlet.java:202) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:243) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:190) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:566) at org.apache.catalina.valves.CertificatesValve.invoke (CertificatesValve.java:246) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2343) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:566) at org.apache.catalina.valves.ErrorDispatcherValve.invoke (ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:564) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:564) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.connector.http.HttpProcessor.process (HttpProcessor.java:1012) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1107) at java.lang.Thread.run(Thread.java:536) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11026] - After days' running, Apache Tomcat deny offer service.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11026. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11026 After days' running, Apache Tomcat deny offer service. --- Additional Comments From [EMAIL PROTECTED] 2002-07-22 03:43 --- After restart Tomcat, everything is OK. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
Quoting [EMAIL PROTECTED]: You don't need to ask tomcat - jk should have all the mappings, and it can already map any URI. All it has to do is: - for each index: -- concatenate with the current uri -- do the jk mapping ( or internal redirect if you use Location instead of the internal mapper ). If a match is found - forward to tomcat. -- check if a file exists. If yes - serve it as static ( since we already checked all servlet mappings ). - if no match is found, use mod_dir to display the directory. Just reading the algorithm and thinking about the implementation of it. Some of the things might present themselves as big problems here in relation to servlet mappings... An example configuration: DirectoryIndex index.jsp index.vm The order of events would be: 1. mod_dir does a sub request for index.jsp 2. jk_map_to_storage() receives the request 3. jk_map_to_storage() engages map_uri_to_worker() -- this would be new code 4. map_uri_to_worker() finds nothing because it has no mapping to anything that matches *.jsp Now, the next step is rather tricky and is the key to the whole thing. Does jk_map_to_storage(): a) assume that there is index.jsp in one of the mappings that match the URI minus the filename; jk_map_to_storage() could be very wrong about this - maybe there is a default file there, but not index.jsp - this would then result in a failed request b) continue processing with the next index file (in this case index.vm) and possibly miss both index.jsp and index.vm in one of the servlet mappings Keep in mind that these are sub-requests that don't actually result in the file being served. It's just mod_dir's way of checking what would happen if there was a file like that 'in the file system'. So, one cannot 'go back' and do all this again, unless mod_dir is changed to do this kind of thing twice (which is definitely a bad idea). I actually think that it is not possible to establish if there is such a file, unless mod_jk somehow knows about their exisitence. I'm not all that familir with mappings, but I reckon that isn't the case. And then, when everybody thought all was lost... ;-) If my old kludge is applied (with the correct test this time) to jk_handler(), things might be better. The kludge involved jk_handler() responding not just to JK_HANDLER requests but also to DIR_MAGIC_TYPE requests. Now, jk_handler() would find the mapping (since the request is for a directory, not a file) and the request would be served by Tomcat. Would this work? I think it might... Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c
On Mon, 22 Jul 2002, Bojan Smojver wrote: it can already map any URI. All it has to do is: - for each index: Just reading the algorithm and thinking about the implementation of it. Some of Well, don't take it as an algorithm - there are many other things to consider. DirectoryIndex index.jsp index.vm The order of events would be: 1. mod_dir does a sub request for index.jsp 2. jk_map_to_storage() receives the request 3. jk_map_to_storage() engages map_uri_to_worker() -- this would be new code 4. map_uri_to_worker() finds nothing because it has no mapping to anything that matches *.jsp That's actually a problem - map_uri_to_worker would find a match ( using *.jsp extension mapping ). That's very serious - need to check the servlet specs, maybe 2.4 has more details. I'm not sure how tomcat deals with that - we would find the extension mapping and find the JspServlet which is mapped to it. But there is no way to tell if this is a real match or not - without invoking JspServlet. ( well, for JSPs we know that a file may be there, but what if the extension would be for something else ? ) Craig, Remy - any ideas ? Now, the next step is rather tricky and is the key to the whole thing. Does jk_map_to_storage(): a) assume that there is index.jsp in one of the mappings that match the URI minus the filename; jk_map_to_storage() could be very wrong about this - maybe there is a default file there, but not index.jsp - this would then result in a failed request If jk_map_to_storage finds an exact or prefix mapping - then the problem is solved, the request goes to tomcat. If it finds an extension mapping - I have no idea. If it doesn't find any mapping - then it's not a request for tomcat and you can look for static files ( or let mod_dir do it ). Keep in mind that these are sub-requests that don't actually result in the file being served. It's just mod_dir's way of checking what would happen if there was a file like that 'in the file system'. So, one cannot 'go back' and do all this again, unless mod_dir is changed to do this kind of thing twice (which is definitely a bad idea). No, you don't need to go back. For each attempted index you make a subrequest and you need to determine if tomcat could handle it. Assuming jk has knowledge about all the mappings in web.xml - you can do that ( again, I don't know how to deal with extension mappings ). If my old kludge is applied (with the correct test this time) to jk_handler(), things might be better. The kludge involved jk_handler() responding not just to JK_HANDLER requests but also to DIR_MAGIC_TYPE requests. Now, jk_handler() would find the mapping (since the request is for a directory, not a file) and the request would be served by Tomcat. I think this would work and is the best short-term solution. If it is a DIR, let tomcat serve it for now. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
- Original Message - From: Bojan Smojver [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Sunday, July 21, 2002 9:19 PM Subject: RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c Quoting [EMAIL PROTECTED]: You don't need to ask tomcat - jk should have all the mappings, and it can already map any URI. All it has to do is: - for each index: -- concatenate with the current uri -- do the jk mapping ( or internal redirect if you use Location instead of the internal mapper ). If a match is found - forward to tomcat. -- check if a file exists. If yes - serve it as static ( since we already checked all servlet mappings ). - if no match is found, use mod_dir to display the directory. Just reading the algorithm and thinking about the implementation of it. Some of the things might present themselves as big problems here in relation to servlet mappings... An example configuration: DirectoryIndex index.jsp index.vm The order of events would be: 1. mod_dir does a sub request for index.jsp 2. jk_map_to_storage() receives the request 3. jk_map_to_storage() engages map_uri_to_worker() -- this would be new code 4. map_uri_to_worker() finds nothing because it has no mapping to anything that matches *.jsp Now, the next step is rather tricky and is the key to the whole thing. Does jk_map_to_storage(): a) assume that there is index.jsp in one of the mappings that match the URI minus the filename; jk_map_to_storage() could be very wrong about this - maybe there is a default file there, but not index.jsp - this would then result in a failed request b) continue processing with the next index file (in this case index.vm) and possibly miss both index.jsp and index.vm in one of the servlet mappings Keep in mind that these are sub-requests that don't actually result in the file being served. It's just mod_dir's way of checking what would happen if there was a file like that 'in the file system'. So, one cannot 'go back' and do all this again, unless mod_dir is changed to do this kind of thing twice (which is definitely a bad idea). I actually think that it is not possible to establish if there is such a file, unless mod_jk somehow knows about their exisitence. I'm not all that familir with mappings, but I reckon that isn't the case. And then, when everybody thought all was lost... ;-) If my old kludge is applied (with the correct test this time) to jk_handler(), things might be better. The kludge involved jk_handler() responding not just to JK_HANDLER requests but also to DIR_MAGIC_TYPE requests. Now, jk_handler() would find the mapping (since the request is for a directory, not a file) and the request would be served by Tomcat. Would this work? I think it might... At the moment, the servlet-mapping issue is somewhat of a red-herring, since only 3.3.2-dev supports it (and even there, it is disabled by default). For now, mod_jk(2) might as well assume that the physical jsp/vm file is there, since Tomcat requires that it is. The real issue is that jk_map_to_storage was a kludgy attempt to bypass tree-walking by Apache (and save the time to do all of those stat calls). Your fix at least removes the kludgy part. ;-) I *really* don't like the idea of passing DIR_MAGIC_TYPE requests to Tomcat, since I tend to set up directories with only static content that only Apache knows about. Sending them to Tomcat just gives me very many 404 errors, so I'd be forced to use a branched copy of mod_jk. If you have: JkMount /myapp/*.jsp ajp13 JkMount /myapp/*.vm ajp13 Then jk_translate will grab the request for /myapp/index.jsp and set the handler. If the file is physically there, then jk_map_to_storage will stat it, and everyone is happy. Otherwise, jk_translate will grab the request for /myapp/index.vm and set the handler and do the same check for a physical file. In Apache 1.3.x, this is basically what happens except that the physical file test is done by Apache's tree-walk. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
Quoting [EMAIL PROTECTED]: DirectoryIndex index.jsp index.vm The order of events would be: 1. mod_dir does a sub request for index.jsp 2. jk_map_to_storage() receives the request 3. jk_map_to_storage() engages map_uri_to_worker() -- this would be new code 4. map_uri_to_worker() finds nothing because it has no mapping to anything that matches *.jsp That's actually a problem - map_uri_to_worker would find a match ( using *.jsp extension mapping ). Sorry, I meant, but never wrote, that the problem would be if there was no explicit extension mapping. If there was, the match would be found and that wouldn't be one of the problem cases because we'd simulate r-finfo.filetype by setting it explicitly to APR_REG. Then mod_dir would engage the real request based on that with handler set to JK_HANDLER, which would then call Tomcat. Now, the next step is rather tricky and is the key to the whole thing. Does jk_map_to_storage(): a) assume that there is index.jsp in one of the mappings that match the URI minus the filename; jk_map_to_storage() could be very wrong about this - maybe there is a default file there, but not index.jsp - this would then result in a failed request If jk_map_to_storage finds an exact or prefix mapping - then the problem is solved, the request goes to tomcat. Well, yes, but at this stage we are not doing the request. mod_dir is just checking if the request should go there or not. And since the real request would be originated by mod_dir, which filename would mod_dir use: index.jsp or index.vm? That would be a real problem case, I think. If it finds an extension mapping - I have no idea. If it doesn't find any mapping - then it's not a request for tomcat and you can look for static files ( or let mod_dir do it ). So, one cannot 'go back' and do all this again, unless mod_dir is changed to do this kind of thing twice (which is definitely a bad idea). No, you don't need to go back. For each attempted index you make a subrequest and you need to determine if tomcat could handle it. You mean here like this? Following code from mod_dir: --- rr = ap_sub_req_lookup_uri(name_ptr, r, NULL); --- Wouldn't that just end up going through jk_map_to_storage() again? If my old kludge is applied (with the correct test this time) to jk_handler(), things might be better. The kludge involved jk_handler() responding not just to JK_HANDLER requests but also to DIR_MAGIC_TYPE requests. Now, jk_handler() would find the mapping (since the request is for a directory, not a file) and the request would be served by Tomcat. I think this would work and is the best short-term solution. If it is a DIR, let tomcat serve it for now. I can implement that easily. But there is one catch: static files would get checked first (through the code in jk_map_to_storage()) and if the match wasn't found (either because there is no DirecoryIndex or there were no physical files that Apache can find), the the raw directory would hit jk_handler(). Is that a problem? Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
Quoting Bill Barker [EMAIL PROTECTED]: I *really* don't like the idea of passing DIR_MAGIC_TYPE requests to Tomcat, since I tend to set up directories with only static content that only Apache knows about. Sending them to Tomcat just gives me very many 404 errors, so I'd be forced to use a branched copy of mod_jk. Actually, DIR_MAGIC_TYPE would *only* get involved if there was no match found through my current code jk_map_to_storage(), and that would not be the case if: - you defined DirectoryIndex - there is a physical file that Apache can stat Basically, static files would be preferred (I don't like the idea of involving Tomcat if I don't need to either). Does that eliminate the objection? Bojan PS. I have applied ap_is_directory() call in the latest version of the patch. Do you think I should have stuck with determining if the r-main-filename ends in a '/'? It would save some stat-ing, but on the other hand I'm not sure if file system directories are stored in Unix format or architecture dependent format (i.e. with '\' on Windows). I wanted to make sure I don't run into problems on Windows... If someone can verify that it'll be a '/', then I think I should remove that stat and just use the last character verification. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
My apologies everyone... Just ignore the part of my previous e-mail marked here with between the stars. It just plain stupid :-( ** Quoting Bojan Smojver [EMAIL PROTECTED]: Quoting [EMAIL PROTECTED]: DirectoryIndex index.jsp index.vm The order of events would be: 1. mod_dir does a sub request for index.jsp 2. jk_map_to_storage() receives the request 3. jk_map_to_storage() engages map_uri_to_worker() -- this would be new code 4. map_uri_to_worker() finds nothing because it has no mapping to anything that matches *.jsp That's actually a problem - map_uri_to_worker would find a match ( using *.jsp extension mapping ). Sorry, I meant, but never wrote, that the problem would be if there was no explicit extension mapping. If there was, the match would be found and that wouldn't be one of the problem cases because we'd simulate r-finfo.filetype by setting it explicitly to APR_REG. Then mod_dir would engage the real request based on that with handler set to JK_HANDLER, which would then call Tomcat. Now, the next step is rather tricky and is the key to the whole thing. Does jk_map_to_storage(): a) assume that there is index.jsp in one of the mappings that match the URI minus the filename; jk_map_to_storage() could be very wrong about this - maybe there is a default file there, but not index.jsp - this would then result in a failed request If jk_map_to_storage finds an exact or prefix mapping - then the problem is solved, the request goes to tomcat. Well, yes, but at this stage we are not doing the request. mod_dir is just checking if the request should go there or not. And since the real request would be originated by mod_dir, which filename would mod_dir use: index.jsp or index.vm? That would be a real problem case, I think. If it finds an extension mapping - I have no idea. If it doesn't find any mapping - then it's not a request for tomcat and you can look for static files ( or let mod_dir do it ). So, one cannot 'go back' and do all this again, unless mod_dir is changed to do this kind of thing twice (which is definitely a bad idea). No, you don't need to go back. For each attempted index you make a subrequest and you need to determine if tomcat could handle it. You mean here like this? Following code from mod_dir: --- rr = ap_sub_req_lookup_uri(name_ptr, r, NULL); --- Wouldn't that just end up going through jk_map_to_storage() again? ** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
new velocity user
can anyone help me with instructions for running velocity templates on tomcat ..?? or kindly give some leads for the same .. thnx sunil
