JK Todo List
Hi, Here is my Todo List for JK: - Documentation - Use Apache coding style (already done 90%) using simple .indent.pro - Fix all 64/32 bit compatibility issues. - Backport IIS Worker thread pool from JK2. - Backport some ajp messaging stuff from proxy_ajp (mostly performance). - Backport shared memory from JK2 for load balancer worker. What's more important: - Documentation - Put the JK2 in 'maintainer' mode. - Inform our users about that decision. - Inform out users that we are still in native<->tomcat business :) Long term plans: - Documentation - Backport unix sockets from JK2 - Backport JNI from JK2 with lots improvements. - Use 1.4 API on Java side - Add full AJP14 protocol support - Add encryption and compression to AJP protocol - APR-ize JK Regards, MT. smime.p7s Description: S/MIME Cryptographic Signature
Re: JK Todo List
Well JK using APR will be a good solution for every webservers but Apache 1.3.x. Apache 2.x came with APR, IIS, Domino and others should have no problems to use an external APR library (.so, .dll). So the remaining question will be shoud we drop Apache 1.3.x support in future JK 1.2.x or should we start a 'new' APR JK 1.2.x based implementation ? On Fri, 08 Oct 2004 16:53:40 -0400, Kurt Miller <[EMAIL PROTECTED]> wrote: > From: "Mladen Turk" <[EMAIL PROTECTED]> > > Remy Maucherat wrote: > > >>> Over all, I don't, personally, think that it's worth trying to build > > >>> on the existing Jk code base. However, if you have an itch > > >> > > >> Well, we deceased JK2, for Apache2.1 we have proxy_ajp. > > >> Until Apache2.1 becomes the only server around the net, > > >> I'll stick with JK for all those not running my preferred > > >> web server :). > > > > > > Right. However, I think JK 1.2.x needs some level of stability. So APR, > > > large architectural changes, etc seem bad ideas. Of your list, I think > > > documentation (yah !) and the Unix sockets backport would be good (if > > > not too complex), but that's about it. Modifications to the Java side is > > > something independent. > > > > > > > I think it would rise the stability, but introduce new problems like > > building APR, etc.. so you are probably right. We'll see. > > I'm not very happy with the integrated APR build in JK2 for Apache > 1.3. I did much of the work there and if I had to do it again, I'd > prefer APR to be a build/runtime depend, built separately by the > user first and loaded with LoadFile directive. > > With respect to JK, I'd rather not see it get APR'ized. Mostly > so that Apache 1.3 support is kept simple and straightforward. > > > > For the long term, if you would want better support for the other > > > servers, you can start a 100% APR replacement for JK 1.2 (I think it was > > > a bit like your mod_ajp) if you want to. > > > > > > > I'm surely do. The IIS6 support is something to chase :). > > > > MT. > > > > > > > - > 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 Todo List
From: "Henri Gomez" <[EMAIL PROTECTED]> > Well JK using APR will be a good solution for every webservers but Apache 1.3.x. > > Apache 2.x came with APR, IIS, Domino and others should have no > problems to use an external APR library (.so, .dll). > > So the remaining question will be shoud we drop Apache 1.3.x support > in future JK 1.2.x or should we start a 'new' APR JK 1.2.x based > implementation ? I think there are two other options. I've listed all them in my order of preference. 1) Don't APR'ize JK and keep Apache 1.3 support 2) APR'ize JK 3) start a new APR JK 1.2 based 4) drop Apache 1.3 support I'd like to keep Apache 1.3 support going longer. If 1 is ruled out, I'd want APR to be build separately and loaded via the LoadFile directive. The JK2 integrated build of APR and static linking is/was to complex. If there's consensus to go with option 2, I would be willing to do the work on the Apache 1.3 native build. -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
Henri Gomez wrote: Well JK using APR will be a good solution for every webservers but Apache 1.3.x. Apache 2.x came with APR, IIS, Domino and others should have no problems to use an external APR library (.so, .dll). So the remaining question will be shoud we drop Apache 1.3.x support in future JK 1.2.x or should we start a 'new' APR JK 1.2.x based implementation ? Why use APR in mod_jk ? Support for Apache1.3 is IMO more important than support for IIS. And so far, mod_jk seems to work without any apr - and it is in maintainance mode, so no major changes should be made. Costin On Fri, 08 Oct 2004 16:53:40 -0400, Kurt Miller <[EMAIL PROTECTED]> wrote: From: "Mladen Turk" <[EMAIL PROTECTED]> Remy Maucherat wrote: Over all, I don't, personally, think that it's worth trying to build on the existing Jk code base. However, if you have an itch Well, we deceased JK2, for Apache2.1 we have proxy_ajp. Until Apache2.1 becomes the only server around the net, I'll stick with JK for all those not running my preferred web server :). Right. However, I think JK 1.2.x needs some level of stability. So APR, large architectural changes, etc seem bad ideas. Of your list, I think documentation (yah !) and the Unix sockets backport would be good (if not too complex), but that's about it. Modifications to the Java side is something independent. I think it would rise the stability, but introduce new problems like building APR, etc.. so you are probably right. We'll see. I'm not very happy with the integrated APR build in JK2 for Apache 1.3. I did much of the work there and if I had to do it again, I'd prefer APR to be a build/runtime depend, built separately by the user first and loaded with LoadFile directive. With respect to JK, I'd rather not see it get APR'ized. Mostly so that Apache 1.3 support is kept simple and straightforward. For the long term, if you would want better support for the other servers, you can start a 100% APR replacement for JK 1.2 (I think it was a bit like your mod_ajp) if you want to. I'm surely do. The IIS6 support is something to chase :). MT. - 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 Todo List
Costin Manolache wrote: Henri Gomez wrote: Well JK using APR will be a good solution for every webservers but Apache 1.3.x. Apache 2.x came with APR, IIS, Domino and others should have no problems to use an external APR library (.so, .dll). So the remaining question will be shoud we drop Apache 1.3.x support in future JK 1.2.x or should we start a 'new' APR JK 1.2.x based implementation ? Why use APR in mod_jk ? Support for Apache1.3 is IMO more important than support for IIS. And so far, mod_jk seems to work without any apr - and it is in maintainance mode, so no major changes should be made. I think good Apache 1.3 support is more important than improving IIS support. IIS is not gaining market share these days, and it seems quite obvious most of the new IIS 6 installations are going to be used to run .not web components. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
So is JK2 dead because of proxy_ajp? Why doesn't JK2 just replace JK? Dave. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
- Original Message - From: "Dave Oxley" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Monday, October 11, 2004 3:35 PM Subject: Re: JK Todo List > So is JK2 dead because of proxy_ajp? Why doesn't JK2 just replace JK? > JK2 is dead because (like mod_webapp before it :), it failed to attract a community interested in maintaining it. You might as well ask 'why doesn't mod_webapp just replace JK?' > Dave. > > > > - > 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: JK Todo List
True, in ASF land as in other community, it's the users and developpers base which make a solution/product successfull or forgotten. BTW, jk 1.2.x is allready very stable and should stay like this for now : - JK 1.2.x is now on bug-fix only mode. - AJP_PROXY/MOD_PROXY for Apache 2.1.x (built-in) Should we start a new AJP/JK/whatever connector is another story which has been debated this summer when we speak about mod_ajp. We should first be very prudent since users may be puzzled by : jk 1.2.x, jk 2.x, mod_webapp, ajp_proxy/mod_proxy, anewstufffwecouldimagine. Since ajp_proxy/mod_proxy devel goes outside jakarta land, httpd-dev and will be present only in Apache 2.1.x, may be there is a need for a new piece of code for IIS/DOMINO/Apache1.3 or even Apache 2.x but we should list the requested features missing in jk 1.2.x I suggest take a look about what was detailed in mod_ajp thread (July 2004) and see if a new consensus could appears. On Mon, 11 Oct 2004 16:21:44 -0700, Bill Barker <[EMAIL PROTECTED]> wrote: > > - Original Message - > From: "Dave Oxley" <[EMAIL PROTECTED]> > To: "Tomcat Developers List" <[EMAIL PROTECTED]> > Sent: Monday, October 11, 2004 3:35 PM > Subject: Re: JK Todo List > > > So is JK2 dead because of proxy_ajp? Why doesn't JK2 just replace JK? > > > > JK2 is dead because (like mod_webapp before it :), it failed to attract a > community interested in maintaining it. You might as well ask 'why doesn't > mod_webapp just replace JK?' > > > > > Dave. > > > > > > > > - > > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
Henri Gomez wrote: True, in ASF land as in other community, it's the users and developpers base which make a solution/product successfull or forgotten. BTW, jk 1.2.x is allready very stable and should stay like this for now : - JK 1.2.x is now on bug-fix only mode. - AJP_PROXY/MOD_PROXY for Apache 2.1.x (built-in) Should we start a new AJP/JK/whatever connector is another story which has been debated this summer when we speak about mod_ajp. We should first be very prudent since users may be puzzled by : jk 1.2.x, jk 2.x, mod_webapp, ajp_proxy/mod_proxy, anewstufffwecouldimagine. Since ajp_proxy/mod_proxy devel goes outside jakarta land, httpd-dev and will be present only in Apache 2.1.x, may be there is a need for a new piece of code for IIS/DOMINO/Apache1.3 or even Apache 2.x but we should list the requested features missing in jk 1.2.x For IIS/Domino - I think having it maintained and developed by apache is a waste. In both mod_jk and mod_jk2 we pay a significant price for trying to be "multi-server", and it seems clear this is a feature that only few people want. If an external project wants to create an IIS connector based on mod_ajp or jk - that's great. But they should do it taking full advantage of whatever IIS provides, including consistent config, etc. I suggest take a look about what was detailed in mod_ajp thread (July 2004) and see if a new consensus could appears. On Mon, 11 Oct 2004 16:21:44 -0700, Bill Barker <[EMAIL PROTECTED]> wrote: - Original Message - From: "Dave Oxley" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Monday, October 11, 2004 3:35 PM Subject: Re: JK Todo List So is JK2 dead because of proxy_ajp? Why doesn't JK2 just replace JK? JK2 is dead because (like mod_webapp before it :), it failed to attract a community interested in maintaining it. You might as well ask 'why doesn't mod_webapp just replace JK?' There are also technical reasons I think. Like the attempt to "object oriented C" but without using one of the existing solutions. And not droping featurea from mod_jk. But you're right - lack of community interest was the main problem. Costin Dave. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
+1, will help as much as possible On Fri, 08 Oct 2004 13:28:49 +0200, Mladen Turk <[EMAIL PROTECTED]> wrote: > Hi, > > Here is my Todo List for JK: > > - Documentation > - Use Apache coding style (already done 90%) using simple .indent.pro > - Fix all 64/32 bit compatibility issues. > - Backport IIS Worker thread pool from JK2. > - Backport some ajp messaging stuff from proxy_ajp (mostly performance). > - Backport shared memory from JK2 for load balancer worker. > > What's more important: > > - Documentation > - Put the JK2 in 'maintainer' mode. > - Inform our users about that decision. > - Inform out users that we are still in native<->tomcat business :) > > Long term plans: > > - Documentation > - Backport unix sockets from JK2 > - Backport JNI from JK2 with lots improvements. > - Use 1.4 API on Java side > - Add full AJP14 protocol support > - Add encryption and compression to AJP protocol > - APR-ize JK > > Regards, > MT. > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
Mladen Turk wrote: Hi, Here is my Todo List for JK: - Documentation - Use Apache coding style (already done 90%) using simple .indent.pro - Fix all 64/32 bit compatibility issues. - Backport IIS Worker thread pool from JK2. - Backport some ajp messaging stuff from proxy_ajp (mostly performance). - Backport shared memory from JK2 for load balancer worker. What's more important: - Documentation - Put the JK2 in 'maintainer' mode. - Inform our users about that decision. - Inform out users that we are still in native<->tomcat business :) Long term plans: - Documentation - Backport unix sockets from JK2 - Backport JNI from JK2 with lots improvements. I still don't see benefits in JNI as a transport for JK. Only trouble (no matter how I look at it, it seems like it would actually make the whole system much less robust) and complexity. Did I miss something ? - Use 1.4 API on Java side - Add full AJP14 protocol support - Add encryption and compression to AJP protocol - APR-ize JK Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
Remy Maucherat wrote: - Backport JNI from JK2 with lots improvements. I still don't see benefits in JNI as a transport for JK. Only trouble (no matter how I look at it, it seems like it would actually make the whole system much less robust) and complexity. Did I miss something ? The JNI was not meant to be used for transport layer. Sorry for the confusion. It will became a part of dynamic configuration, so that we don't need to write everything in C. Still this is very early draft, and it should be at the end of list, cause it might happened that it simply won't work :). MT. smime.p7s Description: S/MIME Cryptographic Signature
Re: JK Todo List
Remy Maucherat wrote: - Backport JNI from JK2 with lots improvements. I still don't see benefits in JNI as a transport for JK. Only trouble (no matter how I look at it, it seems like it would actually make the whole system much less robust) and complexity. Did I miss something ? I have to agree - for Apache ( even 2 ) the complexity of multiprocess is too big and it's not worth it in almost all cases. But having a jni library to access OS-specific features is not a bad idea. For example registry, change UID ( I know c-daemon could do the same), unix sockets, etc. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
Over all, I don't, personally, think that it's worth trying to build on the existing Jk code base. However, if you have an itch - Original Message - From: "Mladen Turk" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Friday, October 08, 2004 4:28 AM Subject: JK Todo List Hi, Here is my Todo List for JK: - Documentation - Use Apache coding style (already done 90%) using simple .indent.pro - Fix all 64/32 bit compatibility issues. - Backport IIS Worker thread pool from JK2. - Backport some ajp messaging stuff from proxy_ajp (mostly performance). - Backport shared memory from JK2 for load balancer worker. What's more important: - Documentation - Put the JK2 in 'maintainer' mode. - Inform our users about that decision. - Inform out users that we are still in native<->tomcat business :) Long term plans: - Documentation - Backport unix sockets from JK2 - Backport JNI from JK2 with lots improvements. I agree with Remy here. It's not worth doing with the existing codebase. If you want JNI, you need to do it again from scratch. - Use 1.4 API on Java side - Add full AJP14 protocol support -0. This is what proxy_ajp is for. - Add encryption and compression to AJP protocol - APR-ize JK I'm very strongly -1 on requiring APR in JK. The main purpose of JK is for Luddites (myself included) who are still using Apache 1.3. Regards, MT. 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: JK Todo List
Bill Barker wrote: Over all, I don't, personally, think that it's worth trying to build on the existing Jk code base. However, if you have an itch Well, we deceased JK2, for Apache2.1 we have proxy_ajp. Until Apache2.1 becomes the only server around the net, I'll stick with JK for all those not running my preferred web server :). MT. smime.p7s Description: S/MIME Cryptographic Signature
Re: JK Todo List
Mladen Turk wrote: Bill Barker wrote: Over all, I don't, personally, think that it's worth trying to build on the existing Jk code base. However, if you have an itch Well, we deceased JK2, for Apache2.1 we have proxy_ajp. Until Apache2.1 becomes the only server around the net, I'll stick with JK for all those not running my preferred web server :). Right. However, I think JK 1.2.x needs some level of stability. So APR, large architectural changes, etc seem bad ideas. Of your list, I think documentation (yah !) and the Unix sockets backport would be good (if not too complex), but that's about it. Modifications to the Java side is something independent. The new direction is basically making Apache (which has a continued overwhelming market share) the preferred native webserver, with the others still being supported, but with a limited feature set. For the long term, if you would want better support for the other servers, you can start a 100% APR replacement for JK 1.2 (I think it was a bit like your mod_ajp) if you want to. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Todo List
Remy Maucherat wrote: Over all, I don't, personally, think that it's worth trying to build on the existing Jk code base. However, if you have an itch Well, we deceased JK2, for Apache2.1 we have proxy_ajp. Until Apache2.1 becomes the only server around the net, I'll stick with JK for all those not running my preferred web server :). Right. However, I think JK 1.2.x needs some level of stability. So APR, large architectural changes, etc seem bad ideas. Of your list, I think documentation (yah !) and the Unix sockets backport would be good (if not too complex), but that's about it. Modifications to the Java side is something independent. I think it would rise the stability, but introduce new problems like building APR, etc.. so you are probably right. We'll see. For the long term, if you would want better support for the other servers, you can start a 100% APR replacement for JK 1.2 (I think it was a bit like your mod_ajp) if you want to. I'm surely do. The IIS6 support is something to chase :). MT. smime.p7s Description: S/MIME Cryptographic Signature
Re: JK Todo List
From: "Mladen Turk" <[EMAIL PROTECTED]> > Remy Maucherat wrote: > >>> Over all, I don't, personally, think that it's worth trying to build > >>> on the existing Jk code base. However, if you have an itch > >> > >> Well, we deceased JK2, for Apache2.1 we have proxy_ajp. > >> Until Apache2.1 becomes the only server around the net, > >> I'll stick with JK for all those not running my preferred > >> web server :). > > > > Right. However, I think JK 1.2.x needs some level of stability. So APR, > > large architectural changes, etc seem bad ideas. Of your list, I think > > documentation (yah !) and the Unix sockets backport would be good (if > > not too complex), but that's about it. Modifications to the Java side is > > something independent. > > > > I think it would rise the stability, but introduce new problems like > building APR, etc.. so you are probably right. We'll see. I'm not very happy with the integrated APR build in JK2 for Apache 1.3. I did much of the work there and if I had to do it again, I'd prefer APR to be a build/runtime depend, built separately by the user first and loaded with LoadFile directive. With respect to JK, I'd rather not see it get APR'ized. Mostly so that Apache 1.3 support is kept simple and straightforward. > > For the long term, if you would want better support for the other > > servers, you can start a 100% APR replacement for JK 1.2 (I think it was > > a bit like your mod_ajp) if you want to. > > > > I'm surely do. The IIS6 support is something to chase :). > > MT. > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]