Re: jk connector error on post.
I believe I have made some progress now. It looks like this is a problem with mod_perl and mod_jk interacting poorly. I haven't investigated why yet, but mod_perl is calling ap_should_client_block in the authentication phase of Apache, which plays havoc with mod_jk's call in the handler. Mod_jk is in the right here, and I'm 99.9% sure that mod_perl isn't making the call, but rather our code is. So, this is my problem. Thanks to everybody who helped. Ryan On Tue, 18 Jan 2005, William A. Rowe, Jr. wrote: > Hi Ryan, fancy meeting up here :) You don't mention, so > I'll confirm - you are using mod_jk 1.2.8 (brand new release)? > This sure sounds like the (rather obscure) issues with re-piping > body content, and taking a simple guess, if you drop back and > force http/1.0 (eliminate chunking) the issue goes away? > > Bill > > At 06:55 PM 1/17/2005, Ryan Bloom wrote: > > >I am trying to get Apache 1.3 and Tomcat 5.0.27 working together. My site > >basically works, but any POST request causes the following error with a > >hex dump: > > > >Jan 17, 2005 3:19:23 PM org.apache.jk.common.HandlerRequest invoke > >SEVERE: Error decoding request > >java.io.IOException > >at > >org.apache.jk.common.JkInputStream.receive(JkInputStream.java:252) > >at > >org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:500) > >at > >org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:352) > >at > >org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743) > >at > >org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:675) > >at > >org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866) > >at > >org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) > >at java.lang.Thread.run(Thread.java:567) > > > > > >I have been unable to get Tomcat to give me more log messages. The web > >pages are very clear that jk2 is no longer in development, so I really > >don't want to go to jk2. but I am at a loss as to where to go from here. > > > >Can anybody suggest a possible solution? > > > >Thanks, > > > >Ryan > > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk connector error on post.
Actually, both 1.2.6 and 1.2.8 of mod_jk. What do you mean re-piping body content? I haven't forced http/1.0 yet, I was about to trace through Apache to find the problem. My initial investigation looks like the problem is in Apache somewhere, looks like ap_setup_client_block/ap_should_client_block. Ryan On Tue, 18 Jan 2005, William A. Rowe, Jr. wrote: > Hi Ryan, fancy meeting up here :) You don't mention, so > I'll confirm - you are using mod_jk 1.2.8 (brand new release)? > This sure sounds like the (rather obscure) issues with re-piping > body content, and taking a simple guess, if you drop back and > force http/1.0 (eliminate chunking) the issue goes away? > > Bill > > At 06:55 PM 1/17/2005, Ryan Bloom wrote: > > >I am trying to get Apache 1.3 and Tomcat 5.0.27 working together. My site > >basically works, but any POST request causes the following error with a > >hex dump: > > > >Jan 17, 2005 3:19:23 PM org.apache.jk.common.HandlerRequest invoke > >SEVERE: Error decoding request > >java.io.IOException > >at > >org.apache.jk.common.JkInputStream.receive(JkInputStream.java:252) > >at > >org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:500) > >at > >org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:352) > >at > >org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743) > >at > >org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:675) > >at > >org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866) > >at > >org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) > >at java.lang.Thread.run(Thread.java:567) > > > > > >I have been unable to get Tomcat to give me more log messages. The web > >pages are very clear that jk2 is no longer in development, so I really > >don't want to go to jk2. but I am at a loss as to where to go from here. > > > >Can anybody suggest a possible solution? > > > >Thanks, > > > >Ryan > > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jk connector error on post.
I am trying to get Apache 1.3 and Tomcat 5.0.27 working together. My site basically works, but any POST request causes the following error with a hex dump: Jan 17, 2005 3:19:23 PM org.apache.jk.common.HandlerRequest invoke SEVERE: Error decoding request java.io.IOException at org.apache.jk.common.JkInputStream.receive(JkInputStream.java:252) at org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:500) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:352) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:675) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:567) I have been unable to get Tomcat to give me more log messages. The web pages are very clear that jk2 is no longer in development, so I really don't want to go to jk2. but I am at a loss as to where to go from here. Can anybody suggest a possible solution? Thanks, Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JDK 1.31??
Granted, but we could have provided more detailed instructions. Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA > -Original Message- > From: Pier Fumagalli [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 20, 2002 10:38 AM > To: Tomcat Developers List > Cc: 'Mark Goddard'; 'Julian Mitchell'; 'Isabella Pighi'; 'Stefano > Mazzocchi'; 'Bellintani Luca'; 'Federico Barbieri' > Subject: Re: JDK 1.31?? > > It was not against Covalent... But rather against the user... Your > instructions were concise and accurate... Even my mother could have > followed > them... If the guy doesn't have a clue of what a Java JDK 1.3.1 is, well, > then he'd better not even touch Tomcat :) :) :) > > Pier > > "Ryan Bloom" <[EMAIL PROTECTED]> wrote: > > > I would just like to state that as I Covalent employee, I disavow all > > knowledge of this completely. :-( > > > > Ryan > > > > -- > > Ryan Bloom [EMAIL PROTECTED] > > 645 Howard St. [EMAIL PROTECTED] > > San Francisco, CA > > > >> -Original Message- > >> From: Pier Fumagalli [mailto:[EMAIL PROTECTED]] > >> Sent: Wednesday, March 20, 2002 10:15 AM > >> To: Tomcat Developers List > >> Cc: Mark Goddard; Julian Mitchell; Isabella Pighi; Stefano Mazzocchi; > >> Bellintani Luca; Federico Barbieri > >> Subject: FW: JDK 1.31?? > >> > >> I believe this _deserves_ greater attention than webmaster... Pearls > > like > >> those come once every year... > >> > >> Pier > >> > >> -- Forwarded Message > >>> From: /* NAME CONCEALED */ > >>> Date: Wed, 20 Mar 2002 11:48:15 -0500 > >>> To: <[EMAIL PROTECTED]> > >>> Subject: JDK 1.31?? > >>> > >>> Hello, > >>> > >>> I purchased a server package from Covalent (over a year ago) that > >> includes an > >>> installation of Tomcat. It doesn't work and all I can get out of > >> Covalent is: > >>> > >>> "Upgrade your jdk to 1.31 and then modify the Tomcat.sh to reflect > > the > >> new > >>> JAVA_HOME and start the server with the covalent script". > >>> > >>> It might as well be Chinese. > >>> > >>> I'm running Red Hat Linux 7.2. > >>> > >>> I checked all the Tomcat and Apache references and I can't find > > anything > >> that > >>> says "JDK 1.31". What are they talking about? A Java JDK? I can't > > find > >>> anything that says "JDK 1.31". > >>> > >>> Please include a copy of this message with your reply. > >>> > >> -- End of Forwarded Message > >> > >> > >> -- > >> To unsubscribe, e-mail: <mailto:tomcat-dev- > >> [EMAIL PROTECTED]> > >> For additional commands, e-mail: <mailto:tomcat-dev- > >> [EMAIL PROTECTED]> > > > > > > > > -- > > To unsubscribe, e-mail: <mailto:tomcat-dev- > [EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:tomcat-dev- > [EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: <mailto:tomcat-dev- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:tomcat-dev- > [EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
RE: JDK 1.31??
I would just like to state that as I Covalent employee, I disavow all knowledge of this completely. :-( Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA > -Original Message- > From: Pier Fumagalli [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 20, 2002 10:15 AM > To: Tomcat Developers List > Cc: Mark Goddard; Julian Mitchell; Isabella Pighi; Stefano Mazzocchi; > Bellintani Luca; Federico Barbieri > Subject: FW: JDK 1.31?? > > I believe this _deserves_ greater attention than webmaster... Pearls like > those come once every year... > > Pier > > -- Forwarded Message > > From: /* NAME CONCEALED */ > > Date: Wed, 20 Mar 2002 11:48:15 -0500 > > To: <[EMAIL PROTECTED]> > > Subject: JDK 1.31?? > > > > Hello, > > > > I purchased a server package from Covalent (over a year ago) that > includes an > > installation of Tomcat. It doesn't work and all I can get out of > Covalent is: > > > > "Upgrade your jdk to 1.31 and then modify the Tomcat.sh to reflect the > new > > JAVA_HOME and start the server with the covalent script". > > > > It might as well be Chinese. > > > > I'm running Red Hat Linux 7.2. > > > > I checked all the Tomcat and Apache references and I can't find anything > that > > says "JDK 1.31". What are they talking about? A Java JDK? I can't find > > anything that says "JDK 1.31". > > > > Please include a copy of this message with your reply. > > > -- End of Forwarded Message > > > -- > To unsubscribe, e-mail: <mailto:tomcat-dev- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:tomcat-dev- > [EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or Tomcat 3.3
On Monday 10 September 2001 16:15, Christopher Cain wrote: > Gomez Henri wrote: > > [snip] > > > PS: Something goes crasy these days, on tomcat list, what do you think > > about this Pier (known as my worst enemy :) > > Something is indeed a little bizarre on the list today, mon ami. Maybe > because Craig isn't here to keep us in line =) > > a) There are now four key people seriously discussing a partial merge of > mod_jk and mod_webapp > > b) Henri and Pier are agreeing on all sorts of things > > c) The 3.3 guys are congratulating the 4.0 guys and vice-versa > > d) There have been about 15 votes in last 24 hours > > e) _I'm_ the short-tempered one, for a change > > The only reason I know for sure that the world is still spinning is that > Jon is still vetoing things ;-) Well, I'm new to the list, but I like to veto things too. Somebody point me at something I can veto... :-) Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or Tomcat 3.3
On Monday 10 September 2001 15:22, Pier Fumagalli wrote: > "Ryan Bloom" <[EMAIL PROTECTED]> wrote: > >> MMAP is the other scary stuff in APR, the new code (without Ralph's > >> libmm) it no more than one month old... I need it for load balancing, > >> but I want to double check with the guys in CA next week and see what > >> they tell me before publishing anything.. > > > > Actually, MMAP has been in APR for a long time, it is just shared memory > > that is new. > > My bad... :) > > > And, the shared memory code has been stressed in Apache for the > > last month. Also the shared memory code is basically just the important > > stuff from the MM library. > > My last status was 2 weeks ago when I last saw David, and he said "wait for > a little longer still"... So, can I assume that "little longer" is over? I think so. The problem back then, was that he needed APR to be available before he could do anything with apr-util, but we were cleaning APR before trying to clean apr-util, and it just didn't work. That was a BeOS-only problem though. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or Tomcat 3.3
> MMAP is the other scary stuff in APR, the new code (without Ralph's libmm) > it no more than one month old... I need it for load balancing, but I want > to double check with the guys in CA next week and see what they tell me > before publishing anything.. Actually, MMAP has been in APR for a long time, it is just shared memory that is new. And, the shared memory code has been stressed in Apache for the last month. Also the shared memory code is basically just the important stuff from the MM library. > > I'm actually right now working on the thread locks for Windows, and then > > I am going to start agitating for an APR release. We should have APR 1.0 > > out the door soon-ish. I am hoping to have it released sometime in the > > next month or two. :-) > > Yah... We need that thread locking for Windows... :) At least I do :) :) :) Give me one or two hours, and I will commit it. :-) Ryan ______ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or Tomcat 3.3
On Monday 10 September 2001 14:51, [EMAIL PROTECTED] wrote: > On Mon, 10 Sep 2001, Pier Fumagalli wrote: > > >> This is the third time we agree on something in less than 24 hours. > > >> This implies that either I'm getting old, or just plain silly... > > > > > > Now, if you could agree on merging mod_webapp and mod_jk, that would be > > > something... > > > > Slowww down... :) If mod_jk wants to start using APR, I believe we're > > talking, otherwise, I'm done with cross-platform porting, I live it to > > Ryan > > > > :) > > Mod_jk will use APR - that's certain. The only question is when and how > to do the transition without affecting the stability of the code. Having > an APR1.0 out is one of the requirements - I don't think we can release > mod_jk, even from j-t-c, with dependencies on un-released library. > > There are already 2 proposals for how to do that - one with preserving the > current common as a temporary solution, until we make sure it works with > IIS/NES, and the other with removing the common utils and hoping things > will work with IIS/NES. > > Right now the APR/common is not the main itch - it'll become pretty soon, > at least for me ( I need mmap for the new connector ) I'm actually right now working on the thread locks for Windows, and then I am going to start agitating for an APR release. We should have APR 1.0 out the door soon-ish. I am hoping to have it released sometime in the next month or two. :-) Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or Tomcat 3.3
On Monday 10 September 2001 14:05, Pier Fumagalli wrote: > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > On Mon, 10 Sep 2001, Pier Fumagalli wrote: > >> "GOMEZ Henri" <[EMAIL PROTECTED]> wrote: > >>> Ryan to became more than just a contributer : > >> > >> This is the third time we agree on something in less than 24 hours. This > >> implies that either I'm getting old, or just plain silly... > > > > Now, if you could agree on merging mod_webapp and mod_jk, that would be > > something... > > Slowww down... :) If mod_jk wants to start using APR, I believe we're > talking, otherwise, I'm done with cross-platform porting, I live it to Ryan Oh no you don't. I did the cross-platform stuff. I wrote APR to get awar from it. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [VOTE] New commiter Ryan Bloom
On Monday 10 September 2001 10:23, Christopher Cain wrote: Thanks for the vote of confidence everybody. I wasn't expecting such a fast turn-around time on this. I'll try not to muck things up too badly. Ryan > +1 > > Welcome, Slick! > > - Christopher > > /** > * Pleurez, pleurez, mes yeux, et fondez vous en eau! > * La moitié de ma vie a mis l'autre au tombeau. > *---Corneille > */ > > GOMEZ Henri wrote: > > I would like to propose Ryan Bloom as commiter > > in Tomcat, and particulary on jakarta-tomcat-connector. > > > > Ryan is one of the dev leader in Apache 2.0 and > > contributed many patch for both mod_jk and mod_webapp, > > showing us that connectors avoid politics :) > > > > Vote, please > > > > - > > Henri Gomez ___[_] > > EMAIL : [EMAIL PROTECTED](. .) > > PGP KEY : 697ECEDD...oOOo..(_)..oOOo... > > PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat for Tomcat 3.3
On Monday 10 September 2001 07:48, Mike Anderson wrote: ++1! I didn't even know it existed anyplace other than JTC. I have been supplying patches recently for it too. Also, having duplicate code anyplace is just a bad idea. I am on a crusade to remove all duplicate code from every code-base throughout the world. :-) Anyway, from a non-committer, but sometime contributer, get rid of the duplicate code, please. Ryan > +1 > > JTC is the best place for this since it can be kept up to date > with an appropriate version of APR and Apache 2.0. > > Mike Anderson > > >>> [EMAIL PROTECTED] 09/07/01 12:44PM >>> > > I agree with Costin's suggestion to remove the Apache 2.0 > version of mod_jk from jakarta-tomcat for Tomcat 3.3. > This would occur after any bug fixes missing from > jakarta-tomcat-connectors were ported. > > It makes much more sense to have it live only in > jakarta-tomcat-connectors where it can quickly respond > to changes. I don't plan much maintenance on the connectors > once Tomcat 3.3 is released. > > VOTE: > > [ ] +1 REMOVE: Apache 2.0 mod_jk should be removed from >jakarta-tomcat for Tomcat 3.3 > [ ] -1 KEEP: Apache 2.0 mod_jk should be kept in >jakarta-tomcat for Tomcat 3.3 > > My vote is +1. > > Cheers, > Larry > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Friday, September 07, 2001 2:17 PM > > To: [EMAIL PROTECTED] > > Subject: RE: cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 > > mod_w ebapp.c > > > > On Fri, 7 Sep 2001, GOMEZ Henri wrote: > > > Don't forget that many of us must evaluate > > > a KNOWN Apache 2.0 in real environnement. > > > The most known are Apache sites which use the released > > > version 2.0.24 :) > > > > > > We could do that a each release (2.0.24/2.0.25) but > > > not in real-time ;) > > > > Probably the correct solution is somewhere in the middle. I agree with > > Henri that using the HEAD is extremely difficult for both > > developers and > > potential users who want to help testing or just evaluate > > 2.0+jk. However > > sticking with an old snapshot and not testing with the HEAD > > is also bad. > > > > Having more frequent 'stable' snapshots of 2.0 would be IMHO the best > > solution, and keeping jk in sync with the latest snapshot > > wouldn't be that > > difficult. At least we could get reproductible behavior - and more > > determinism. > > > > So my proposal for jk would be to use snapshots - regardless > > of alpha or > > beta status. When the dust settles on a 2.0 change and a new > > alpha/beta > > snapshot is released - we can update our APIs. > > > > BTW, giving the amount of change in 2.0 - what about removing > > the 2.0 jk > > connector from 3.3, and relying on j-t-c for a 2.0 connector ? > > > > Right now the jk code in jakarta-tomcat is supposed to be > > 'stable', and > > only clear bug fixes are ported back. The 2.0 module can't be > > considered > > stable ( since it changes all the time ) - and what could be > > released with > > 3.3 will be certainly out of sync the next day. > > > > Should we call a vote on this ? > > > > Costin -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 mod_w ebapp.c
On Thursday 06 September 2001 18:06, Justin Erenkrantz wrote: > On Fri, Sep 07, 2001 at 01:52:50AM +0100, Pier Fumagalli wrote: > > Since there is no official release of httpd-2.0, I am confident that > > nobody will actually care unless they're testing something... And by > > "testing" good practice says "get the HEAD of CVS and try it out yourself > > if it doesn't work". Development happens on "head" and if someone forks > > off for a little while to do some porting to some weird operating > > systems, at the end those changes will have to be integrated with HEAD, > > so, there's no point in sticking with backward compatibility AT THIS > > POINT. > > +1 to what Pier said. (Ryan may chip in here too...) > > If you are using anything other than HEAD for httpd-2.0, I don't > care much about any bug reports you may have. The odds are that it'd > either be fixed or broken in a different manner. =) -- justin Don't try to mainain backwards compat in 2.0. We aren't even trying yet. Every release of 2.0 other than head has a serious problem, either a memory leek, or a security hole, or it can crash the machine. IF your not using HEAD of httpd-2.0, you have a problem. :-) Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
[PATCH] only parse workers.properties once
This is an improvement for mod_jk, to only parse workers.properties once
on platforms that use fork(). Most platforms will not require us to read
the workers.properties file in the child process, because they process it in
the parent. Windows is the only platform I know of today that does require
us to read it twice.
This also has the advantage, that the workers.properties file does not need
to be readable by the user that the web server is running as.
Ryan
Index: mod_jk.c
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.23
diff -u -d -b -w -u -r1.23 mod_jk.c
--- mod_jk.c2001/09/06 17:00:54 1.23
+++ mod_jk.c2001/09/06 21:54:01
@@ -1214,6 +1214,7 @@
return overrides;
}
+#ifdef WIN32
/** Standard apache callback, initialize jk.
*/
static void jk_child_init(apr_pool_t *pconf,
@@ -1224,6 +1225,7 @@
init_jk( pconf, conf, s );
}
+#endif
/** Initialize jk, using worker.properties.
We also use apache commands ( JkWorker, etc), but this use is
@@ -1340,7 +1342,9 @@
{
ap_hook_handler(jk_handler, NULL, NULL, APR_HOOK_MIDDLE);
ap_hook_post_config(jk_post_config,NULL,NULL,APR_HOOK_MIDDLE);
+#ifdef WIN32
ap_hook_child_init(jk_child_init,NULL,NULL,APR_HOOK_MIDDLE);
+#endif
ap_hook_translate_name(jk_translate,NULL,NULL,APR_HOOK_FIRST);
#if (MODULE_MAGIC_NUMBER_MAJOR > 20010808)
ap_hook_map_to_storage(jk_map_to_storage, NULL, NULL, APR_HOOK_MIDDLE);
__
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--
Patch for mod_jk and Apache 2.0
This patch allows mod_jk to successfully serve pages against Apache 2.0
and Tomcat 4.0. This is required after the changes to abstract out location
and directory walks from the core request processing. This was created by
Will Rowe and myself.
Ryan
Index: mod_jk.c
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.18
diff -u -d -b -w -u -r1.18 mod_jk.c
--- mod_jk.c2001/09/04 10:57:03 1.18
+++ mod_jk.c2001/09/06 00:17:28
@@ -1333,13 +1333,22 @@
return DECLINED;
}
+static int jk_map_to_storage(request_rec *r)
+{
+if (apr_table_get(r->notes, JK_WORKER_ID)) {
+r->filename = apr_filename_of_pathname(r->uri);
+return OK;
+}
+return DECLINED;
+}
+
static void jk_register_hooks(apr_pool_t *p)
{
ap_hook_handler(jk_handler, NULL, NULL, APR_HOOK_MIDDLE);
ap_hook_post_config(jk_post_config,NULL,NULL,APR_HOOK_MIDDLE);
ap_hook_child_init(jk_child_init,NULL,NULL,APR_HOOK_MIDDLE);
ap_hook_translate_name(jk_translate,NULL,NULL,APR_HOOK_FIRST);
-
+ap_hook_map_to_storage(jk_map_to_storage, NULL, NULL, APR_HOOK_MIDDLE);
}
module AP_MODULE_DECLARE_DATA jk_module =
______
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--
Re: Build system for mod_webapp and Apache 2.0
On Wednesday 05 September 2001 09:57, jean-frederic clere wrote: > Ryan Bloom wrote: > > On Wednesday 05 September 2001 04:13, jean-frederic clere wrote: > > > > If you don't remove the --disable-shared, then libtool 1.4 can't compile > > mod_webapp as a dynamic library. > > I just want a DSO file... > > - On my Linux if I remove the --disable-shared to the APR, libtool > complains when building mod_webapp.so: > something like that "we use dynamic library we have to install them"... > (That is libtool 1.3.5) > > Are you suggesting to use dynamic libapr and libwebapp? I don't really have a good suggestion. I am just telling you that with --disable-shared, libtool 1.4 CAN NOT create DSOs. It sucks, but that is libtool for ya. It sounds like we may have to figure out which version of libtool the user has, and adjust our build rules appropriately. :-( Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: Build system for mod_webapp and Apache 2.0
On Wednesday 05 September 2001 04:13, jean-frederic clere wrote: If you don't remove the --disable-shared, then libtool 1.4 can't compile mod_webapp as a dynamic library. It really sucks, but complain to the libtool developers. That flg must go, or we break anybody who tries to use the latest version of libtool. :-( Ryan > Hi, > > I have committed it. Note that the --disable-shared MUST NOT be removed > otherwise libtool uses the dynamic libraries and we want it to use the > static ones. > > Cheers > > Jean-frederic ______ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: Build system for mod_webapp and Apache 2.0
> > > LOCAL_HEADER([Configuring APR])
> > > LOCAL_FILTEREXEC(
> > > - [./configure --enable-static --disable-shared --disable-threads],
> > > + [./configure --enable-static --disable-threads],
> > > ["APR configure"])
> > > if ${TEST} "${ret}" -ne "0"
> > > then
> >
> > Hmm... I'd like to rely on the APR code coming with Apache 2.0 instead of
> > building our local copy with Apache 2.0... (I'll see what I can figure
> > out, hoping that 2.0 works on my OS/X box :)
>
> Oh, if that's what you want to do, I can make that happen. Give me five
> minutes, and you'll have a patch. :-)
Sorry, I got called into a meeting, so this took a little bit longer than I wanted it
to. Here is a patch that stops us from building APR, and we just use the one
from Apache 2.0.
Index: Makefile.in
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/webapp/Makefile.in,v
retrieving revision 1.16
diff -u -d -b -w -u -r1.16 Makefile.in
--- Makefile.in 2001/08/31 10:26:24 1.16
+++ Makefile.in 2001/08/31 20:36:29
@@ -70,11 +70,11 @@
config.log \
config.status
-all: apr-all local-all
+all: @APR_BUILD@ local-all
install: local-install
-clean: apr-clean local-clean
+clean: @APR_CLEAN@ local-clean
distclean: clean
@$(ECHO) ""
Index: configure.in
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/webapp/configure.in,v
retrieving revision 1.24
diff -u -d -b -w -u -r1.24 configure.in
--- configure.in2001/08/31 10:26:24 1.24
+++ configure.in2001/08/31 20:36:29
@@ -210,15 +210,21 @@
APA=`${GREP} STANDARD20 ${APXS}`
if ${TEST} -z "$APA" ; then
TARGET="${SRCDIR}/apache-1.3"
+ APR_BUILD="apr-all"
+ APR_CLEAN="apr-clean"
makefile="apache-1.3/Makefile"
else
TARGET="${SRCDIR}/apache-2.0"
+ APR_BUILD=""
+ APR_CLEAN=""
makefile="apache-2.0/Makefile"
fi
AC_MSG_RESULT([setting target module to... ${TARGET}])
]
)
AC_SUBST(TARGET)
+AC_SUBST(APR_BUILD)
+AC_SUBST(APR_CLEAN)
dnl --
dnl Process the --with-apr=... command line argument
@@ -226,10 +232,16 @@
AC_MSG_CHECKING([APR directory])
AC_ARG_WITH(apr,
[ --with-apr=DIR where the APR sources can be found.],
- APRDIR="${withval}",
- APRDIR="${SRCDIR}/apr"
+ APRDIR="${withval}"
)
+if ${TEST} -z "${APA}" -a -z "${APRDIR}" ; then
+ APRDIR="{SRCDIR}/apr"
+else
+ APRDIR="${APXS_PREFIX}"
+fi
+
+if ${TEST} -z "${APA}" ; then
if ${TEST} ! -d "${APRDIR}" ; then
AC_MSG_ERROR([Cannot find APR sources directory \"${APRDIR}\"])
fi
@@ -267,6 +279,9 @@
AC_MSG_ERROR([APR configure script terminated with error code ${ret}])
fi
cd ${curdir}
+else
+ AC_MSG_RESULT(Using APR from Apache build)
+fi
dnl --
dnl Retrieving APR default values
@@ -275,19 +290,29 @@
if ${TEST} ! -f ${APRDIR}/APRVARS
then
+ if ${TEST} "${APA}" ; then
+LIBDIR="/lib"
+ else
AC_MSG_RESULT([error])
AC_MSG_ERROR([Cannot find APR defaults in ${APRDIR}/APRVARS])
fi
+else
+ LIBDIR=""
+fi
if ${TEST} ! -x ${APRDIR}/libtool
then
+ if ${TEST} "${APA}" ; then
+LIBTOOL="${APXS_PREFIX}/build/libtool"
+ else
AC_MSG_RESULT([error])
AC_MSG_ERROR([Cannot find APR libtool binary])
+ fi
else
LIBTOOL="${APRDIR}/libtool"
fi
-eval `cat ${APRDIR}/APRVARS`
+eval `cat ${APRDIR}${LIBDIR}/APRVARS`
AC_SUBST(CC)
AC_SUBST(CPP)
AC_SUBST(SHELL)
__
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--
Re: Build system for mod_webapp and Apache 2.0
On Friday 31 August 2001 10:36, Pier Fumagalli wrote:
> > +TARGET="${SRCDIR}/apache-2.0"
> > +makefile="apache-2.0/Makefile"
> > +AC_MSG_RESULT([setting target module to... ${TARGET}])
> > + ]
> > +)
> > +AC_SUBST(TARGET)
> > +
> > +dnl
>
> Wasn't APXS for 2.0 completely broken? That's what you said last time :)
It was. I fixed it. :)
> > LOCAL_HEADER([Configuring APR])
> > LOCAL_FILTEREXEC(
> > - [./configure --enable-static --disable-shared --disable-threads],
> > + [./configure --enable-static --disable-threads],
> > ["APR configure"])
> > if ${TEST} "${ret}" -ne "0"
> > then
>
> Hmm... I'd like to rely on the APR code coming with Apache 2.0 instead of
> building our local copy with Apache 2.0... (I'll see what I can figure out,
> hoping that 2.0 works on my OS/X box :)
Oh, if that's what you want to do, I can make that happen. Give me five minutes,
and you'll have a patch. :-)
Ryan
__
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--
Re: cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 Makefile.in
On Friday 31 August 2001 10:32, Pier Fumagalli wrote: > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > jfclere 01/08/29 07:29:29 > > > > Modified:webapp configure.in > > Added: webapp/apache-2.0 Makefile.in > > Log: > > Copy/add configure logic for Apache-2.0 from mod_jk. > > > > Revision ChangesPath > > 1.23 +12 -3 jakarta-tomcat-connectors/webapp/configure.in > > APXS is broken in Apache 2.0... We should rely on APRVARS... I actually fixed APXS this last weekend, and I have used it many times now to build mod_webapp. :-) Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: Build system for mod_webapp and Apache 2.0
On Thursday 30 August 2001 01:10, jean-frederic clere wrote:
> Ryan Bloom wrote:
> > Hi everybody, I'm new to the list, but for anybody who doesn't know me,
> > I have been pretty active on httpd 2.0. I decided to port mod_webapp
> > last week, and Pier committed the code for me, but the build system isn't
> > there, so I am posting the build system now.
> >
> > This is currently working, although there seems to be some strangeness
> > when Tomcat responds to mod_webapp. I'll be looking into that over the
> > next few days. I hope to be more active as time permits. :-)
> >
> > The Makefile.in should be placed in
> > jakarta-tomcat-connectors/webapp/apache-2.0
>
> Hi Ryan,
>
> I committed some code some hours before... I will try to merge the two.
> I am detecting Apache version using apxs thru the following code:
> +++
> dnl test apache version (from mod_jk)
> $RM -rf test
> $APXS -n test -g
> APA=`grep STANDARD20 test/mod_test.c`
> if ${TEST} -z "$APA" ; then
> TARGET="${SRCDIR}/apache-1.3"
> makefile="apache-1.3/Makefile"
> else
> TARGET="${SRCDIR}/apache-2.0"
> makefile="apache-2.0/Makefile"
> fi
> +++
> Any comment? - I am using the same in mod_jk -
Doesn't this needlessly create a new directory on the machine? And, it doesn't
clean that dir until the next time you try to configure. At the very least,
we should execute the '$RM -rf test' command after the grep. It would actually
be possible to just do 'grep STANDARD20 $APXS'. This is because
the perl script actually has a copy of the module in it. That is probably the
cleanest solution.
> I have also noted strange things mod_webapp always returns 500.
> It seems the request is mapped (wam_match) correctly but the handler
> (wam_invoke) is not called.
> What is the problem you have detected?
It looks like when Tomcat returns a 302 through mod_webapp, we are
redirected to a strange port. I haven't even begun to look at it yet, but I
am hoping to have time either today or tomorrow.
Ryan
__
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--
Build system for mod_webapp and Apache 2.0
Hi everybody, I'm new to the list, but for anybody who doesn't know me,
I have been pretty active on httpd 2.0. I decided to port mod_webapp last
week, and Pier committed the code for me, but the build system isn't there, so
I am posting the build system now.
This is currently working, although there seems to be some strangeness when
Tomcat responds to mod_webapp. I'll be looking into that over the next few days.
I hope to be more active as time permits. :-)
The Makefile.in should be placed in jakarta-tomcat-connectors/webapp/apache-2.0
Thanks,
Ryan
Index: webapp/Makefile.in
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/webapp/Makefile.in,v
retrieving revision 1.15
diff -u -d -b -w -u -r1.15 Makefile.in
--- webapp/Makefile.in 2001/08/06 22:21:52 1.15
+++ webapp/Makefile.in 2001/08/29 23:51:41
@@ -62,6 +62,7 @@
LOCALDIRS = @TGTDIRS@ @TARGET@
APRDIR = @APRDIR@
+INSTALLDIR = @TARGET@
CFGS = @CONFIGFILES@ \
@SRCDIR@/lib/pr_warp_defs.h \
@@ -71,6 +72,8 @@
all: apr-all local-all
+install: local-install
+
clean: apr-clean local-clean
distclean: clean
@@ -128,6 +131,19 @@
$(ECHO) "Cleaning up $${DIR}..." ; \
cd $${DIR} ; \
$(MAKE) clean ; \
+ RET=$$? ; \
+ cd $(SRCDIR) ; \
+ if test "$${RET}" != "0" ; then \
+ exit $${RET} ; \
+ fi ; \
+ done
+
+local-install:
+ @for DIR in $(INSTALLDIR) ; do \
+ $(ECHO) "" ; \
+ $(ECHO) "Compiling sources in $${DIR}..." ; \
+ cd $${DIR} ; \
+ $(MAKE) install ; \
RET=$$? ; \
cd $(SRCDIR) ; \
if test "$${RET}" != "0" ; then \
Index: webapp/configure.in
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/webapp/configure.in,v
retrieving revision 1.22
diff -u -d -b -w -u -r1.22 configure.in
--- webapp/configure.in 2001/08/06 22:48:45 1.22
+++ webapp/configure.in 2001/08/29 23:51:41
@@ -214,6 +214,41 @@
AC_SUBST(TARGET)
dnl --
+dnl Process the --with-apxs2[=FILE] command line argument
+dnl --
+AC_ARG_WITH(apxs2,
+ [ --with-apxs2[=FILE] build a shared Apache 2.0.x module.],
+ [
+if ${TEST} -n "${TARGET}"
+then
+ AC_MSG_ERROR([target already defined as ${TARGET}])
+fi
+
+APXS="${withval}"
+
+if ${TEST} -z "${APXS}" ; then APXS="yes" ; fi
+if ${TEST} "${APXS}" = "yes"
+then
+ AC_PATH_PROG(APXS,apxs,${PATH})
+fi
+
+AC_MSG_CHECKING([if apxs is working])
+${APXS} -q CC 2>&1 1>/dev/null
+if ${TEST} ! "$?" -eq "0"
+then
+ AC_MSG_RESULT([no])
+ AC_MSG_ERROR([apxs is unworkable])
+fi
+AC_MSG_RESULT([ok])
+
+TARGET="${SRCDIR}/apache-2.0"
+makefile="apache-2.0/Makefile"
+AC_MSG_RESULT([setting target module to... ${TARGET}])
+ ]
+)
+AC_SUBST(TARGET)
+
+dnl --
dnl Process the --with-apr=... command line argument
dnl --
AC_MSG_CHECKING([APR directory])
@@ -253,7 +288,7 @@
LOCAL_HEADER([Configuring APR])
LOCAL_FILTEREXEC(
- [./configure --enable-static --disable-shared --disable-threads],
+ [./configure --enable-static --disable-threads],
["APR configure"])
if ${TEST} "${ret}" -ne "0"
then
__
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--
# = #
# #
# The Apache Software License, Version 1.1 #
# #
# Copyright (c) 1999-2001 The Apache Software Foundation. #
# All rights reserved.#
# #
# = #
# #
# Redistribution and use in source and binary forms, with or without modi- #
# fication, are permitted provided that the following cond
