RE: Rename jK2 to mod_jk2 ?
So JkMount in Jk2 will point to NOP ? - 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: Monday, February 18, 2002 8:36 PM To: Tomcat Developers List Subject: RE: Rename jK2 to mod_jk2 ? On Mon, 18 Feb 2002, GOMEZ Henri wrote: Any objection to see JkMount renamed to Jk2Mount in mod_jk2 and in general all Directive subject to collisions with the original mod_jk... I have one :-) If we change JkMount, I would rather change it into nothing ( i.e. get rid of it ). It should be in just for backward compatibility with jk1. I like this aproach to backward compatibility - i.e. including both the old code and the new code, sort of 'perfect' backward compat. Instead of JkMount we should use either Location path=/foo JkWebapp worker ajp13 /Location or jkurimap.properties - which is already used for IIS and has more 'potential' to support dynamic updates to the config ( without apache restart ). This way we'll have a consistent server-independent config ( properties ) and a server-optimized config ( location uses the internal mapper which is more optimized and we avoid duplicating the mapping ). 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: Rename jK2 to mod_jk2 ?
On Tue, 19 Feb 2002, GOMEZ Henri wrote: So JkMount in Jk2 will point to NOP ? No, it'll be commented out ( as long as we use jk in parallel with jk2 ). ( to avoid name conflicts ). When jk2 is ready and we decide it's time to stop supporting jk1, we can add back JkMount for backward compatibility, as an equivalent to adding mappings in the properties file ( which it is ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Rename jK2 to mod_jk2 ?
Ok not a nop but a comment - 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: Tuesday, February 19, 2002 5:01 PM To: Tomcat Developers List Subject: RE: Rename jK2 to mod_jk2 ? On Tue, 19 Feb 2002, GOMEZ Henri wrote: So JkMount in Jk2 will point to NOP ? No, it'll be commented out ( as long as we use jk in parallel with jk2 ). ( to avoid name conflicts ). When jk2 is ready and we decide it's time to stop supporting jk1, we can add back JkMount for backward compatibility, as an equivalent to adding mappings in the properties file ( which it is ). 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: Rename jK2 to mod_jk2 ?
Any objection to see JkMount renamed to Jk2Mount in mod_jk2 and in general all Directive subject to collisions with the original mod_jk... The both could be installed at the same time ... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Rename jK2 to mod_jk2 ?
On Mon, 18 Feb 2002, GOMEZ Henri wrote: Any objection to see JkMount renamed to Jk2Mount in mod_jk2 and in general all Directive subject to collisions with the original mod_jk... I have one :-) If we change JkMount, I would rather change it into nothing ( i.e. get rid of it ). It should be in just for backward compatibility with jk1. I like this aproach to backward compatibility - i.e. including both the old code and the new code, sort of 'perfect' backward compat. Instead of JkMount we should use either Location path=/foo JkWebapp worker ajp13 /Location or jkurimap.properties - which is already used for IIS and has more 'potential' to support dynamic updates to the config ( without apache restart ). This way we'll have a consistent server-independent config ( properties ) and a server-optimized config ( location uses the internal mapper which is more optimized and we avoid duplicating the mapping ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Rename jK2 to mod_jk2 ?
GOMEZ Henri wrote: What about renaming native2 (jk2) in JTC to mod_jk2 and jk2_module ? If we consider native2 as a remplacement for the native of mod_jk, no. That is just a new version. If you thing of easy testing may be... I have libjk.so from native and mod_jk.so from native2 and I stop/start Apache for testing both. It will allow us to install both modules at the same times and test original mod_jk and new mod_jk. It will be need to rename all non static references, variables functions, but I could do that, by suffixing with jk2_ : And to be consistent, it could be nice to suffix the native, original mod_jk, with jk_ If you agree, I could do this quickly, but JTC developpers shouldn't do updates for 1-3 hours... And that will be a big commit ;-) 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: Rename jK2 to mod_jk2 ?
If we consider native2 as a remplacement for the native of mod_jk, no. That is just a new version. If you thing of easy testing may be... I have libjk.so from native and mod_jk.so from native2 and I stop/start Apache for testing both. The idea is that native2 will replace more or less quickly the good old mod_jk and it will be better (IMO) to start called mod_jk with a new name, maybe mod_jk2. And some people may want to test BOTH at the same time, so the need to rename : mod_jk.so to mod_jk2.so mod_jk.c to mod_jk2.c jk_module to jk2_module and the jk2_ prefix to avoid problems with non-static refs. Also it will help us do stuff like : IfModule mod_jk.c ... /IfModule IfModule mod_jk2.c ... /IfModule This dual config could help us determine problems by having one virtual server test against a Tomcat using mod_jk/ajp13 and another virtual testing against the same Tomcat using mod_jk2/ajp13-ajp14 PS: Yes the commit will be important -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Rename jK2 to mod_jk2 ?
On Fri, 15 Feb 2002, GOMEZ Henri wrote: What about renaming native2 (jk2) in JTC to mod_jk2 and jk2_module ? +1 if you talk about the binary. -0 if you talk about directory/file names. In mod_jk2 we already removed a lot of 'public' symbols that could conflict if both modules are loaded. Instead of doing a mechanical replace, I would do it gradually, and maybe finish the 'virtualization' of jk2. I think the effects are very good, it improves code readability and extensibility. What I'm talking about is using JNI-style ( or module style ), with structures and funcion pointer. ( ok, that's kind-of OO programming in C, but OO is not that bad :-) It will allow us to install both modules at the same times and test original mod_jk and new mod_jk. That's a very good idea, it allows us to ship both and have a 'backup' plan if something doesn't work. It will be need to rename all non static references, variables functions, but I could do that, by suffixing with jk2_ : If you want, you can go ahead with that ( but in time I would still like to continue to organize the code with fewer globals and more objects ) And to be consistent, it could be nice to suffix the native, original mod_jk, with jk_ If you agree, I could do this quickly, but JTC developpers shouldn't do updates for 1-3 hours... I agree with changing the names of non-statics in native2, but need more time to think about changing dir names. There are build files, cvs history, habbits that will change as well. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Rename jK2 to mod_jk2 ?
What about renaming native2 (jk2) in JTC to mod_jk2 and jk2_module ? +1 if you talk about the binary. -0 if you talk about directory/file names. No only source/binary, without touching anything in CVS layout. It will be need to rename all non static references, variables functions, but I could do that, by suffixing with jk2_ : If you want, you can go ahead with that ( but in time I would still like to continue to organize the code with fewer globals and more objects ) +1 for more globals And to be consistent, it could be nice to suffix the native, original mod_jk, with jk_ If you agree, I could do this quickly, but JTC developpers shouldn't do updates for 1-3 hours... I agree with changing the names of non-statics in native2, but need more time to think about changing dir names. There are build files, cvs history, habbits that will change as well. No change in CVS tree, just in source to avoid conflict between mod_jk(s) even if one is a jk_module and the other jk2_module Rigth now, I'll wait for JTC developpers 'green ligth' to do the changes in JTC native2 ONLY :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Rename jK2 to mod_jk2 ?
On Fri, 15 Feb 2002, GOMEZ Henri wrote: I agree with changing the names of non-statics in native2, but need more time to think about changing dir names. There are build files, cvs history, habbits that will change as well. No change in CVS tree, just in source to avoid conflict between mod_jk(s) even if one is a jk_module and the other jk2_module Rigth now, I'll wait for JTC developpers 'green ligth' to do the changes in JTC native2 ONLY :) Green light from me. It's an excelent idea. Now a small problem - what about directives ? I don't think you can have the same name in 2 modules ( I'm talking about httpd.conf ). If we run them in parallel, it's a great pretext to use the new config style for native2 ( with Location, JkSet, Webapp, etc ). JkSet foo bar is equivalent with foo=bar in workers.properties. All jk2 settings can be done in either workers.properties or httpd.conf ( or both ). The JkWebapp in a Location context allows setting per webapp properties, like JkWebapp worker ajp13 JkMount is not needed in jk2 - Location is the recomended way to mount ( it integrates with the native apache mapper ), and IIS-style urimap.properties should be the second mechanism ( if the internal jk mapper is used ). I think it's a good idea to use the new 'style' for jk2. When it's ready, we can add back the jk1-style directives for backward compatibility, but as long as jk1 is used in parallel it'll provide backward compat by itself. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Rename jK2 to mod_jk2 ?
No change in CVS tree, just in source to avoid conflict between mod_jk(s) even if one is a jk_module and the other jk2_module Rigth now, I'll wait for JTC developpers 'green ligth' to do the changes in JTC native2 ONLY :) Green light from me. It's an excelent idea. Now a small problem - what about directives ? I don't think you can have the same name in 2 modules ( I'm talking about httpd.conf ). Exact If we run them in parallel, it's a great pretext to use the new config style for native2 ( with Location, JkSet, Webapp, etc ). +1, new JK, new config style JkSet foo bar is equivalent with foo=bar in workers.properties. All jk2 settings can be done in either workers.properties or httpd.conf ( or both ). The JkWebapp in a Location context allows setting per webapp properties, like JkWebapp worker ajp13 JkMount is not needed in jk2 - Location is the recomended way to mount ( it integrates with the native apache mapper ), and IIS-style urimap.properties should be the second mechanism ( if the internal jk mapper is used ). I think it's a good idea to use the new 'style' for jk2. When it's ready, we can add back the jk1-style directives for backward compatibility, but as long as jk1 is used in parallel it'll provide backward compat by itself. Yep. I'm starting looking where to apply changes :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
