Re: jk2 evolution plan
Sorry for the late reply on this. I'd also like to help out with mod_jk2 and this move to apr. Mostly for the sake of the NetWare platform, though I need to understand the Linux connectors well as well. Let me know where I can be of service. I have a little experience with the connectors, though mostly mod_jk. I will do my best to get up to speed on it though and help out. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com [EMAIL PROTECTED] 10/17/03 5:41 AM +1 I can help out. This is a significant change for a minor revision to 2.0.4, perhaps we should bump it to 2.1 or even 3.0? Glenn Henri Gomez wrote: Ok, about everybody seems to agree on using apr for jk2 (still waiting Nacho for IIS). APR side will be to : - Update doc to indicate that APR is mandatory - Remove #idef APR - Use APR for all OS operation and sus will save us from handling all the #include for all the diverses IO operation (it's really a pain). - For now still use_jk pool, but the version using apr_tools. - Make socket use apr_socket for compatibility. JK to JK2 fonctionnalities backport : - Check features added in jk and not present in jk2 (ie cping/cpong). There was also some specific lb workers settings which should be studied. - After this works, make a 2.0.4 release and start extensive testing. On the channel side I added a new method, hasinput which should help use determine if there is something to do on 'stream connections'. For instance, it's used in jk/jk2 by the cping/cpong stage when connectTimeout, prepostTimeout and replyTimeout are set. And no the who's who ;) I'd like to know who could works on jk2 evolution. BTW, where could we find today the jk/jk2 documentation which is regenerated each day ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 evolution plan
Glenn Nielsen wrote: +1 I can help out. This is a significant change for a minor revision to 2.0.4, perhaps we should bump it to 2.1 or even 3.0? Since it's an 'internal rewrite', it should stay 2.x, may be 2.1 could be the right name But first we should cleanup all jk2 from #iddef APR defines and custom OS includes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 evolution plan
- Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, October 20, 2003 12:53 AM Subject: Re: jk2 evolution plan Glenn Nielsen wrote: +1 I can help out. This is a significant change for a minor revision to 2.0.4, perhaps we should bump it to 2.1 or even 3.0? Since it's an 'internal rewrite', it should stay 2.x, may be 2.1 could be the right name But first we should cleanup all jk2 from #iddef APR defines and custom OS includes. I could get on-board with this, after Mladen's suggestion to change the return-type of most methods to jk_status_t. Without this, mod_jk2 is hopelessly broken (and I'll contunue to ignore it :). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 evolution plan
From: Bill Barker I could get on-board with this, after Mladen's suggestion to change the return-type of most methods to jk_status_t. Without this, mod_jk2 is hopelessly broken (and I'll contunue to ignore it :). It's to apr_status_t ;-). Sill, takes a bit more time then I thought It would. Not just to return APR_SUCCESS, but to return the meaningful error codes that can be logged. So day or two... MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 evolution plan
Mladen Turk wrote: From: Bill Barker I could get on-board with this, after Mladen's suggestion to change the return-type of most methods to jk_status_t. Without this, mod_jk2 is hopelessly broken (and I'll contunue to ignore it :). It's to apr_status_t ;-). Sill, takes a bit more time then I thought It would. Not just to return APR_SUCCESS, but to return the meaningful error codes that can be logged. So day or two... So it will be apr_status_t ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 evolution plan
From: Henri Gomez Mladen Turk wrote: From: Bill Barker I could get on-board with this, after Mladen's suggestion to change the return-type of most methods to jk_status_t. Without this, mod_jk2 is hopelessly broken (and I'll contunue to ignore it :). It's to apr_status_t ;-). Sill, takes a bit more time then I thought It would. Not just to return APR_SUCCESS, but to return the meaningful error codes that can be logged. So day or two... So it will be apr_status_t ? Yes, It is IMO the most straighforward. If the APR API call fails the calee will return the same error code, without the need to reinvent our own error codes. The jk2 specific error codes will beging from APR_OS_START_USERERR + 1. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 evolution plan
+1 I can help out. This is a significant change for a minor revision to 2.0.4, perhaps we should bump it to 2.1 or even 3.0? Glenn Henri Gomez wrote: Ok, about everybody seems to agree on using apr for jk2 (still waiting Nacho for IIS). APR side will be to : - Update doc to indicate that APR is mandatory - Remove #idef APR - Use APR for all OS operation and sus will save us from handling all the #include for all the diverses IO operation (it's really a pain). - For now still use_jk pool, but the version using apr_tools. - Make socket use apr_socket for compatibility. JK to JK2 fonctionnalities backport : - Check features added in jk and not present in jk2 (ie cping/cpong). There was also some specific lb workers settings which should be studied. - After this works, make a 2.0.4 release and start extensive testing. On the channel side I added a new method, hasinput which should help use determine if there is something to do on 'stream connections'. For instance, it's used in jk/jk2 by the cping/cpong stage when connectTimeout, prepostTimeout and replyTimeout are set. And no the who's who ;) I'd like to know who could works on jk2 evolution. BTW, where could we find today the jk/jk2 documentation which is regenerated each day ? - 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]
jk2 evolution plan
Ok, about everybody seems to agree on using apr for jk2 (still waiting Nacho for IIS). APR side will be to : - Update doc to indicate that APR is mandatory - Remove #idef APR - Use APR for all OS operation and sus will save us from handling all the #include for all the diverses IO operation (it's really a pain). - For now still use_jk pool, but the version using apr_tools. - Make socket use apr_socket for compatibility. JK to JK2 fonctionnalities backport : - Check features added in jk and not present in jk2 (ie cping/cpong). There was also some specific lb workers settings which should be studied. - After this works, make a 2.0.4 release and start extensive testing. On the channel side I added a new method, hasinput which should help use determine if there is something to do on 'stream connections'. For instance, it's used in jk/jk2 by the cping/cpong stage when connectTimeout, prepostTimeout and replyTimeout are set. And no the who's who ;) I'd like to know who could works on jk2 evolution. BTW, where could we find today the jk/jk2 documentation which is regenerated each day ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 evolution plan
-Original Message- From: Henri Gomez Ok, about everybody seems to agree on using apr for jk2 (still waiting Nacho for IIS). IIS uses APR by default (staticaly linked) for a long time. APR side will be to : - Update doc to indicate that APR is mandatory - Remove #idef APR - Use APR for all OS operation and sus will save us from handling all the #include for all the diverses IO operation (it's really a pain). - For now still use_jk pool, but the version using apr_tools. - Make socket use apr_socket for compatibility. Why? Just rename env-registerFactory( env, channel.socket, jk2_channel_socket_factory ); to env-registerFactory( env, channel.socket,jk2_channel_apr_socket_factory ); and drop the socket channel. And no the who's who ;) I'd like to know who could works on jk2 evolution. +1 MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 evolution plan
Mladen Turk wrote: -Original Message- From: Henri Gomez Ok, about everybody seems to agree on using apr for jk2 (still waiting Nacho for IIS). IIS uses APR by default (staticaly linked) for a long time. APR side will be to : - Update doc to indicate that APR is mandatory - Remove #idef APR - Use APR for all OS operation and sus will save us from handling all the #include for all the diverses IO operation (it's really a pain). - For now still use_jk pool, but the version using apr_tools. - Make socket use apr_socket for compatibility. Why? Just rename env-registerFactory( env, channel.socket, jk2_channel_socket_factory ); to env-registerFactory( env, channel.socket,jk2_channel_apr_socket_factory ); and drop the socket channel. Exactly ... And no the who's who ;) I'd like to know who could works on jk2 evolution. +1 Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 evolution plan
-Original Message- From: Henri Gomez I'd like to know who could works on jk2 evolution. +1 Thanks. I can (not before friday): 1. Change all the (quasi boolean) functions to return the apr_status_t instead int (0, 1) 2. aprize jk2_log to use the apr_file_t 3. aprize mutex and pool. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 evolution plan
Mladen Turk wrote: -Original Message- From: Henri Gomez I'd like to know who could works on jk2 evolution. +1 Thanks. I can (not before friday): 1. Change all the (quasi boolean) functions to return the apr_status_t instead int (0, 1) 2. aprize jk2_log to use the apr_file_t 3. aprize mutex and pool. Ok, You should know what apr call should be used to mimic select isn't it ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 evolution plan
-Original Message- From: Henri Gomez You should know what apr call should be used to mimic select isn't it ? PING/PONG right? Nothing that simple :-). The magick is apr_poll. It will require some modifications to the channel in general. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 evolution plan
Mladen Turk wrote: -Original Message- From: Henri Gomez You should know what apr call should be used to mimic select isn't it ? PING/PONG right? Nothing that simple :-). The magick is apr_poll. It will require some modifications to the channel in general. hasinput method has been created ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 evolution plan
Henri Gomez wrote: Ok, about everybody seems to agree on using apr for jk2 (still waiting Nacho for IIS). APR side will be to : - Update doc to indicate that APR is mandatory - Remove #idef APR - Use APR for all OS operation and sus will save us from handling all the #include for all the diverses IO operation (it's really a pain). - For now still use_jk pool, but the version using apr_tools. - Make socket use apr_socket for compatibility. JK to JK2 fonctionnalities backport : - Check features added in jk and not present in jk2 (ie cping/cpong). There was also some specific lb workers settings which should be studied. - After this works, make a 2.0.4 release and start extensive testing. On the channel side I added a new method, hasinput which should help use determine if there is something to do on 'stream connections'. For instance, it's used in jk/jk2 by the cping/cpong stage when connectTimeout, prepostTimeout and replyTimeout are set. And no the who's who ;) I'd like to know who could works on jk2 evolution. BTW, where could we find today the jk/jk2 documentation which is regenerated each day ? I used to generate it every night but I have stopped doing the generation. Should I activate my cronjob again? - 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: jk2 evolution plan
jean-frederic clere wrote: Henri Gomez wrote: Ok, about everybody seems to agree on using apr for jk2 (still waiting Nacho for IIS). APR side will be to : - Update doc to indicate that APR is mandatory - Remove #idef APR - Use APR for all OS operation and sus will save us from handling all the #include for all the diverses IO operation (it's really a pain). - For now still use_jk pool, but the version using apr_tools. - Make socket use apr_socket for compatibility. JK to JK2 fonctionnalities backport : - Check features added in jk and not present in jk2 (ie cping/cpong). There was also some specific lb workers settings which should be studied. - After this works, make a 2.0.4 release and start extensive testing. On the channel side I added a new method, hasinput which should help use determine if there is something to do on 'stream connections'. For instance, it's used in jk/jk2 by the cping/cpong stage when connectTimeout, prepostTimeout and replyTimeout are set. And no the who's who ;) I'd like to know who could works on jk2 evolution. BTW, where could we find today the jk/jk2 documentation which is regenerated each day ? I used to generate it every night but I have stopped doing the generation. Should I activate my cronjob again? Yes please, but we should find a stable place (where ?) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 evolution plan
Oh, don't forget COMPLETE documentation for everything in jkstatus! -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED] Sent: Thursday, October 16, 2003 4:59 AM To: Tomcat Developers List Subject: jk2 evolution plan Ok, about everybody seems to agree on using apr for jk2 (still waiting Nacho for IIS). APR side will be to : - Update doc to indicate that APR is mandatory - Remove #idef APR - Use APR for all OS operation and sus will save us from handling all the #include for all the diverses IO operation (it's really a pain). - For now still use_jk pool, but the version using apr_tools. - Make socket use apr_socket for compatibility. JK to JK2 fonctionnalities backport : - Check features added in jk and not present in jk2 (ie cping/cpong). There was also some specific lb workers settings which should be studied. - After this works, make a 2.0.4 release and start extensive testing. On the channel side I added a new method, hasinput which should help use determine if there is something to do on 'stream connections'. For instance, it's used in jk/jk2 by the cping/cpong stage when connectTimeout, prepostTimeout and replyTimeout are set. And no the who's who ;) I'd like to know who could works on jk2 evolution. BTW, where could we find today the jk/jk2 documentation which is regenerated each day ? - 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: jk2 evolution plan
Henri Gomez wrote: jean-frederic clere wrote: Henri Gomez wrote: Ok, about everybody seems to agree on using apr for jk2 (still waiting Nacho for IIS). APR side will be to : - Update doc to indicate that APR is mandatory - Remove #idef APR - Use APR for all OS operation and sus will save us from handling all the #include for all the diverses IO operation (it's really a pain). - For now still use_jk pool, but the version using apr_tools. - Make socket use apr_socket for compatibility. JK to JK2 fonctionnalities backport : - Check features added in jk and not present in jk2 (ie cping/cpong). There was also some specific lb workers settings which should be studied. - After this works, make a 2.0.4 release and start extensive testing. On the channel side I added a new method, hasinput which should help use determine if there is something to do on 'stream connections'. For instance, it's used in jk/jk2 by the cping/cpong stage when connectTimeout, prepostTimeout and replyTimeout are set. And no the who's who ;) I'd like to know who could works on jk2 evolution. BTW, where could we find today the jk/jk2 documentation which is regenerated each day ? I used to generate it every night but I have stopped doing the generation. Should I activate my cronjob again? Yes please, but we should find a stable place (where ?) Done. The machine where it runs is stable but inside FSC firmwall. - 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: jk2 evolution plan
Done. The machine where it runs is stable but inside FSC firmwall. Could we copy it somewhere on apache.org to have it mirrored ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 evolution plan
Henri Gomez wrote: Done. The machine where it runs is stable but inside FSC firmwall. Could we copy it somewhere on apache.org to have it mirrored ? I have copied and adapted it to my account in minotaur. - 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: jk2 evolution plan
jean-frederic clere wrote: Henri Gomez wrote: Done. The machine where it runs is stable but inside FSC firmwall. Could we copy it somewhere on apache.org to have it mirrored ? I have copied and adapted it to my account in minotaur. So we'll have an URL available ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 evolution plan
Henri Gomez wrote: And no the who's who ;) I'd like to know who could works on jk2 evolution. Until December is very unlikely I'll have any free time. I would like to help with the unix domain channel and JNI - but it'll be very limitted... Sorry. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 evolution plan
Costin Manolache wrote: Henri Gomez wrote: And no the who's who ;) I'd like to know who could works on jk2 evolution. Until December is very unlikely I'll have any free time. I would like to help with the unix domain channel and JNI - but it'll be very limitted... Sorry. You're more than welcome of course Costin. The more I look in jk2, the more I like the 'object' oriented methods of jk2 :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
