Index files ( was RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c
On Mon, 22 Jul 2002, Craig R. McClanahan wrote: In Servlet 2.4 (Community Draft 2), it looks like the language in Section 9.10 that describes this hasn't changed. The basic rule is that you combine the partial URLs specified in the welcome file list to the incoming request for a directory resource in the WAR -- and if a resource in the WAR is mapped that request URI then it's supposed to be served by the servlet corresponding to the complete request URI. And that can't work - if index.jsp is specified as index, then *.jsp mapping will allways match. Acording the the servlet spec there is no requirement for index.jsp to be present ( it can be precompied ), and no way to ask a servlet like JspServlet if a request will work without executing it. So the only correct implementation would be to execute service() - and if the result is a 404 then we should try the next match. However there is no guarantee that the extension-mapped servlet will return 404 - in many cases servlets are using the pathinfo to do some actions ( like Struts ) and may return something valid. Catalina interprets the requirement as meaning that there has to be a static resource that matches. This has the side effect that you can't use a regular servlet mapping that doesn't correspond to a static resource -- if you could, that would mean that a welcome file like foo.jsp would match every time, even if there wasn't such a page in the specified directory, because of the *.jsp mapping. I know. And I think you can't use index.do or pre-compiled jsps ( unless you also have the jsp source files - which in many cases is not desirable ). 3.3 has a similar implementation - and I don't think either implements the spec corectly. It would seem that a web connector should at least be able to emulate what Catalina does, by checking for the existence of a static file in the webapp directory. +1 I don't know how you could implement a generic servlet matching a welcome file path, unless we were to exclude extension mapping and default servlet from the definition of matching. And I'm not sure that even that would do the right thing in all circumstances. It's the index.jsp that worries me - combined with precompile jsps. That could be an extremely common case - and will fail with the current implementation. And of course, I would be good to know if it is at least possible to implement this - and if not to have it fixed in the spec. My proposal was to consider all exact and prefix mappings ( that would cover precompiled jsps and struts ), as well as static files. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Index files ( was RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c
On Mon, 22 Jul 2002 [EMAIL PROTECTED] wrote: It's the index.jsp that worries me - combined with precompile jsps. That could be an extremely common case - and will fail with the current implementation. As a workaround, why don't you just include the JSP source files in the war anyway? One of the things JSPC creates for you is a bunch of exact match servlet mappings for the compiled pages, and those will take priority over the extension-match mapping of the index.jsp page to the JSP servlet. And of course, I would be good to know if it is at least possible to implement this - and if not to have it fixed in the spec. My proposal was to consider all exact and prefix mappings ( that would cover precompiled jsps and struts ), as well as static files. Sounds like a topic worth raising with the Servlet 2.4 expert group (JSR-154). I'll start a message thread abou this on the EG mailing list. Costin Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Index files ( was RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c
On Tue, 23 Jul 2002, Craig R. McClanahan wrote: It's the index.jsp that worries me - combined with precompile jsps. That could be an extremely common case - and will fail with the current implementation. As a workaround, why don't you just include the JSP source files in the war anyway? One of the things JSPC creates for you is a bunch of exact match servlet mappings for the compiled pages, and those will take priority over the extension-match mapping of the index.jsp page to the JSP servlet. I know, and so far that's the only solution I found to make index.jsp work. However there are cases where you don't want to distribute the JSP source files - and AFAIK the spec allows that. I'm not really looking for workarounds - but for the 'correct' behavior, that we can eventually implement, and eventually a clarification to the spec - if this can't be implemented. The root of many problems is the way the extension mapping is defined - in a very different way from what all web servers are doing. That creates many integration problems, disables the pathInfo for extension-mapped resources, brakes the index, and may have other effects in future. Of course, in this particular case ( index.jsp - without having the file ) the extension mapping is usefull. Sounds like a topic worth raising with the Servlet 2.4 expert group (JSR-154). I'll start a message thread abou this on the EG mailing list. Thanks. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Index files ( was RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2mod_jk2.c
On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote: Date: Tue, 23 Jul 2002 09:34:18 -0700 (PDT) From: [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: Index files ( was RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c On Tue, 23 Jul 2002, Craig R. McClanahan wrote: It's the index.jsp that worries me - combined with precompile jsps. That could be an extremely common case - and will fail with the current implementation. As a workaround, why don't you just include the JSP source files in the war anyway? One of the things JSPC creates for you is a bunch of exact match servlet mappings for the compiled pages, and those will take priority over the extension-match mapping of the index.jsp page to the JSP servlet. I know, and so far that's the only solution I found to make index.jsp work. However there are cases where you don't want to distribute the JSP source files - and AFAIK the spec allows that. A zero-length file, rather than the actual source, would still fill the bill :-) I'm not really looking for workarounds - but for the 'correct' behavior, that we can eventually implement, and eventually a clarification to the spec - if this can't be implemented. I know ... a clarification is the important thing. The root of many problems is the way the extension mapping is defined - in a very different way from what all web servers are doing. That creates many integration problems, disables the pathInfo for extension-mapped resources, brakes the index, and may have other effects in future. Of course, in this particular case ( index.jsp - without having the file ) the extension mapping is usefull. Sounds like a topic worth raising with the Servlet 2.4 expert group (JSR-154). I'll start a message thread abou this on the EG mailing list. Thanks. Costin Craig -- 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 Sun, 21 Jul 2002, Bill Barker wrote: 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 I'm beginning to doubt the spec can be implemented - I just can't find any reasonable way to deal with extensions mapping. Yes, I know tomcat doesn't implement it very well either. 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 Not all DIR_MAGIC_TYPE, only those that belong to a webapplication. And possibly based on some option to enable/disable this behavior. 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/apache2mod_jk2.c
On Sun, 21 Jul 2002 [EMAIL PROTECTED] wrote: 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. In Servlet 2.4 (Community Draft 2), it looks like the language in Section 9.10 that describes this hasn't changed. The basic rule is that you combine the partial URLs specified in the welcome file list to the incoming request for a directory resource in the WAR -- and if a resource in the WAR is mapped that request URI then it's supposed to be served by the servlet corresponding to the complete request URI. 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. Catalina interprets the requirement as meaning that there has to be a static resource that matches. This has the side effect that you can't use a regular servlet mapping that doesn't correspond to a static resource -- if you could, that would mean that a welcome file like foo.jsp would match every time, even if there wasn't such a page in the specified directory, because of the *.jsp mapping. It would seem that a web connector should at least be able to emulate what Catalina does, by checking for the existence of a static file in the webapp directory. ( 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 ? I don't know how you could implement a generic servlet matching a welcome file path, unless we were to exclude extension mapping and default servlet from the definition of matching. And I'm not sure that even that would do the right thing in all circumstances. Craig 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] -- 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 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
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 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/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/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/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]
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/apache2mod_jk2.c
On Fri, 2002-07-19 at 01:15, [EMAIL PROTECTED] wrote: mturk 2002/07/18 08:15:00 Modified:jk/native2/server/apache2 mod_jk2.c Log: Fix the bug 10789 caused by hook order. Thanks Mladen. 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
Since I didn't really like my original 'fix' for mod_jk 1.2.0 situation (bug 9913), I tried this approach, but it seems to make no difference whatsoever... The content of the directory is being served rather then default pages. Bojan On Fri, 2002-07-19 at 01:15, [EMAIL PROTECTED] wrote: mturk 2002/07/18 08:15:00 Modified:jk/native2/server/apache2 mod_jk2.c Log: Fix the bug 10789 caused by hook order. -- 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
You should also have a look to
jakarta-commons-sandbox/daemon/src/native/unix/native/location.c for the
defaultVM_PATH possible values. (The variable is named location_jvm_default there).
[EMAIL PROTECTED] wrote:
costin 2002/06/01 08:40:09
Modified:jk/native2/common jk_vm_default.c
jk/native2/server/apache2 mod_jk2.c
Log:
2 fixes from Mladen Turk: eliminate double version and add support for
another JVM layout style.
Thanks.
Revision ChangesPath
1.16 +1 -0 jakarta-tomcat-connectors/jk/native2/common/jk_vm_default.c
Index: jk_vm_default.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_vm_default.c,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- jk_vm_default.c 24 May 2002 04:29:22 - 1.15
+++ jk_vm_default.c 1 Jun 2002 15:40:09 - 1.16
@@ -151,6 +151,7 @@
*/
static const char *defaultVM_PATH[]={
${JAVA_HOME}${fs}jre${fs}bin${fs}classic${fs}libjvm.${so},
+${JAVA_HOME}${fs}jre${fs}bin${fs}client${fs}jvm.${so},
${JAVA_HOME}${fs}jre${fs}lib${fs}${arch}${fs}classic${fs}libjvm.${so},
${JAVA_HOME}${fs}jre${fs}lib${fs}${arch}${fs}client${fs}libjvm.${so},
${JAVA_HOME}${fs}jre${fs}bin${fs}classic${fs}jvm.${so},
1.31 +1 -3 jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
Index: mod_jk2.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- mod_jk2.c 31 May 2002 22:27:17 - 1.30
+++ mod_jk2.c 1 Jun 2002 15:40:09 - 1.31
@@ -59,7 +59,7 @@
* Description: Apache 2 plugin for Jakarta/Tomcat *
* Author: Gal Shachor [EMAIL PROTECTED] *
* Henri Gomez [EMAIL PROTECTED] *
- * Version: $Revision: 1.30 $ *
+ * Version: $Revision: 1.31 $ *
***/
/*
@@ -464,8 +464,6 @@
if(s-is_virtual)
return OK;
-
-ap_add_version_component(pconf, JK_EXPOSED_VERSION);
env=workerEnv-globalEnv;
--
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]
