Re: Tomcat scalability
Quoting Jon Scott Stevens [EMAIL PROTECTED]: on 2002/11/3 2:24 PM, Bojan Smojver [EMAIL PROTECTED] wrote: I know you have a much better machine, but 1600 transactions does seem a bit high. Not for porn. Nah... they wouldn't use Java for that. They'd use Porn Hypertext Processor (PHP) ;-) Bojan -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: TOMCAT memory usage : how to manage and benchmark ?
On Tue, 2002-10-29 at 20:15, jean-frederic clere wrote: The Linux threads implementation is _bad_ but that does not mean that the whole thing bad. I was just teasing. Anyway, have a look at this: http://marc.theaimsgroup.com/?l=linux-kernelm=103269598000900w=2 and this: http://www-124.ibm.com/developerworks/oss/pthreads/ The first link is the future (2.6 or 3.0), the second is now. For the Fun. The kernel threads appair also in ps but I have not (yet) tried to kill one ;-) There are known problems with POSIX compliance in the stock threads (this includes signal delivery and other problems). Bojan -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: TOMCAT memory usage : how to manage and benchmark ?
On Tue, 2002-10-29 at 00:31, Pier Fumagalli wrote: Those are _not_ processes, they are threads... Use a decent operating system that supports them nicely (not Linux) and you'll see the difference (how many times do I have to repeat this?)... Linux sucks :-( Ha, ha... Keep dreaming Pier ;-) Bojan -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: TOMCAT memory usage : how to manage and benchmark ?
On Tue, 2002-10-29 at 00:10, [EMAIL PROTECTED] wrote: Hello, I have tomcat 4.1.10 on a red hat Linux server 7.3 with the j2sdk141, When I start the tomcat4 service, all is OK and the tomcat server run. BUT, when I look the memory usage (with TOP utility), I have this result : 11:31am up 12 days, 2:18, 2 users, load average: 0,00, 0,00, 0,00 90 processes: 87 sleeping, 3 running, 0 zombie, 0 stopped CPU states: 0,0% user, 0,5% system, 0,0% nice, 99,4% idle Mem: 514340K av, 479748K used, 34592K free, 0K shrd, 75716K buff Swap: 1048120K av, 35016K used, 1013104K free 216648K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 19954 tomcat4 25 0 33584 32M 10464 S 0,0 6,5 0:05 java 19957 tomcat4 15 0 33584 32M 10464 S 0,0 6,5 0:00 java 19958 tomcat4 15 0 33584 32M 10464 S 0,0 6,5 0:00 java 19959 tomcat4 15 0 33584 32M 10464 S 0,0 6,5 0:00 java 19960 tomcat4 15 0 33584 32M 10464 S 0,0 6,5 0:00 java 19961 tomcat4 15 0 33584 32M 10464 R 0,0 6,5 0:00 java 19962 tomcat4 20 0 33584 32M 10464 S 0,0 6,5 0:00 java 19963 tomcat4 16 0 33584 32M 10464 S 0,0 6,5 0:00 java 19964 tomcat4 16 0 33584 32M 10464 S 0,0 6,5 0:01 java 19966 tomcat4 15 0 33584 32M 10464 S 0,0 6,5 0:00 java 19967 tomcat4 15 0 33584 32M 10464 S 0,0 6,5 0:00 java 19968 tomcat4 15 0 33584 32M 10464 S 0,0 6,5 0:00 java 19969 tomcat4 15 0 33584 32M 10464 S 0,0 6,5 0:00 java 19970 tomcat4 15 0 33584 32M 10464 S 0,0 6,5 0:00 java 19971 tomcat4 15 0 33584 32M 10464 S 0,0 6,5 0:00 java 19972 tomcat4 15 0 33584 32M 10464 S 0,0 6,5 0:00 java 19973 tomcat4 15 0 33584 32M 10464 S 0,0 6,5 0:00 java So, My first question is : why tomcat use all the memory while there is no users connected (or just one) ? Ah well, it's Java, that's why. There is a lot of side stuff going on in a JVM that requires heaps (no pun intended) memory (i.e. you have to pay for having strong runtime typing, no buffer overflows, run anywhere...). My second question is : how much memory is needed if I want to use tomcat with many users (500, 1000,...) ? Huh, depends on what your applications do, really. For so many concurrent users Tomcat will create separate threads, which means separate local storage for all of them. Then there is the garbage collection algorithm, which is usually lazy, so more then absolutely necessary will be allocated etc. I already read in the forum Tomcat don't manage the memory, it is the JVM... so why the jvm use so many processes ? This is configurable in server.xml, I think. However, if you under configure it, some clients may be left out. Bojan -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [VOTE] tomcat-commiters list
On Tue, 2002-10-15 at 03:24, Costin Manolache wrote: I would like to propose a new mailing list. The list will be closed to commiters only. The main purpose will be discussions of security and other special issues. This should avoid [Cc] threads. The main target should be active commiters - so it should start empty. This is a majority vote. [X] I agree with the proposal [ ] I don't agree with the proposal -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk2 and daemon ( was Re: commons-daemon release ?)
Quoting Pier Fumagalli [EMAIL PROTECTED]: Our main web-app has roughly 400 JSP pages to compile (you never know), 20 servlets loaded on startup, 4 lucene indexes to open, 500 connections to the database, 350/400 megabytes of cached objects to de-serialize and put down into memory, and some initial synchronization checks with the DB to find out what are the articles that need to be displayed first (articles ranking) out of an history of some hundred thousand of them (all on line)... It is a big bubba, the JVM memory size is somewhat in the range of 640 Mb... :-) (and it's just 1 web-application out of 6) Only problem? Tomcat doesn't scale that high :-( Since you like segfaults better then NPE's and you seem to need performance, maybe you should try CSP's: http://astro.temple.edu/~john43/ ;-) Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk crash, please help
Quoting Eugene Gluzberg [EMAIL PROTECTED]: Please help. How can i trace this further? How do i get apache to generate a core file so i can see where in apache code this is? Any pointers for help here at all? Have a look at this: http://httpd.apache.org/dev/debugging.html Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Apache 2.0.43 is out
So, there was an MMN bump in Apache 2.0.43? From what I can tell, that's not the case... Bojan On Fri, 2002-10-04 at 18:13, Henri Gomez wrote: We should provide new binaries for JK and JK2. I'll do JK/JK2 for Linux boxes (and FreeBSD) Who could do the same for Windows, Netware and Solaris ? BTW, I'm still waiting an account on moof to build a MacOSX version. -- 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: Apache 2.0.43 is out
Just ignore... I should read my e-mail from the most recent :-( Bojan On Sat, 2002-10-05 at 10:39, Bojan Smojver wrote: So, there was an MMN bump in Apache 2.0.43? From what I can tell, that's not the case... Bojan On Fri, 2002-10-04 at 18:13, Henri Gomez wrote: We should provide new binaries for JK and JK2. I'll do JK/JK2 for Linux boxes (and FreeBSD) Who could do the same for Windows, Netware and Solaris ? BTW, I'm still waiting an account on moof to build a MacOSX version. -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat 3.3.2 cleanup
+1 Bojan On Mon, 2002-09-30 at 19:13, Henri Gomez wrote: If everybody agree, what about removing src/native for tomcat 3.3.2 ? -- 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: [ANNOUNCEMENT]: JK 1.2.0 is now available
Just compiled and tested mod_jk 1.2.0 from CVS, Apache 2.0.42. Seems as solid as ever... Good stuff! Bojan On Sat, 2002-09-28 at 01:03, Henri Gomez wrote: Hi all, The Jakarta-Tomcat-Connector team is pleased to announce the availability of JK 1.2.0. JK, also known as mod_jk, is a Tomcat / WebServers plug-in that handles the communication between Tomcat and webservers. Currently Apache 1.3.x and 2.0.x, IIS, Netscape/iPlanet are supported. binaries and source versions of the release are available and can be downloaded from : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/ Binaries allready available are : - Linux i386 (Apache 1.3/2.0.42) - Solaris 8 (Apache 1.3/2.0.39/2.0.42) - Win32 (IIS/Apache 1.3/2.0.42) MacOS X, AIX, iSeries binaries to be released shortly (I hope) Feel free to contact us to provide binaries for your own operating system. Enjoy! -- 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/common jk_requtil.c
Quoting [EMAIL PROTECTED]: In the C language we use #ifdef not #ifef :-) Only if something like this works: #define #ifef #idef ;-) -#idef AS400 +#ifdef AS400 Bojan - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_requtil.c
Quoting Henri Gomez [EMAIL PROTECTED]: Bojan Smojver wrote: Quoting [EMAIL PROTECTED]: In the C language we use #ifdef not #ifef :-) Only if something like this works: #define #ifef #idef ;-) Oups, I'll fix the typo ASAP Actually, Mladen already fixed it. It's just that he had another, different typo in the description of the fix, which was either: - a very good joke :-) - unintentional and therefore an even better joke ;-) Bojan - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/commonjk_requtil.c
On Wed, 2002-09-25 at 18:28, Henri Gomez wrote: Actually, Mladen already fixed it. It's just that he had another, different typo in the description of the fix, which was either: - a very good joke :-) - unintentional and therefore an even better joke ;-) What do you means ? The broken code was: #idef AS400 Then Mladen fixed it to: #ifdef AS400 But in the CVS comment he put: In the C language we use #ifdef not #ifef :-) ^ I found the fact that he fixed a typo and then in the explanation made another one funny, as in ha, ha. I was just having a few laughs, that's all. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JK2 logo
Nicely done! Bojan On Wed, 2002-09-25 at 19:30, Mladen Turk wrote: Just a suggestion. MT. -- 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: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
On Wed, 2002-09-25 at 20:59, John Trollinger wrote: Don't buy all the velocity hype.. It is not as great as they make it out to be. What hype? I don't follow here... Velocity is just a template language, plain, simple and relatively small. It's greatness comes from the fact that you cannot do things in it, not from that fact that you can. Other template languages might be as good or better, wouldn't know, but given that Velocity is a Jakarta project, it seemed like a reasonable suggestion to me. And it certainly does the job for me. I don't see why would sharing a good experience with someone qualify as hype. But all that is actually beside the point. The point is that you don't want your web designers to touch Java code, ever. Making web pages programs, with access into depths of you JVM, is what the initial problem with JSP's actually is. Please no flames from the velocity disiples as I will not respond. Why do you think anyone from Velocity crowd would flame you? I found most users and developers to be helpful and constructive. They certainly helped me switch from JSP's in no time at all. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Quoting Costin Manolache [EMAIL PROTECTED]:
And Velocity does have a mailing list where all this can be discussed.
This is tomcat-dev - for servlet and jsp development.
If you have any ideas on how to improve jasper - great, but please don't
waste our time with off topic subjects. Comments and sugestions on JSP spec
can be addressed to the feedback address from Sun, we just implement it.
( and BTW, nobody forces you to use any java inside the JSP if you don't
want to, or any of the features that are specific to jsps. )
All right then, let's talk about JSP's. If I host my clients' JSP's on my server
and a web designer puts this in (BTW, he wasn't forced, he simply decided he
wanted to do it):
---
Hashtable strings = new Hashtable();
int i=0;
while (true)
{
strings.put (dead+i, new StringBuffer(99));
}
---
What would happen to my Tomcat? I think this is called OutOfMemoryError and it
would affect every single web application running in that instance of Tomcat,
possibly owned by some other clients of mine. Completely unacceptable...
Web applications are collection programs and other stuff, for instance web
pages. However, web pages should not be programs because they are (usually)
maintained by non-programmers. The fact that you know what you're doing doesn't
exuse the shortcomings of the technology.
Bojan
-
This mail sent through IMP: http://horde.org/imp/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Not if:
runtime.interpolate.string.literals = false
Bojan
Quoting Tim Funk [EMAIL PROTECTED]:
That's what code reviews are for and in absence of that - firing your
developers.
Wouldn't I also get an out of memory with this in Velocity?
#set($oom = )
#foreach( $i in [-2147483648..2147483648] )
#set($oom = $oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom )
#end
Bad code can kill ANY system for the determined(disgruntled) developer.
Bojan Smojver wrote:
All right then, let's talk about JSP's. If I host my clients' JSP's on my
server
and a web designer puts this in (BTW, he wasn't forced, he simply decided
he
wanted to do it):
---
Hashtable strings = new Hashtable();
int i=0;
while (true)
{
strings.put (dead+i, new StringBuffer(99));
}
---
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
-
This mail sent through IMP: http://horde.org/imp/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Quoting Costin Manolache [EMAIL PROTECTED]: Bojan Smojver wrote: All right then, let's talk about JSP's. If I host my clients' JSP's on my server and a web designer puts this in (BTW, he wasn't forced, he simply decided he wanted to do it): And your proposed solution is ... ? Don't use JSP's. I think that was very clear from the beginning of this thread. Do you have a patch to solve this problem ? If so, send the code. IF not - please let me know what's your point here ? Do you think we're stupid and never heard about denial of service ? No, I don't think that anyone here is stupid - how did you get that idea? And I don't have a patch. I don't think anyone has. Furthermore, since this is not my itch any more, why would I scratch? Also I don't think that malicious people can be prevented from causing problems if they really want to. But, if you make it easy for it to happen by accident to the people that don't really understand what they're doing, that's asking for trouble (e.g. how many web designer really understand the concept of session beans?). My point is this - JSP makes it dead easy to not write MVC applications and to fiddle with Java code where you shouldn't. Jon explained it here: http://jakarta.apache.org/velocity/ymtd/ymtd.html. Bottom line: let designers design and let programmers program. BTW, velocity _is_ a programming language - at least by the book definition, AFAIK it is turing complete. Some things are more difficult to do, but not impossible - you can see it as a benefit, I see it as a major lack of flexibility. Actually, I think even Velocity can do too much. An even better template language (or whatever you want to name it - don't really care) wouldn't allow method calls etc. But that's a different story altogether... So if you want to discuss solutions for this problem - I'm sure it'll help other templating and programming tools as well, including velocity ( which BTW can be a nice tool - and the lack of flexibility can be good in some cases ). I don't know what to do about your web designer - who doesn't know programming but decides to write some DOS code in his page. But I know that the best web applications I've used so far ( including some in php or perl ) were written by people who know a lot of programming. You need software engineers, useability engineers - not web designers who are clueless on programming ( and can't be trusted to not write DOS just for fun ). I'm not talking about my web designer, I'm talking about my clients' web designers. I cannot fire my clients' employees. I also don't have any influence over what they do and don't know, how qualified they are and if they care. Again, the point is - why give people power (that they don't need anyway) and hope nothing bad will happen? Bojan - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Quoting Bill Barker [EMAIL PROTECTED]: I'm agreeing with Costin. Please move this discussion to [EMAIL PROTECTED] It is off-topic here. Promise not to write a single byte on this topic on Tomcat-Dev list after this e-mail. Bojan - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs faq.xml
I think this also applies to 1.3. It's just that MMN in it hasn't been changed for a while. Bojan On Tue, 2002-09-24 at 20:23, [EMAIL PROTECTED] wrote: hgomez 2002/09/24 03:23:51 Modified:jk/xdocs faq.xml Log: Add information about MMNB (Magic Module Number bump) of Apache 2.0 Revision ChangesPath 1.4 +2 -2 jakarta-tomcat-connectors/jk/xdocs/faq.xml Index: faq.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/faq.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- faq.xml 20 Sep 2002 21:35:31 - 1.3 +++ faq.xml 24 Sep 2002 10:23:51 - 1.4 @@ -220,7 +220,7 @@ subsection name=Apache 2.0 complains about incorrect module version p Since Apache 2.0 API still change often, the Apache 2.0 teams decide to put in headers of compiled modules the -Apache 2.0 version used to compile the module. +Apache 2.0 version used to compile the module. This check is called Magic Module Number bump. /p p At start time Apache 2.0 check that version in modules headers and stop if it detect that a module was compiled -- 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: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Quoting Glenn Nielsen [EMAIL PROTECTED]: This list is for discussing Tomcat development, not velocity, web macro, et. al. The evangelizing for velocity is off topic in this list. JSP is part of Tomcat, live with it and move on. There are plenty of other forums for discussing the merits of one web templating technology vs another. Sure. But it's fun :-) Bojan - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Quoting Steve Downey [EMAIL PROTECTED]: Perhaps you would prefer this exploit? http://localhost:8080/velexample/servlet/org.apache.catalina.servlets.DefaultServlet/sample.vm Horrors! Velocity is insecure! The DefaultServlet exploit is a general security problem in Tomcat. JSP may be somewhat more vulnerable, due to the (somewhat naieve) expectation that the source will be confidential, but it's not really JSP per se that is at fault. Actually, there is a big difference here. You're assuming that Velocity macro pages are programs (well, classes) like JSP's and therefore probably contain security sensitive information. Usually what you'll see is something like this: #foreach($role in $roles) #if($fields.rolename $fields.rolename==$role.rolename) option selected=selected$role.rolename/option #else option$role.rolename/option #end #end This is a (very typical) snippet from a VM that does editing of Tomcat users/roles database in one of my applications. I don't care if people see that code at all because the template doesn't do anything but templating. The beef if elsewhere (i.e. MVC). Bojan PS. Glenn, my apologies, I was just answering a direct question. - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [POLL] Tomcat 3.3.2 updates
On Tue, 2002-09-24 at 00:01, Henri Gomez wrote: Thanks to give your opinion here. [X] 1. Don't care about MBeans, or do want to be able to have different XML apis for apps and container, so keep the current situation. [ ] 2. MxInterceptor is really needed, ok to change the layout, we'll warn users in Changelog / Readme [ ] 3. I'd like to MxInterceptor and old layout, I'd rather like to have a copy of DynamicMBeanProxy from jtc/util located in a location compatible with container/lib (to be in container_util.jar we could copy it in org.apache.tomcat.util.mx) [ ] 4. I'd like to use MxInterceptor, keep the old layout, but don't want to make the copy and could provide some code to avoid that. However, as long as I can: 1. Disable it completely in server.xml 2. Remove unwanted XML parser JAR's manually I'm OK with any, really. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk 1.2.0 release proposal
Sounds good (although I have to admit I haven't compiled mod_jk from CVS for a while). +1 Bojan On Fri, 2002-09-20 at 20:40, Henri Gomez wrote: Hi to all, Now that code and odc is stabilized in mod_jk 1.2.0, it could be time to do the release : Proposals : Monday 2002/09/23 - Freeze native development Tuesday 2002/09/24 - Tag JTC as mod_jk 1.2.0 and prepare tarball, which will contains only : jk/native jk/docs (generated from xdocs and without jk2 parts) Wednesday 2002/09/25 - Prepare binaries for : mod_jk 1.2.0 for Apache 1.3.26 / 2.0.40 (I could do Linux i386 with and without ssl for 1.3.26) isapi redirector (nacho ?) nes/iplanet redirector (mike ?) domino should be left out since the code has been updated for many times now and need review by andy. We'll need mod_jk binaries for others Unix platform like AIX/HPUX/MacOSX/Solaris and everybody is welcome. I'll do the iSeries (AS/400) against Apache 2.0.39 as soon as I get the required PTF installed on my OS400 V5R1. The release should be present in : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/ where will find : bin,doc,rpms,src Comments please and vote : -- 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/src/etc server.xml
On Thu, 2002-09-19 at 21:14, [EMAIL PROTECTED] wrote: -MXInterceptor port=8999 authentification=basic +MxInterceptor port=8999 authentification=basic user=admin password=changeillico/ Shouldn't the above be authentication, not authentification? Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jasper 2 Question
On Fri, 2002-09-20 at 04:30, Lenny Karpel wrote: is it right that when I ask a serious question about jasper2 that I get these totally ridiculous answers ? Well, Jon and Pier are known to throw in a curly one from time to time, which keeps all of us here on the list in good spirits ;-) Anyway, there is a serious side to all this as JSP's are inherently evil. You'll find that creating true MVC applications in Velocity is almost trivial. I suggest you do read Jon's article. The fact that JSP's are official, doesn't mean they are good. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jasper 2 Question
Quoting Lenny Karpel [EMAIL PROTECTED]: this is truly amazing .. how can this possibly be .. My apologies for making you upset :-( It honestly wasn't my intention. Jon helped me with my transition from JSP to Velocity and since then my web apps have become much simpler and easier to maintain. That was the point of my e-mail. As for Jasper, don't know, but I'm sure there will be people that do. Bojan - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 3.3 repository changes
On Fri, 2002-09-13 at 19:46, Henri Gomez wrote: Now that we have mod_jk present on JTC, what about removing it from TC 3.3.2 CVS ? +1 Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Applet Codebase From Servlet
There is no difference between the HTML generated by the servlet and a static HTML file. So, cut yourself a static HTML file (handy for testing), put the applet tag in there and watch the web server log files to see what is the actual requested URL. Once you know that, fix it accordingly and you'll be laughing. Bojan Quoting Martin Mc Atamney [EMAIL PROTECTED]: I have a servlet which produces straight HTML. In the HTML I'd like to embed an applet tag. My servlet is in com.test.servlet, my applet in com.test.applet. I set the code value in the applet tag to test.class, but after trying various combinations for codebase I still getting a FileNotFound exception when a browser tries to load my applet. Am I missing something. I am using jakarta-tomcat-4.0-b5 - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [linux CP COMMAND options]
On Tue, 2002-09-10 at 03:56, micael wrote: I will investigate this and do thank you. You are welcome. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSL Connectors
Quoting Trevor Nielsen [EMAIL PROTECTED]: I would also like to get an idea of how long it will be until Tomcat 5 has been released. Although I'm not actively participating in development, I can confidently say that it's going to be before Tomcat 6 ;-) Bojan - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [linux CP COMMAND options]
http://rsync.samba.org/ Bojan On Mon, 2002-09-09 at 08:37, micael wrote: I need to copy all the files (drilled down in directories recursively) that end in .jsp to another location and write over the files in that location. Anyone have the command for a Red Hat 7.2 Linux environment? It is irrelevant, but connected to this list, that I am running Tomcat 4 and Struts with JBoss. Not much knowledge about the admin languages in my head. Any assistance would be appreciated. Sorry if this is a bit off topic. -- 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: [linux CP COMMAND options]
I'm not sure I know what a 'Secure CTR' is, so I'll leave that one alone :-) Yes there is 'cp -fr' on Linux, see 'man cp' for details. Manual pages for RedHat Linux are available from here: http://linux.ctyme.com/. rsync will make sure copying is atomic (i.e. it'll create a temp file, sync into it and then move the temp file into the destination file ), cp won't (it'll overwrite the target file, starting at the beginning of the file, so if something grabs the file while this is being done, there's going to be trouble), which makes rsync a better choice for this kind of work, especially if you're doing it while Tomcat is running. Also, rsync has sophisticated pattern matching, which makes it, well, suitable for (remote) syncing :-) Bojan Quoting micael [EMAIL PROTECTED]: Thanks, Bojan, but I use a command line with Secure CTR. What I need to know is what is the right command with cp on the linux machine. Is there one? cp -fr ? /usr/local/java/tomcat/webapps/[app]/WEB-INF/classes/com/wahoo/place/ which will force the .jsp pages to overwrite the ones in place/ is what I need. Micael At 09:45 AM 9/9/2002 +1000, you wrote: http://rsync.samba.org/ Bojan On Mon, 2002-09-09 at 08:37, micael wrote: I need to copy all the files (drilled down in directories recursively) that end in .jsp to another location and write over the files in that location. Anyone have the command for a Red Hat 7.2 Linux environment? It is irrelevant, but connected to this list, that I am running Tomcat 4 and Struts with JBoss. Not much knowledge about the admin languages in my head. Any assistance would be appreciated. Sorry if this is a bit off topic. -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [linux CP COMMAND options]
Quoting micael [EMAIL PROTECTED]: I want to move particular files out of a group, so the sort of graphic tool you are talking about is useless to me. Which one was the graphic tool? Not following... Bojan - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk doc works in progress
On Fri, 2002-09-06 at 18:26, Henri Gomez wrote: Mladen Turk wrote: One suggestion. I would use the align=left for most of the tables showing config or console cause it would look much better, but that's my opinion. Hum it seems to be a problem with IE, mozilla allready show it at left, I'll fix the xsl/css Probably something that was introduced with IE 6. I noticed some of my web work was broken in the same way. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [vote] Possible logos for mod_jk documentation
On Mon, 2002-09-02 at 23:35, jean-frederic clere wrote: vote I prefer to use: (Please put X in the [ ] of file you like most). mod_jk-logo11.gif [ ] mod_jk-logo11.png [ ] mod_jk-logo12.png [ ] mod_jk-logo13.gif [ ] mod_jk-logo13.png [ ] mod_jk-logo14.png [ ] mod_jk-logo15.png [ ] mod_jk-logo16.png [ ] mod_jk-logo3.jpg [ ] mod_jk-logo4.jpg [ ] mod_jk-logo5.jpg [X] mod_jk-logo6.jpg [ ] As logo for mod_jk documentation. /vote The surfing Tomcat! Bojan PS. Actually, I think we should adopt both 5 and 6 and let people use them as they see fit (i.e. with or without the text). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Spec question: RE BUG 12052
On Fri, 2002-08-30 at 23:51, Ignacio J. Ortega wrote: De: Bojan Smojver [mailto:[EMAIL PROTECTED]] Enviado el: 30 de agosto de 2002 1:11 Para: Tomcat Dev List Asunto: RE: Spec question: RE BUG 12052 On Thu, 2002-08-29 at 23:49, Ignacio J. Ortega wrote: We know how r-parsed_uri.port gets his value? Yep. It's getting it from the URL, not the headers. Wrong, It takes the port and ServerName from the Host: header if the Request-uri is relative ( most common case ) and from the Reqeust-Uri if it is absolute.. rfc2616 Section 5.2 strict compliance.. I had another look at Apache 2.0 code and I think you're right. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat crashes
Quoting Taral Shah [EMAIL PROTECTED]: Try a different JDK. This doesn't look a Tomcat problem. Bojan Hi I am facing strange problem at one of my customers side. I am using tomcat 3.3 for my devlopment and its working fine. But at one of customers side tomcat crases unknowingly. It even does not compile a simple jsp. The os at the client side is solaris, WHen tomcat starts and a simple jsp(containg just 2 html tags like html and title) is run it throws following error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 10 occurred at PC=0x10a1fc Function name=(N/A) Library=(N/A) - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Spec question: RE BUG 12052
Quoting [EMAIL PROTECTED]: So: getServerPort() should return the same as the CGI variable SERVER_PORT ( which returns the server port, not the host header ! ), meaning the value of the part after : in the Host header. I didn't know that the servlet spec can define new meanings for the CGI spec. Pretty cool, ha? :-)) Bojan - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat crashes
One more thing - check if the OS has all the relevant patches. Sometimes it's the libraries that JDK's using. Bojan Quoting Bojan Smojver [EMAIL PROTECTED]: Quoting Taral Shah [EMAIL PROTECTED]: Try a different JDK. This doesn't look a Tomcat problem. Bojan Hi I am facing strange problem at one of my customers side. I am using tomcat 3.3 for my devlopment and its working fine. But at one of customers side tomcat crases unknowingly. It even does not compile a simple jsp. The os at the client side is solaris, WHen tomcat starts and a simple jsp(containg just 2 html tags like html and title) is run it throws following error: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 10 occurred at PC=0x10a1fc Function name=(N/A) Library=(N/A) - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat crashes
Quoting Taral Shah [EMAIL PROTECTED]: But same thing works with different solaris. Here I have solaris 5.7 and with 5.8 it works fine, even in one of 5.7 solaris machine tomcat runs fine. And they all have the same patches applied? I don't use Solaris, so I can't tell you specifically what to do or patch, but the errors indicate a VM problem (or something outside affecting the VM). Even if you feed VM total garbage, it shouldn't crash. That's the theory, at least. I checked with memory and space, initially it showed that it had occupied 99% of disk space, so i moved whole code to another partition and there only 50% space is used. Still its giving me same problem. I never had such crowded partitions, so I can tell if that might affect the VM. Any other solution, Or if i change JDK then which jdk should i go, as I need jdk 1.3 and here i am using same, do u suggest me to go with jdk1.4? I think there is a 1.3.1_04 available for Solaris. If you're aren't familiar with 1.4 (like I'm not), I think it's better to stick with the same minor version, unless, of course, that doesn't fix it. And given the error message (An unexpected exception has been detected in native code outside the VM), I would investigate the patch status of the machine quite seriously. Bojan - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Spec question: RE BUG 12052
On Thu, 2002-08-29 at 23:49, Ignacio J. Ortega wrote: We know how r-parsed_uri.port gets his value? Yep. It's getting it from the URL, not the headers. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Spec question: RE BUG 12052
Craig, I think this bug report is invalid, since Tomcat/Apache has no knowledge of load balancers and firewalls, so it is unrealistic to expect to return port numbers that it doesn't know about. What do you think? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12052 Other opinions welcome :-) Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Spec question: RE BUG 12052
On Thu, 2002-08-29 at 02:14, Craig R. McClanahan wrote: Consider Apache running on port 80, forwarding to Tomcat on 8009 (the default setup). I think it's reasonable for the application developer to assume that getServerPort() is going to return 80 and not 8009, because they should conceptually view the entire Apache+Tomcat thing as a single server. To avoid confusion, I have tested what comes back. The combo is Apache 2.0.40, mod_jk 1.2.0, Tomcat 3.3.x. The port 80 comes back over HTTP and 443 over SSL. This is also indicated by the current source in the bug report. The real problem is that the bug report asks to go a step further and to fake the ports when there is a load balancer or firewall in front of Apache/Tomcat combo. I don't think we should do that - load balancer or firewall is not part of the container. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Spec question: RE BUG 12052
On Thu, 2002-08-29 at 04:28, Bill Barker wrote:
The question in 12052 is whether Apache should use the socket port (as it
does now), or the port in the Host header. When this came up with the
Coyote/Http11 connector, the decision was that the Host header was the
correct one. I'd have to say that the bug is valid.
This is what the API (2.2) docs say about the getServerPort():
Returns the port number on which this request was received. For HTTP
servlets, same as the value of the CGI variable SERVER_PORT.
This in itself could be contradicting, but I think that in the case of
Apache it is pretty straightforward.
This is what Apache 2.0 does to populate the variable SERVER_PORT:
apr_table_addn(e, SERVER_PORT,
apr_psprintf(r-pool, %u, ap_get_server_port(r)));
And this is the ap_get_server_port():
AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
{
apr_port_t port;
core_dir_config *d =
(core_dir_config *)ap_get_module_config(r-per_dir_config,
core_module);
if (d-use_canonical_name == USE_CANONICAL_NAME_OFF
|| d-use_canonical_name == USE_CANONICAL_NAME_DNS) {
/* With UseCanonicalName off Apache will form self-referential
* URLs using the hostname and port supplied by the client if
* any are supplied (otherwise it will use the canonical name).
*/
port = r-parsed_uri.port ? r-parsed_uri.port :
r-server-port ? r-server-port :
ap_default_port(r);
}
else { /* d-use_canonical_name == USE_CANONICAL_NAME_ON */
/* With UseCanonicalName on (and in all versions prior to 1.3)
* Apache will use the hostname and port specified in the
* ServerName directive to construct a canonical name for the
* server. (If no port was specified in the ServerName
* directive, Apache uses the port supplied by the client if
* any is supplied, and finally the default port for the
protocol
* used.
*/
port = r-server-port ? r-server-port :
r-connection-local_addr-port ?
r-connection-local_addr-port
ap_default_port(r);
}
/* default */
return port;
}
This doesn't seem like coming from headers, but rather from URL or as
indicated by the server itself. What do you think?
Bojan
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Spec question: RE BUG 12052
Quoting Bill Barker [EMAIL PROTECTED]: Not anymore. ;-) In the current 2.4 spec draft it is required to be taken from the Host header. Huh, I guess that's that then. The bug does seem to be valid. At least according to the newer spec. Bojan - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Chuid - merging code from daemon into jk2
Quoting [EMAIL PROTECTED]: In order to change the uid from root to a regular user, you will add user.name=... user.group=... in jk2.properties. I'm not too familiar with this - which part here is running as root? Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Chuid - merging code from daemon into jk2
Quoting Costin Manolache [EMAIL PROTECTED]: Bojan Smojver wrote: Quoting [EMAIL PROTECTED]: In order to change the uid from root to a regular user, you will add user.name=... user.group=... in jk2.properties. I'm not too familiar with this - which part here is running as root? If you want to start tomcat on port 80, you need to start it as root so it can open the socket - but need to drop the priviledges for security. OK, thanks. It obviously doesn't affect me as I never run Tomcat as the web server on port 80. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat 4.1.9 rpms available
Legend! Bojan On Thu, 2002-08-22 at 18:37, Henri Gomez wrote: The TC 4.1.9 beta rpms are available : http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.9-beta/rpms/ Nota that we share now the rpms with the jpackage project (www.jpackage.org), so for those of you who want to rebuild source rpms, you should go to jpackage site to get the required rpms. Enjoy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jtc rpms
On Tue, 2002-08-20 at 18:56, Henri Gomez wrote: Quoting Bojan Smojver [EMAIL PROTECTED]: On Tue, 2002-08-20 at 00:50, Henri Gomez wrote: Welcome back from holidays, Thanks hope you had a good time... Rainy ;[ Sorry to hear that :-( Yes, with latest Apache 2.0, modules should be compiled against the proper Apache 2.0, so if you have a mod_jk built against 2.0.39, you need to recompile it to make use of jk under Apache 2.0.40 ;( It will be a pain for many distributions and modules maintainers (binary), so I hope HTTP 2.0 team will relax it a little or consider version update and functionnalities updates. I was hoping it was a temporary thing. Otherwise it truly looked like a nightmare... Yes, ie mod_jk-1.2.0-apache-2.0.40.so Yep, exactly. I agree, and we refer to the jtc tag name instead of a particular tomcat version. You could use mod_jk 1.2.0 tagged at tc 4.1.9 time with tc 3.3.1 That's right. On packaging, the file explaining the compatibility might also be included in the RPM itself. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jtc rpms
On Tue, 2002-08-20 at 00:50, Henri Gomez wrote: Welcome back from holidays, hope you had a good time... I propose to create a snapshot subdir in jtc, snapshot, and provide here the necessary binaries, for example Linux rpms .so, windows, netware, iis are welcome also. http://jakarta.apache.org/builds/jakarta-tomcat-connectors/snapshot/rpms/ We could have right now : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/snapshot/v4.1.9-beta/ rpms/ What do you think about that ? I think this is generally a good idea but I just wanted to clear another possible source of confusion. Is there some sort of dependency between modules and Apache 2.0.x versions? I ran into this with mod_jk 1.2.0 from CVS (i.e. had to rebuild the module when the version of Apache was bumped from 2.0.39 to 2.0.40). I almost always do static linking, but I was wandering if that applies to DSO's as well (my experience with building PHP 4.2.2 tells me it does). If so, I think we should also clearly mark what Apache version that particular module is for. Also, do we need to tie JTC to a particular Tomcat version, like in your example to 4.1.9? My understanding is that the web server (Apache) part doesn't care much about what's behind it, as long as it speaks the correct protocol version. Maybe there should be a README file instead, listing all known Tomcat version combos for a particular JTC version... Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [COMMENT] mod_jk2 reverse mappings
Neat :-) Bojan On Thu, 2002-08-15 at 19:43, Mladen Turk wrote: Hi, Some comments regarding reverse uri mappings. This is the simplest way of accomplishing the reverse mapping (I'm not sure if this is correct terminology). There is additional option for the uri map configuration 'reverse' : [uri:/examples/*.gif] info=Extension mapping reverse=1 All the 'normal' mappings are skipped for such a directive, so first we will map the /examples context. The second call to the mapUri will check only the 'reverse' flagged uri mappings. If both are mapped then the DECLINED is returned, meaning that we mapped the context but don't wish to map the *.gif files in the context. The drawback is that we are calling the mapUri twice, first for positive and then for negative mappings. Of course this could be accomplished in the single call using regular expressions, with all the drawbacks using pcre. MT. -- 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: uri_map using regex [WAS: mod_jk, mod_jk2 URI spaces]
I think I understand what you're saying here and it will probably be necessary for non-Apache web servers anyway. I was thinking more along the lines of: 1. Anything you want to disallow for TC, rewrite to Apache visible filenames and/or URL's (in your example, image files). Apache will then happily serve them. 2. Anything else, rewrite to URL that match something that's in mod_jk's space. Bojan On Sat, 2002-08-10 at 16:31, Mladen Turk wrote: -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Saturday, August 10, 2002 2:04 AM To: Tomcat Dev List Subject: Re: uri_map using regex [WAS: mod_jk, mod_jk2 URI spaces] Doesn't mod_rewrite do what you want here? In combination with mod_proxy, it can rewrite URL to URL as well, so you can get the resulting URL back in mod_jk and then just use normal mappings. Or maybe I'm on a totally wrong track here... True (I think) for the positive assertions, but: [uri:/examples/*] #matches entire app [uri:/examples/(?!\.(gif|jpe?g|png)$)] #matches everything except .gif, .jpg, .jpeg, .png The entire purpose is to be able to _disallow_ certain mappings in the already mapped application. I'm afraid that the mod_proxy cannot be used for such a thing, cause the first mapping will forcibly drive all the examples context through the TC. At first I was trying (before the pcre idea) to use the simple matching like : [uri:/examples/*] [uri:!/examples/*.jpg] ...etc This is can be parsed without using pcre (using apr_fnmatch), but what about more complex schemas involving directories and file extensions, not only files. On the other hand, we can use the mod_rewrite/mod_proxy only with the Apache, and we want to be portable thought. MT. -- 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: uri_map using regex [WAS: mod_jk, mod_jk2 URI spaces]
Doesn't mod_rewrite do what you want here? In combination with mod_proxy, it can rewrite URL to URL as well, so you can get the resulting URL back in mod_jk and then just use normal mappings. Or maybe I'm on a totally wrong track here... As for IIS, dunno, don't care ;-) Bojan On Fri, 2002-08-09 at 21:07, Mladen Turk wrote: Hi, Remember the last month advanced URI space resolution I proposed? Well, I've been working on that for a week or so, and found myself doing things that are more or less regular expression matching of request uri. Even existing uri_map code has a trace of that (matching star for example), so IMO (since we are matching things) we could use the regex code as a general uri-file space matching solution. That way the users will be able to use the same syntax as for the LocationMatch or mod_proxy, allowing one to make complex uri resolutions, like TRUE/FALSE cases. The major drawback of that is that we'll need the pcre library, either one that comes with the Apache 2 (by Philip Hazel) or Apache 1.3 (by Henry Spencer). Since the same should be used with the IIS and other platforms, I suggest that we use the one from Apache 2.0. Using pcre will introduce the need for build process changes (only 2.0 can use the proposed pcre from its own build) and we'll need the pcre.lib. Thoughts? MT. -- 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: mod_jk, mod_jk2 URI spaces
On Wed, 2002-07-31 at 23:55, Mladen Turk wrote: Now I propose that we make something like _not_ URI space filtering. Meaning that one could be able to serve every .html file through TC except for the /*/some_space/ location. Right now we are checking and hoping that the TC will accept the context, and then we forget that immediately. I propose that we make the map_to_storage two way (If the TC accepts it and then checking if the Apache configuration rejects it). This above sentence is confusing. You probably meant configuration options as a series of include/exclude switches, rsync style. After I read my mail, it doesn't make sense even for me :) For example (what I have in mind) using mod_jk: JkMount /examples/* (This will map /examples URI space and everything belonging to the /examples will be served by the TC). JkNotMount /examples/*.gif JkNotMount /examples/*.jpg (This will map /examples URI space and everything will be served by the TC except the gif and jpg files). I see your point here. You are running a setup where anything not specifically targeted for Apache goes to Tomcat. As long as this doesn't affect current situation (and I don't see how it would) where I can set up that Tomcat only gets what's not specifically targeted for Apache, I'm +1. This would make mod_jk configuration really flexible. Bojan PS. Given 1.2.0 is due for a release when Henri comes back from holidays (in about 2 weeks time), are you planning the patches for this before of after the release? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: mod_jk, mod_jk2 URI spaces
Cool! Bojan Quoting Mladen Turk [EMAIL PROTECTED]: -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 01, 2002 12:00 AM To: Tomcat Dev List Subject: RE: mod_jk, mod_jk2 URI spaces This above sentence is confusing. You probably meant configuration options as a series of include/exclude switches, rsync style. Yes something like that. This will allow to serve the compiled applications and still deliver the static context from those locations, overlaying Apache URI space (if set) over already resolved TC uri space. Well, at least the configuration will be IMHO easier. PS. Given 1.2.0 is due for a release when Henri comes back from holidays (in about 2 weeks time), are you planning the patches for this before of after the release? After 1.2.0, If I figure out how to do that cross-server. I'll make that for jk2 first, I hope :). MT. -- 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: Mod_jk for Apache2.
On Mon, 2002-07-29 at 19:49, Simon Stewart wrote: Another spanner: the default anonymous cvs checkout of the current mod_jk2 doesn't build on linux. This is because the OS doesn't appear to get detected properly, meaning that the system dependent jni_md.h file isn't included in the native build's includes. This is probably a known issue, but a quick search doesn't appear to reveal any hits. Shall I post a proper bug report? By all means. Unless, of course, you can find such bug in Bugzilla already. If you attach a patch with the bug report, it will get fixed sooner... Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 mod_jk.c
Since there were no complaints within 24 hours, I went ahead and committed the patch. This should bring mod_jk 1.2.0 for Apache 1.3.x in line with mod_jk 1.2.0 for Apache 2.0.x. In other words, ForwardDirectories is not a no-op any more. I have tested the patch and it does work in my environment. Please test and let me know if anything is broken or just plain unacceptable. Bojan Quoting [EMAIL PROTECTED]: bojan 2002/07/29 19:13:05 Modified:jk/native/apache-1.3 mod_jk.c Log: Introduce a working ForwardDirectories implementation into mod_jk 1.2.0 for Apache 1.3.x. Major changes: - mod_jk requires mod_dir - jk_fixups() function introduced - jk_translate() knows how to handle ForwardDirectories - jk_server_conf_t has a new field -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ForwardDirectories option with mod_jk 1.2.0/Apache 1.3.x
Quoting Bojan Smojver [EMAIL PROTECTED]:
2. Make explicit request from jk_fixups (new function)
Actually, this would break Apache completely, because serving requests from
non-handlers is not allowed. However...
I have developed solution for this problem involving this:
---
- declare:
extern module dir_module;
- copy the typedef from mod_dir:
typedef struct dir_config_struct {
array_header *index_names;
} dir_config_rec;
- introduce jk_fixups function (this runs after jk_translate):
- this function checks if this is a sub-request, and if yes
- checks if ForwardDirectories is set, and if yes
- then it determines if this is the last file mentioned in DirectorIndex
- if yes and still no worker is set (i.e. we exhausted all index options)
- sets r-uri=r-main-uri (the directory in question)
- sets r-finfo.st_mode=S_IFREG, to trick mod_dir to serve
- sets r-main-handler to JK_HANDLER
- jk_translate gets these changes:
- if map_uri_to_worker can't find the worker and
- if r-prev exists and
- if r-prev-handler is JK_HANDLER and
- if r-uri is a directory
- picks the default worker, which then causes the request to go to Tomcat
---
The dirty part is:
- mod_jk would depend on mod_dir being present
- one typedef from mod_dir is copied into mod_jk
I'd like to get comments on this before I commit. I have tested this fix and it
works, but I wouldn't like to introduce a solution that breaks things for some
people or is too ugly. mod_dir is a standard module and it gets compiled in by
default, so I don't think there would be too many people without it. However,
there is always an odd configuration somewhere...
There are also other, minor changes to the code, like making sure that the
structure holding worker_env isn't freed straight after it gets created. We now
need it later to determine the default worker in case we are forwarding directories.
Bojan
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Mod_jk for Apache2.
On Sat, 2002-07-27 at 02:36, Mike Anderson wrote: Now that Apache 2.0 has been released, when/how should we deliver the mod_jk plugin (the 1.2.0 version from jtc) for Apache 2.0. Since the magic number changes between builds, we can't put a version out there that will work with all possible versions. Should we just try and keep up with the current Apache 2.0 (currently 2.0.39)? Anything below 2.0.39 has security issues and should not be used in production. So, it shouldn't even be supported. 2.0.39 should be the starting point. Should we update all of the possible tomcat releases (currently 3.2.4, 3.3.1, 4.0.4, 4.1.7 Beta) when Apache updates? I reckon that's going to be a lot of work. Unless there are security issues, we should focus on what's current. In other words, the current stable version from each branch. Anything else, build from source or use the old version. If someone contributes a binary, then by all means, it should be published, but otherwise it shouldn't be a target. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [connectors] compile error on jk_jni_aprImpl.c
Try running: ./buildconf.sh ./configure --apxs2=/path/to/apxs and then just dump the mod_jk2.so (should be in jk/build/jk2/apache2) into your Apache *.so directory, apply the appropriate LoadModule and you should be set. I had problems building with ant too... Bojan On Wed, 2002-07-24 at 17:24, Dev Zero G Ltd wrote: PLEASE help, I've batting with this one for 2 days solid now What should I do with this? Submit it as a bug? Or am I doing something wrong? Freebsd 4.4, Apache 2.0.39, Tomcat 4.0.4, jakarta-tomcat-connectors sources from cvs, i.e. latest.. Mike --- snip --- Compiling /usr/tmp/jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c [so] Compile failed 1 /usr/tmp/jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c [so] Command:libtool --mode=compile cc -c -o /usr/tmp/jakarta-tomcat-connectors/jk/build/jk2/apache2/jni/jk_jni_aprImpl.o -I/usr/tmp/jakarta-tomcat-connectors/jk/native2/common -I/usr/local/apache2/include -I/usr/local/apache2/include -I/usr/local/apache2/include -I/usr/tmp/jakarta-tomcat-connectors/jk/native2/include -I/usr/local/linux-jdk1.4.0/jre/../include -I/usr/local/linux-jdk1.4.0/jre/../include/linux -g -W -D_REENTRANT -DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAVE_JNI /usr/tmp/jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c [so] Output: [so] mkdir /usr/tmp/jakarta-tomcat-connectors/jk/build/jk2/apache2/jni/.libs [so] cc -c -I/usr/tmp/jakarta-tomcat-connectors/jk/native2/common -I/usr/local/apache2/include -I/usr/local/apache2/include -I/usr/local/apache2/include -I/usr/tmp/jakarta-tomcat-connectors/jk/native2/include -I/usr/local/linux-jdk1.4.0/jre/../include -I/usr/local/linux-jdk1.4.0/jre/../include/linux -g -W -D_REENTRANT -DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAVE_JNI /usr/tmp/jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c -fPIC -DPIC -o /usr/tmp/jakarta-tomcat-connectors/jk/build/jk2/apache2/jni/.libs/jk_jni_aprImpl.lo [so] StdErr: [so] In file included from /usr/tmp/jakarta-tomcat-connectors/jk/native2/include/jk_env.h:71, [so] from /usr/tmp/jakarta-tomcat-connectors/jk/native2/include/jk_pool.h:67, [so] from /usr/tmp/jakarta-tomcat-connectors/jk/native2/include/jk_map.h:67, [so] from /usr/tmp/jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c:78: [so] /usr/tmp/jakarta-tomcat-connectors/jk/native2/include/jk_mutex.h:122: syntax error before `apr_thread_mutex_t' BUILD FAILED file:/usr/tmp/jakarta-tomcat-connectors/jk/native2/build.xml:276: Compile failed /usr/tmp/jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c -- 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: [VOTE]: Re: cvscommit:jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
On Wed, 2002-07-24 at 18:26, Henri Gomez wrote: I can live with any but the first. It would be nice to have it as a config option however. JkOptions is probably fine for 1.2. Not sure where it should be set in Jk2. Thanks. I'm not sure about mod_jk2 either. The latest reports show that the code still doesn't work. Great to have it in jk 1.2.x. BTW, what's the default behaviour ? Default is to let Apache do it's thing. Bojan -- 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.0 mod_jk.c
Quoting [EMAIL PROTECTED]: It's jk_translate who decides if a request is to be handled by jk ( by mapping it to a uriEnv ). You can add a test for r-handler==DIR_MAGIC_TYPE, but don't assume any uriEnv is set. Actually, r-handler is always NULL in jk_translate(). At least in mod_jk 1.2.0 (but I'm suspecting that would be the case in mod_jk2 as well, because it's Apache that determines that). So, adding the test wouldn't do anything. If DirectoryIndex is not used, by the time jk_handler() is reached with DIR_MAGIC_TYPE, we're out of mod_dir. If DirectoryIndex is used, then we end up in jk_handler() much sooner, by an explicit call from within mod_dir. That's, of course, when a static file exists. In none of the cases is r-handler set while in jk_translate(). So, for now, I think the only option is to rely on DIR_MAGIC_TYPE test in jk_handler(). How's that going to work in mod_jk2, I have no idea... Hopefully, Mark will do a few tests and then we'll know more. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[VOTE]: Re: cvs commit:jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
And I answer (to myself :-)
On Tue, 2002-07-23 at 14:47, Bojan Smojver wrote:
So, the unsolved questions for me are:
1. What is it then that jk_handler() does that makes it actually serve the
request when DIR_MAGIC_TYPE is included in the test? It must be that its mapping
is 'better' than mapping of jk_translate()...
Nothing special - it just does it ALWAYS. Which means that Tomcat ALWAYS
gets involved, which is NOT what Bill wanted (sorry Bill) and is
definitely not what I wanted. In order to fix that and let Apache handle
the directories it can physically see, and give the rest to Tomcat, we'd
need to do this at the beginning of jk_handler():
-
/* Deciding if this request is for us, or should we pass it on */
if(strcmp(r-handler,JK_HANDLER)){
if(strcmp(r-handler,DIR_MAGIC_TYPE)) /* Not directory, skip */
return DECLINED;
else if(ap_is_directory(r-pool, r-filename)) /* Can stat, skip */
return DECLINED;
}
-
Which would then mean that you MUST have DirectoryIndex in place if you
have extension mappings and want your physically accessible files served
by Tomcat. It would also mean that all physically accessible
directories, without ANY index files mentioned in DirectoryIndex, would
be served by Apache. Anything else would go to Tomcat for resolution.
This is not ideal and maybe not even correct, but it is the best I can
come up with at this point.
Before I make any changes to the CVS, I'd like to know what everyone
thinks. So, here are the choices:
[ ] Keep it as is and send all DIR_MAGIC_TYPE requests to Tomcat
[ ] Keep it as is, but only if DIR_MAGIC_TYPE can be turned on/off
[ ] Remove DIR_MAGIC_TYPE handling altogether
[ ] Make the change
[ ] Make the change, but only if DIR_MAGIC_TYPE can be turned on/off
2. Or is it that jk_translate() never even gets involved during that request and
therefore never has the chance to do the mapping?
I answered this one before. The request with DIR_MAGIC_TYPE never
touches jk_translate().
Bojan
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE]: Re: cvs commit:jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
On Tue, 2002-07-23 at 23:39, Henri Gomez wrote: Before I make any changes to the CVS, I'd like to know what everyone thinks. So, here are the choices: [ ] Keep it as is and send all DIR_MAGIC_TYPE requests to Tomcat [ ] Keep it as is, but only if DIR_MAGIC_TYPE can be turned on/off [ ] Remove DIR_MAGIC_TYPE handling altogether [ ] Make the change [ ] Make the change, but only if DIR_MAGIC_TYPE can be turned on/off For someone who have all its tomcat behind a webserver, I'll be to have the requests sent to Tomcat since my web servers won't have a directory created for all the webapps available on tomcats farms behind. If you don't have the directories that Apache can see, then this latest change would still work for you (i.e. anything that is not an explicit index page like index.jsp or a directory goes to Tomcat). So, I'm guessing this would be a vote for 'Make the change'. Alternativly I don't want to receive index.php or index.pl in Tomcat, and so want only the one which match with JkMount (in mod_jk 1.2 way), ie JkMount *.jsp ajp13. That would be handled by Apache anyway through the usual DirectoryIndex machinery, so no problems there. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE]: Re: cvscommit:jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
On Wed, 2002-07-24 at 06:47, Bill Barker wrote: Before I make any changes to the CVS, I'd like to know what everyone thinks. So, here are the choices: [ ] Keep it as is and send all DIR_MAGIC_TYPE requests to Tomcat [ ] Keep it as is, but only if DIR_MAGIC_TYPE can be turned on/off [ ] Remove DIR_MAGIC_TYPE handling altogether [ ] Make the change [ ] Make the change, but only if DIR_MAGIC_TYPE can be turned on/off I can live with any but the first. It would be nice to have it as a config option however. JkOptions is probably fine for 1.2. Not sure where it should be set in Jk2. Thanks. I'm not sure about mod_jk2 either. The latest reports show that the code still doesn't work. Bojan -- 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
Since it seems like people have totally different needs in regards to static files and redirection of 'ambiguous' directory requests to Tomcat, I went with the option ForwardDirectories, which can be specified in JkOptions. It is off by default. When turned off, any directory that doesn't contain any of the files specified in DirectoryIndex will be handled by Apache, by whichever module does automatic directory indexing (normally mod_autoindex). When turned on, such requests will be forwarded to Tomcat for resolution. This then gives Tomcat the opportunity to do its magic and serve whatever it pleases, including the contents of the directory, similar to mod_autoindex, or whatever else. This, of course, is only applicable to mod_jk 1.2.0. mod_jk2 still transfers all such requests to Tomcat, I believe. I'll have to learn a great deal more about it in order to apply something like the above to it. Bojan On Wed, 2002-07-24 at 14:48, [EMAIL PROTECTED] wrote: bojan 2002/07/23 21:48:52 Modified:jk/native/apache-2.0 mod_jk.c -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: new velocity user
With pleasure :-) It's actually quite simple: - make sure Velocity JAR file is visible to your application classloader in Tomcat; either put it in your own WEB-INF/lib (for singleton model) of each app or in lib/apps of Tomcat distribution (for non-singleton model) - have a good velocity.properties file and make sure logging location exists and is writeable - use VelocityServlet (supplied with Velocity) to handle requests; or - use any of the framework/servlets available (listed on Velocity web site); I recommend PumpServlet (ftp://ftp.rexursive.com/pub/pump/pump.tar.gz) for purely selfish reasons ;-) - map you servlet in web.xml to your liking - read excellent Velocity User Guide and Velocity Programmers Guide - ask about anything you'd like to know on Velocity user list; majority of the people are very friendly and don't mind being asked questions Have fun, Bojan Quoting sunil [EMAIL PROTECTED]: can anyone help me with instructions for running velocity templates on tomcat ..?? or kindly give some leads for the same .. -- 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 tested this with and without DirectoryIndex. In case there is DirectoryIndex, the physical file(s) are stat and if that's successful mod_dir does its thing. It works nicely for at least 2 different file extensions (in my case *.jsp and *.vm). If the files cannot be stat, it's up the jk_handler() to decide, which covers the cases where there are no physical files present. The requests will still end up in Tomcat if there is a mapping. If there is no DirectoryIndex, jk_handler() makes its own decisions about what's going to get served. Anything that is mapped will end up in Tomcat. Note that this whole thing does not affect real static files like index.html. Tomcat will never serve (or attempt to serve) those, unless they are mapped to Tomcat by some other means, not the extension. So I hope this satisfies all relevant concerns for now. Important note: --- THE CODE IN mod_jk2 IS STILL BROKEN, WITH DocumentRoot LOGIC. - Do you want me to: [ ] Revert it back to what it was before I put my fingers in it [ ] Leave it alone [ ] Attempt to apply the same stuff that's in this patch to it Bojan On Tue, 2002-07-23 at 07:03, [EMAIL PROTECTED] wrote: bojan 2002/07/22 14:03:19 Modified:jk/native/apache-2.0 mod_jk.c Log: Put back DIR_MAGIC_TYPE in case there is no DirectoryIndex and/or no pysical files to stat. Lose one stat, not really needed. Fix a typo. Revision ChangesPath 1.52 +10 -5 jakarta-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.51 retrieving revision 1.52 diff -u -r1.51 -r1.52 --- mod_jk.c22 Jul 2002 02:48:11 - 1.51 +++ mod_jk.c22 Jul 2002 21:03:19 - 1.52 -- 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
Before I do that, some questions about uriEnv in jk2_handler(), since that part is very different to mod_jk. The initial test involves asking: if (uriEnv==NULL || strcmp(r-handler,JK_HANDLER)!= 0) and if so, the whole thing is skipped. After the first test, there is the second test that goes: if( uriEnv == NULL ) Obviously, that's not possible, since the first test would kick us out of the function. But, in case the first test was changed to not involve asking if uriEnv is null, the the code after the second test would hit a NULL pointer here: if( uriEnv-mbean-debug 0 ) How do I go through this mine field? What's going to be the value of uriEnv if r-handler is DIR_MAGIC_TYPE? If it's going to be NULL, I have to change a lot of code in the whole function to make sure we don't bump into a NULL pointer somewhere... Bojan On Tue, 2002-07-23 at 07:44, [EMAIL PROTECTED] wrote: On 23 Jul 2002, Bojan Smojver wrote: Important note: --- THE CODE IN mod_jk2 IS STILL BROKEN, WITH DocumentRoot LOGIC. - Do you want me to: [ ] Revert it back to what it was before I put my fingers in it [ ] Leave it alone [+1] Attempt to apply the same stuff that's in this patch to it 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/native/apache-2.0mod_jk.c
I made an initial, most likely broken commit of this code for mod_jk2. Can you go through it as I'm making assumptions in there that I am not sure about. They are just a parallel from mod_jk, but that could be totally bogus. At least there is some 'meat' for you guys to play with. Bojan On Tue, 2002-07-23 at 07:44, [EMAIL PROTECTED] wrote: On 23 Jul 2002, Bojan Smojver wrote: Important note: --- THE CODE IN mod_jk2 IS STILL BROKEN, WITH DocumentRoot LOGIC. - Do you want me to: [ ] Revert it back to what it was before I put my fingers in it [ ] Leave it alone [+1] Attempt to apply the same stuff that's in this patch to it 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/native/apache-2.0 mod_jk.c
Quoting [EMAIL PROTECTED]: It's jk_translate who decides if a request is to be handled by jk ( by mapping it to a uriEnv ). You can add a test for r-handler==DIR_MAGIC_TYPE, but don't assume any uriEnv is set. OK, I did that in jk2_handler(), which now seems like the wrong place to do it, and I also tried to make sure uriEnv is populated, but I don't think I'm picking it from the correct spot (if it makes any difference at all). I did: - ap_get_module_config(r-server-module_config, jk2_module); - where I maybe should have done: - ap_get_module_config(r-per_dir_config, jk2_module); - Honestly, I don't understand neither mod_jk2 (surprise :-) nor Apache2 enough to make a decision about that. So, I'll leave this up to you guys to correctly identify. However, the most confusing part of this whole business is this (I'll ask this in terms of mod_jk, but it should be similar for mod_jk2): If jk_translate() is the one mapping requests and also in charge of setting the value of r-handler (which will later on be used by jk_handler() to recognise that this as something for Tomcat and eventually serve the request), that would mean that it must have recognised the requested URI that had r-handler==DIR_MAGIC_TYPE as the one that should be mapped too. I don't see anything in the code that would discriminate on the basis of r-handler, except for manual mappings, which does not include DIR_MAGIC_TYPE. So, the unsolved questions for me are: 1. What is it then that jk_handler() does that makes it actually serve the request when DIR_MAGIC_TYPE is included in the test? It must be that its mapping is 'better' than mapping of jk_translate()... 2. Or is it that jk_translate() never even gets involved during that request and therefore never has the chance to do the mapping? 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
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]
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]
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/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]
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]
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/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]
Re: [PROPOSAL] Split the repo's
On Fri, 2002-07-19 at 00:16, [EMAIL PROTECTED] wrote: I'm pretty sure Jon is not proposing this for the benefit of tomcat or tomcat users, but out of his hate for JSPs. What's wrong with that? ;-)) 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 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: mod_jk config options - some elaboration, please?
On Thu, 2002-07-18 at 15:06, Eddie Bush wrote: Is it possible there will be any movement at any time to incorporate the (much more) excellent documentation that existed with the 3.x TC versions into the 4.x doc sets? I think it might really reduce the traffic on tomcat-user - and I would imagine it could only reduce the traffic on tomcat-dev too ;-). I think there is a lot of work going into mod_jk and mod_jk2 in recent days, especially when it comes to TC 4.x. So, it's just a matter of time before such documentation arrives. 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]
[BUGS: 9913, 10789] Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
I've looked through Mark's excellent analysis of the problem (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10789) and I also played with changing the hook order for mod_jk 1.2.0. Are you sure this actually fixes the thing? My experience from 1.2.0 is similar to Mark's with 2.x - the handler never gets called because the r-handler is DIR_MAGIC_TYPE, not JK_HANDLER. So, I think Mark's code would be the real fix for both - giving Apache a hint that the handler is JK_HANDLER. My original 'fix' (more like a kludge) for 1.2.0 doesn't do that. It waits for the next round, accepts the DIR_MAGIC_TYPE call, where r-uri isn't the correct file (i.e. it is not /some/path/index.jsp), but rather a directory (/some/path/), which then causes havoc down the line in getServletPath(). Tomcat 3.3.x is smart and it corrects that for JSP's. I'm not sure if TC 4.x does that at all (I have seen at least one other report related to bug 9913 with TC 4.x where my 'fix' didn't actually fix the problem - some fix :-). Mladen, what's your take on all this? Do you have a setup handy to verify that the changing of hook ordering fixed the problem in mod_jk2? Mark, does the fix in mod_jk2 work in your environment? Bojan PS. Sorry guys, this one is *really* bugging me... Quoting [EMAIL PROTECTED]: mturk 2002/07/18 08:15:00 Modified:jk/native2/server/apache2 mod_jk2.c Log: Fix the bug 10789 caused by hook order. Revision ChangesPath 1.42 +3 -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.41 retrieving revision 1.42 diff -u -r1.41 -r1.42 --- mod_jk2.c 17 Jul 2002 22:43:58 - 1.41 +++ mod_jk2.c 18 Jul 2002 15:15:00 - 1.42 @@ -724,8 +724,8 @@ ap_hook_handler(jk2_handler, NULL, NULL, APR_HOOK_MIDDLE); ap_hook_post_config(jk2_post_config,NULL,NULL,APR_HOOK_MIDDLE); ap_hook_child_init(jk2_child_init,NULL,NULL,APR_HOOK_MIDDLE); -ap_hook_translate_name(jk2_translate,NULL,NULL,APR_HOOK_FIRST); -ap_hook_map_to_storage(jk2_map_to_storage, NULL, NULL, APR_HOOK_MIDDLE); + ap_hook_translate_name(jk2_translate,NULL,NULL,APR_HOOK_MIDDLE); +ap_hook_map_to_storage(jk2_map_to_storage, NULL, NULL, APR_HOOK_FIRST); } module AP_MODULE_DECLARE_DATA jk2_module = -- 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: [BUGS: 9913, 10789] Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c
Quoting Mark Miesfeld [EMAIL PROTECTED]:
I was just getting ready to post something saying the fix seems to
break mod_jk2 altogether for me.
Interesting. I haven't actually checked explicit calls to pages with reversed
order and mod_jk 1.2.0, so I don't really know if that breaks it or not. Will
test tonight (Sydney time).
For one thing, I think, if jk2_map_to_storage is invoked before
jk2_translate then mod_jk2 is going to return DECLINED all the time.
Which is what I am seeing. Nothing gets sent over to tomcat.
For example:
jk2_map_to_storage( ) ENTER
Unparsed uri: /tomcat/examples
request_rec:009D79A8
Return DECLINED
jk2_map_to_storage( ) ENTER
Unparsed uri: /tomcat/examples/
request_rec:009D79A8
Return DECLINED
jk2_map_to_storage( ) ENTER
Unparsed uri: /tomcat/examples/index.html
request_rec:009D59A0
Return DECLINED
jk2_map_to_storage( ) ENTER
Unparsed uri: /tomcat/examples/index.jsp
request_rec:009D59A0
Return DECLINED
jk2_handler( )ENTER
Unparsed uri: /tomcat/examples/
request_rec:009D79A8
uriEnv:
Return DECLINED
In jk2_map_to_storage the start of the code is:
jk_uriEnv_t *uriEnv=ap_get_module_config( r-request_config,
jk2_module );
if( uriEnv != NULL ) {
but the only calls to
ap_set_module_config( r-request_config, jk2_module, uriEnv );
are in jk2_translate.
So, it seems to me that jk2_translate needs to be invoked before
jk2_map_to_storage. Which is what I thought the original order was.
But I have to confess I really do not understand APR_HOOK_MIDDLE,
APR_HOOK_FIRST, etc.
I don't really understand Apache all that well, but the API documentation talks
about 'Controlling hook calling order'. From 'Apache Hook Functions' document:
...all modules using HOOK_FIRST will run before the HOOK_MIDDLE which are
before HOOK_LAST. If the order is unimportant, HOOK_MIDDLE is recommended.
Anyhow, the bottom line is that on my machine doing a clean and then
rebuilding tomcat and mod_jk2 using the latest
jakarta-tomcat-connectors
from cvs, leaves me with mod_jk2 not sending anything on to tomcat.
OK. I'll try your solution with mod_jk 1.2.0 and mod_jk2 people might do the
same. I don't really like my fix in 1.2.0 because it's just a cheap hack and it
doesn't address the root cause of the problem
The reason why it didn't work in mod_jk2 is the fact that the test was wrong. It
should have been:
---
if((uriEnv==NULL || strcmp(r-handler,JK_HANDLER))
strcmp(r-handler,DIR_MAGIC_TYPE)))
return DECLINED;
---
But even that probably wouldn't work with TC 4.x because getServletPath() would
start returning strange things. I think your approach is much better.
Bojan
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mod_jk2: bug 10789
Costin, Mladen, could you guys have a look into this. The fix that I put into mod_jk 1.2.0 works fine and default pages do get picked up. A symmetric fix for mod_jk 2 did not work for Mark, the original bug reporter, so I reverted it. CVS versions 1.40 and 1.41 of mod_jk2.c are the ones in question. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk config options - some elaboration, please?
You can check out this: http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ssl-howto.html I'm sure that the definitive list of options can be found in the source. Bojan Quoting Eddie Bush [EMAIL PROTECTED]: Hi, could someone tell me the function of the following, please? JkExtractSSL On JkHTTPSIndicator HTTPS JkSESSIONIndicator SSL_SESSION_ID JkCIPHERIndicator SSL_CIPHER JkCERTSIndicator SSL_CLIENT_CERT Is there, anywhere, a _definitive_ list of all of the options you may use for mod_jk, and their associated meaning? It would be really handy to finally figure this connector out entirely - or, at least, figure out where to look for the answers. I know you guys keep busy, but, if you could just point me in the right direction of where to look, I'd really appreciate it. Thanks, Eddie -- 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: [VOTE] Apache Tomcat 5.0 Proposal
On Wed, 2002-07-03 at 09:57, Remy Maucherat wrote: ballot [ ] +1 I support the proposal, and will help implement it [X] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: /ballot Which might actually turn out to be +0.01 ;-) Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PROPOSAL] removing outdated makefile/buildfile for mod_jk 1.2.0
If you're referring to statically linking mod_jk into Apache 1.3.x, then I can confirm that it works just fine. I've been running that configuration for quite some time now. Bojan On Mon, 2002-07-01 at 18:53, GOMEZ Henri wrote: Ok, I'll remove them so, and will update the build documentation (in xdocs). BTW, who could tell us more about mod_jk 1.2.x static build ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 29, 2002 5:19 AM To: Tomcat Dev List Subject: Re: [PROPOSAL] removing outdated makefile/buildfile for mod_jk 1.2.0 As long as configure/make works I'm +1. Bojan On Fri, 2002-06-28 at 22:39, GOMEZ Henri wrote: Hi, What about removing all the outdated makefile and build.platform.sh present in jk/native now that we have a working configure/makefile or ant/jkant ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- 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] -- 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: index.*: mod_jk 1.2.0 vs. Apache 2.0.36
Yes, pretty much. I'm guessing that Apache will try it's own page types first (index.shtml, index.html etc.) and if if doesn't find any, pass the request to Tomcat (through mod_jk) for index.jsp and then index.vm (in that order, since that's how it's specified in DirectoryIndex). Just for the record, the server displayed the content of the directory (this is on the test machine where that's allowed). When I put explicit URL in the address field of the brower (e.g. http://www.testsite.dev/index.vm) it does work (i.e. Tomcat picks up the servlet that handles *.vm pages etc.). Bojan On Wed, 2002-06-19 at 18:23, GOMEZ Henri wrote: The question is : What should do http server ? forward to tomcat /index.jsp and if it fail, try next to forward /index.vm ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 19, 2002 1:19 AM To: Tomcat Dev List Subject: RE: index.*: mod_jk 1.2.0 vs. Apache 2.0.36 It doesn't work in either case. In this case it should be index.vm, since that's the file that exists in the directory. Bojan On Tue, 2002-06-18 at 19:58, GOMEZ Henri wrote: question. Should mod_jk forward to tomcat index.jsp or index.vm ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Monday, June 17, 2002 1:11 PM To: Tomcat Dev List Subject: index.*: mod_jk 1.2.0 vs. Apache 2.0.36 I've submitted a bug regarding this (9913) since it still appears to be there in the above combo. This should be very simple to test (you just whack an index.jsp in a directory), so if someone can confirm that my configuration is brain-dead (because this is such an unlikely bug :-), that would be nice. 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] -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: index.*: mod_jk 1.2.0 vs. Apache 2.0.36
On Wed, 2002-06-19 at 18:45, GOMEZ Henri wrote: Hum, I think the problem should be easier to detect (I hope so) Yeah, I agree. I actually think that my configuration could be screwed somewhere, somehow (although I don't see how) because almost all Apache 2.0.x/Tomcat 3.3.x users would run into this kind of problem... Bojan -- 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
Thanks. I'll download an retest. Bojan On Thu, 2002-06-13 at 00:33, GOMEZ Henri wrote: This should fix the problem reported by Bojan. What about tagging jtc for jk_1_2_0 release ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 12, 2002 4:31 PM To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c hgomez 2002/06/12 07:31:09 Modified:jk/native/apache-2.0 mod_jk.c Log: Fix the incorrect error reported when a worker is defined but didn't exist (reported by Bojan) Revision ChangesPath 1.45 +4 -1 jakarta-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.44 retrieving revision 1.45 diff -u -r1.44 -r1.45 --- mod_jk.c 8 May 2002 00:45:33 - 1.44 +++ mod_jk.c 12 Jun 2002 14:31:09 - 1.45 @@ -1324,6 +1324,9 @@ return OK;/* NOT r-status, even if it has changed. */ } } + else + return HTTP_INTERNAL_SERVER_ERROR; + } return DECLINED; -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New Committer Mladen Turk
+1 Bojan On Mon, 2002-06-10 at 20:24, GOMEZ Henri wrote: I'd like to propose Mladen Turk [mturk at mappingsoft.com] as a new Tomcat committer. He does a great job in jk2, also involved in APR, he seems very interested in continuing its contribution on jk2 and java area. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- 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: jk 1.2 freese/snap time in JTC ?
+1 for mod_jk 1.2.0 for Apache 1.3.24. It's been running stable on my systems for a really long time now. Not sure if the bug related to not picking up the index pages when used with Apache 2.0.35 still exists... Anyone knows? To find the thread, search this list for this: 'Apache 2.0.35 and mod_jk 1.2.0'. I've posted the question on 2002-04-07. Bojan On Mon, 2002-06-10 at 23:26, GOMEZ Henri wrote: Did there is still work on progress in JK (native) in JTC ? If not, it could be the good moment to make a 1.2.0 snapshot, and ask contributers/friends to generate binaries on there platforms. Regards - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- 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: [VOTE] New Committer Dan Sandberg
On Fri, 2002-05-24 at 21:00, Pier Fumagalli wrote: I hate to be the PITA, as always, and I don't have anything against Dan or the patches he submitted to SSIServlet, but I believe that this group (as noted on the members meeting this Tuesday) is giving away committer privileges a little bit too easily... Perfectly understand your arguments here - I'm one of those 'one patch' committers. My commits were always driven by selfishness - if something I use is broken in the TC version I use (3.3.x), then I'll attempt to fix it. Otherwise, I'll just cruise along. And since TC 3.3.x is so damn good and stable these days (and does what I want it to do), I just have no motivation to do anything else. Maybe there should be a committer status review every so often? Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
