Re: Current Connector Development

2005-02-14 Thread Günter Knauf
Hi Mladen,
 First, I must say that mod_jk does not require APR neither it will.
 So your concerns about dropping 1.3 support are not standing.
ok, good.

 The main reason for continuing mod_jk development is the fact
 that mod_jk was more stable on more platforms then jk2 was.
 Adding new things to mod_jk does not mean it will be less unstable
 then it is or is not already. What I'm trying to do is to port back
 all the good things from jk2 like dynamic config and status, without
 braking any existing platform supported.

 Also, the current development version is just like said *development*.
 If it's broken between two commits, it doesn't mean it will stay as
 such :). AFAICS we only have one or two parameter conversion issues.
sure, and that was not my concern.

 And sure, we tried various ways for connectors, that sometimes lead
 to quite fuzzy directions and agreements.
 As things are now standing, mod_jk will continue support for the
 following servers:
 apache 1.3.x, apache 2.0.x, IIS, Netscape. (Domino is down I think,
 because nobody cares, thought).
ok, fine. BTW. for Netscape on NW applies the same as for Apache 1.3.x.

 Next release will have jk_status page for dynamic config and status,
 as well as runtime workers.properties monitoring and reloading.
cool!
 This will only allow changing of existing parameters, not creating new
 workers like in jk2.
 This is also the last of major design change to mod_jk that I'm willing
 to port back from jk2, and after that it will be more or less frozen
 from design perspective. There was a try to implement AJP14 protocol,
 but IMHO mod_jk design doesn't allow us to do that.

 Apache 2.1/2.2 has mod_proxy_ajp with the active development, and
 surprisingly stable :).
what's missing for 2.0.x? cant we just compile it for the 2.0.x series too?

thanks very much for the update - although one point you didnt mention:
what was the reason that you stopped with mod_jk2? 

greets, Guenter.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Current Connector Development

2005-02-14 Thread Mladen Turk
Günter Knauf wrote:
As things are now standing, mod_jk will continue support for the
following servers:
apache 1.3.x, apache 2.0.x, IIS, Netscape. (Domino is down I think,
because nobody cares, thought).
ok, fine. BTW. for Netscape on NW applies the same as for Apache 1.3.x.
Sure ;).
Netscape iPlanet/SunOne is supported, others are fully supported.

Apache 2.1/2.2 has mod_proxy_ajp with the active development, and
surprisingly stable :).
what's missing for 2.0.x? cant we just compile it for the 2.0.x series too?
Well, you can try, and it will probably build, but couple of things are
missing:
1. Shared memory support
2. Waitable resource pools.
So, it can be used, but not for the production thought.
Also, proxy protocol support is different in 2.1, so not sure
if it comply to RFC if used inside 2.0.
thanks very much for the update - although one point you didnt mention:
what was the reason that you stopped with mod_jk2? 

Yes I did (It was BTW not solely my idea - browse the archive).
jk2 was not as stable as jk, particularly on apache 1.3, and IIS.
We had new mod_proxy, and maintaining three connectors would be way
too much considering the number of active developers. We had
reasonably stable product (jk), that needed just a little bit
push-up with all the good things that we know how and why worked
in jk2.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Current Connector Development

2005-02-14 Thread Remy Maucherat
Mladen Turk wrote:
Apache 2.1/2.2 has mod_proxy_ajp with the active development, and
surprisingly stable :).
Great, but without a release, it's a bit useless :(
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Current Connector Development

2005-02-14 Thread Mladen Turk
Remy Maucherat wrote:

Apache 2.1/2.2 has mod_proxy_ajp with the active development, and
surprisingly stable :).
Great, but without a release, it's a bit useless :(
Yes.
Now that 2.0.53 is released, the people will have more time
to work on 2.1.3 release I hope.
But that's solely dependable on httpd developers :).
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Current Connector Development

2005-02-14 Thread Remy Maucherat
Mladen Turk wrote:
Remy Maucherat wrote:

Apache 2.1/2.2 has mod_proxy_ajp with the active development, and
surprisingly stable :).

Great, but without a release, it's a bit useless :(
Yes.
Now that 2.0.53 is released, the people will have more time
to work on 2.1.3 release I hope.
And 2.2.0 before the end of the world ?
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Current Connector Development

2005-02-14 Thread Mladen Turk
Remy Maucherat wrote:
Great, but without a release, it's a bit useless :(
Yes.
Now that 2.0.53 is released, the people will have more time
to work on 2.1.3 release I hope.
And 2.2.0 before the end of the world ?
He, he.
Taking into account the time needed to release the first 2.0 GA,
I wouldn't be surprised ;).
BTW, that's the one of the reasons to continue JK development.
It will hang around for a while :).
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Current Connector Development

2005-02-14 Thread Henri Gomez
And to add some goodies like configuration settings while Apache web
server is running :)


On Mon, 14 Feb 2005 13:08:36 +0100, Mladen Turk [EMAIL PROTECTED] wrote:
 Remy Maucherat wrote:
 
  Great, but without a release, it's a bit useless :(
  Yes.
  Now that 2.0.53 is released, the people will have more time
  to work on 2.1.3 release I hope.
 
  And 2.2.0 before the end of the world ?
 
 
 He, he.
 Taking into account the time needed to release the first 2.0 GA,
 I wouldn't be surprised ;).
 
 BTW, that's the one of the reasons to continue JK development.
 It will hang around for a while :).
 
 Mladen.
 
 -
 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]



Current Connector Development

2005-02-13 Thread Günter Knauf
Hi Mladen,
appologies that I couldnt closely follow the connector development in the past 
year, so I'm somewhat suprised about all the recent directions; and cant 
really understand them; so I would greatly appreciate if you could do a 
summarize why you are currently again developing to mod_jk...

well, what I see is this:
after more than one year stagnation on the mod_jk2 connector we started again, 
made it comilable on all platforms, and improved it a lot, cleaned up the code 
cause we made APR mandatory, and did a release. Many users where happy with it, 
and a lot of new users came and saw 'hey, thats the new connector' and tried 
it; others migrated and found mod_jk2 faster over mod_jk.

Few time later you are not lucky with mod_jk2, and you just want to start 
another conenctor; and after some discussion you agreed to create mod_proy_ajp.

Then suddenly, just after mod_proy_ajp is just born - and I cant believe that 
it is only cause I couldnt follow up with development - I see that you state 
that mod_jk2 has come to its end cause of no developers and no users 
interest

really suprised of this all I get mail from Novell asking for help since mod_jk 
is now broken.
we have just fixed it so we could folow up with the 1.2.8 release, and you 
continue to break it ..

If I recall correctly we commonly agreed with last time's discussion that we 
stay with mod_jk _as_is_ and dont move to APR or such, and that mod_jk should 
mainly remain for our Apache 1.3.x users while Apache 2.x users should use 
mod_jk2 or also now mod_proxy_ajp - so what has changed this direction now??

Mladen, if you continue with the mod_jk development I fear that we end up the 
same as with mod_jk2: you will certainly break Apache 1.3.x support - at least 
on NetWare, and that's _very_ bad cause it's a shipping product of NetWare 6.

greets, Guenter.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Current Connector Development

2005-02-13 Thread Jess Holle
Günter Knauf wrote:
Hi Mladen,
appologies that I couldnt closely follow the connector development in the past 
year, so I'm somewhat suprised about all the recent directions; and cant 
really understand them; so I would greatly appreciate if you could do a 
summarize why you are currently again developing to mod_jk...
well, what I see is this:
after more than one year stagnation on the mod_jk2 connector we started again, 
made it comilable on all platforms, and improved it a lot, cleaned up the code 
cause we made APR mandatory, and did a release. Many users where happy with it, 
and a lot of new users came and saw 'hey, thats the new connector' and tried 
it; others migrated and found mod_jk2 faster over mod_jk.
Few time later you are not lucky with mod_jk2, and you just want to start 
another conenctor; and after some discussion you agreed to create mod_proy_ajp.
Then suddenly, just after mod_proy_ajp is just born - and I cant believe that 
it is only cause I couldnt follow up with development - I see that you state 
that mod_jk2 has come to its end cause of no developers and no users 
interest
really suprised of this all I get mail from Novell asking for help since mod_jk 
is now broken.
we have just fixed it so we could folow up with the 1.2.8 release, and you 
continue to break it ..
If I recall correctly we commonly agreed with last time's discussion that we 
stay with mod_jk _as_is_ and dont move to APR or such, and that mod_jk should 
mainly remain for our Apache 1.3.x users while Apache 2.x users should use 
mod_jk2 or also now mod_proxy_ajp - so what has changed this direction now??
Mladen, if you continue with the mod_jk development I fear that we end up the same as with mod_jk2: you will certainly break Apache 1.3.x support - at least on NetWare, and that's _very_ bad cause it's a shipping product of NetWare 6.
 

I don't see mod_jk ending up the same as mod_jk2 in that:
 1) The configuration is relatively sane as compared to that of mod_jk2
 2) There are many reasonably stable mod_jk versions, so even *if* 
Mladen screws up a release there are plenty of alternative mod_jk versions.
   * On the other hand, there never really was a stable mod_jk2 
release -- every release tested continued to exhibit serious corner case 
issues.

It would be great if everyone could move to mod_proxy_ajp, but I believe 
that still requires Apache 2.1/2.2 -- which means it has not yet arrived 
for the majority of us.

I personally applaud Mladen for his efforts to fix/improve/maintain 
mod_jk given that that is the reality for most of us.

--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Current Connector Development

2005-02-13 Thread Günter Knauf
Hi,
 I don't see mod_jk ending up the same as mod_jk2 in that:
   1) The configuration is relatively sane as compared to that of mod_jk2
   2) There are many reasonably stable mod_jk versions, so even *if*
 Mladen screws up a release there are plenty of alternative mod_jk
 versions.
unfortunately the situation on NetWare platform is a bit other, just to make 
that clear to everyone:
although APR is fully functional on NetWare it can only be consumed by Apache 
2.x and never from Apache 1.3.x - hence if APR gets mandatory for mod_jk then 
NetWare Apache 1.3 gets broken (and perhaps not only NetWare) for ever. The 
same applies to SHM.

 It would be great if everyone could move to mod_proxy_ajp, but I believe
 that still requires Apache 2.1/2.2 -- which means it has not yet arrived
 for the majority of us.
it would be of interest if we can now already compile the module with the 2.0.x 
series; 
then I would love to provide binaries for NetWare and Win32 on my site, and we 
will see what the users think...

 I personally applaud Mladen for his efforts to fix/improve/maintain
 mod_jk given that that is the reality for most of us.
the same from my side - and to make that absolutely clear: that was nothing 
against Mladen's work, but more a curious question why directions changed, and 
a prognose what this will probably cause for NetWare.

Guenter.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Current Connector Development

2005-02-13 Thread Mladen Turk
Hi,
Well, you put it right. To some point ;)
First, I must say that mod_jk does not require APR neither it will.
So your concerns about dropping 1.3 support are not standing.
The main reason for continuing mod_jk development is the fact
that mod_jk was more stable on more platforms then jk2 was.
Adding new things to mod_jk does not mean it will be less unstable
then it is or is not already. What I'm trying to do is to port back
all the good things from jk2 like dynamic config and status, without
braking any existing platform supported.
Also, the current development version is just like said *development*.
If it's broken between two commits, it doesn't mean it will stay as
such :). AFAICS we only have one or two parameter conversion issues.
And sure, we tried various ways for connectors, that sometimes lead
to quite fuzzy directions and agreements.
As things are now standing, mod_jk will continue support for the
following servers:
apache 1.3.x, apache 2.0.x, IIS, Netscape. (Domino is down I think,
because nobody cares, thought).
Next release will have jk_status page for dynamic config and status,
as well as runtime workers.properties monitoring and reloading.
This will only allow changing of existing parameters, not creating new
workers like in jk2.
This is also the last of major design change to mod_jk that I'm willing
to port back from jk2, and after that it will be more or less frozen
from design perspective. There was a try to implement AJP14 protocol,
but IMHO mod_jk design doesn't allow us to do that.
Apache 2.1/2.2 has mod_proxy_ajp with the active development, and
surprisingly stable :).
Regards,
Mladen.
Günter Knauf wrote:
Hi Mladen,
appologies that I couldnt closely follow the connector development in the past 
year, so I'm somewhat suprised about all the recent directions; and cant 
really understand them; so I would greatly appreciate if you could do a 
summarize why you are currently again developing to mod_jk...
well, what I see is this:
after more than one year stagnation on the mod_jk2 connector we started again, 
made it comilable on all platforms, and improved it a lot, cleaned up the code 
cause we made APR mandatory, and did a release. Many users where happy with it, 
and a lot of new users came and saw 'hey, thats the new connector' and tried 
it; others migrated and found mod_jk2 faster over mod_jk.
Few time later you are not lucky with mod_jk2, and you just want to start 
another conenctor; and after some discussion you agreed to create mod_proy_ajp.
Then suddenly, just after mod_proy_ajp is just born - and I cant believe that 
it is only cause I couldnt follow up with development - I see that you state 
that mod_jk2 has come to its end cause of no developers and no users 
interest
really suprised of this all I get mail from Novell asking for help since mod_jk 
is now broken.
we have just fixed it so we could folow up with the 1.2.8 release, and you 
continue to break it ..
If I recall correctly we commonly agreed with last time's discussion that we 
stay with mod_jk _as_is_ and dont move to APR or such, and that mod_jk should 
mainly remain for our Apache 1.3.x users while Apache 2.x users should use 
mod_jk2 or also now mod_proxy_ajp - so what has changed this direction now??
Mladen, if you continue with the mod_jk development I fear that we end up the 
same as with mod_jk2: you will certainly break Apache 1.3.x support - at least 
on NetWare, and that's _very_ bad cause it's a shipping product of NetWare 6.
greets, Guenter.

-
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]