I still don't understand why don't you just ship 2 config files, or even
change the defaults and just
provide a config that restores old values.
But it looks like a reasonable plan - next step will be to ship 1.2.28,
label it - and branch if you want
( branches are cheap if you don't plan to do a l
On 25.03.2009 19:33, Costin Manolache wrote:
On Wed, Mar 25, 2009 at 11:17 AM, Rainer Jungwrote:
Thanks Costin for coming back to this topic. Collecting ideas for major
redesigns could be done, but that was not my intention. I don't see enough
time available for doing the big stuff, but I want t
On Wed, Mar 25, 2009 at 11:17 AM, Rainer Jung wrote:
> On 25.03.2009 18:38, Costin Manolache wrote:
>
>> This thread was more about where to implement new features - if the goal
>> is
>> a 'redesign
>> from scratch' than maybe sandbox or a branch is a better place, but we
>> tried
>> that twice
>>
On 25.03.2009 18:38, Costin Manolache wrote:
This thread was more about where to implement new features - if the goal is
a 'redesign
from scratch' than maybe sandbox or a branch is a better place, but we tried
that twice
(jk2 and webapp) and I don't think there are enough people interested in
suc
On Wed, Mar 25, 2009 at 9:12 AM, Henri Gomez wrote:
> 2009/3/25 William A. Rowe, Jr. :
> > Mladen Turk wrote:
> >>
> >> The problem with mod_proxy and mod_cluster is the
> >> fact they are targeted for a *single* web server (httpd)
> >
> > Which varies from a one off poorly defined protocol how,
> - Saving changes done by the status worker
> - Rotating log file for IIS
> - Improving the status worker display
> - Adding more connection parameters for dynamic management
> - Adding more functionality to the watchdog thread (e.g. URL probing)
And for a better load balancing, adding a way to g
2009/3/25 William A. Rowe, Jr. :
> Mladen Turk wrote:
>>
>> The problem with mod_proxy and mod_cluster is the
>> fact they are targeted for a *single* web server (httpd)
>
> Which varies from a one off poorly defined protocol how, exactly?
>
>> They don't have the generic web server API like mod_jk
Mladen Turk wrote:
The problem with mod_proxy and mod_cluster is the
fact they are targeted for a *single* web server (httpd)
Which varies from a one off poorly defined protocol how, exactly?
They don't have the generic web server API like mod_jk
does, and all of them doesn't support async b
Costin Manolache wrote:
I was thinking more as
- when all the new features are implemented and we have a replacement
protocol that has been
around ( optional ) for a while - drop the old code and branch 1.3.
This is certainly one approach, but from my humble
experience that won't do any good.
I was thinking more as
- pick a 3rd party RPC/marshalling - like thrift, protobufs, etc, use it for
all the
new cluster/etc communication - and later for HTTP forwarding too (instead
of extending AJP )
- add all the new features as separate source files, with minimal
#ifdef-controlled glue.
If th
The library approach could be a good way to help people/corps use AJP.
And it will force us to split better between AJP code/functionnality
and WebServer operation (it's not really the case today).
This AJP library could be fully APR (and so remove the pain with
#define / #ifdef...)
2009/3/24 C
On Tue, Mar 24, 2009 at 8:46 AM, Rainer Jung wrote:
> On 24.03.2009 16:29, Costin Manolache wrote:
>
>> On Tue, Mar 24, 2009 at 8:13 AM, Henri Gomez
>> wrote:
>>
>>> Why not moving into mod_proxy? If httpd were approaching a major version
change (e.g. httpd 3.0), then there would be the free
On Tue, Mar 24, 2009 at 8:57 AM, jean-frederic clere wrote:
> Costin Manolache wrote:
>
>> On Tue, Mar 24, 2009 at 8:13 AM, Henri Gomez
>> wrote:
>>
>> If you look at my message, my favourite is *not* a JK3. I'm in favor of
>>> jk
>>>
1.3. The difference for me is that 1.3 will be very
And why not works first on a jk api ?
I know companies, and some providing clustering/frontal box, who
complains since their customers ask them for jk proxing/clustering.
If we could proxy a jk API, may be using full APR, it could be easy
for them to connect with Tomcat's using AJP and it will gi
jean-frederic clere wrote:
Mladen Turk wrote:
Rainer Jung wrote:
Hello,
I'm thinking about branching JK, so adding
http://svn.apache.org/viewvc/tomcat/connectors/branches/jk1.2.x
and initially populate the branch with the contents of the 1.2.28 tag.
The motivation is to stabilize 1.2 and re
Mladen Turk wrote:
Rainer Jung wrote:
Hello,
I'm thinking about branching JK, so adding
http://svn.apache.org/viewvc/tomcat/connectors/branches/jk1.2.x
and initially populate the branch with the contents of the 1.2.28 tag.
The motivation is to stabilize 1.2 and restrict further changes on 1.
Rainer Jung wrote:
Hello,
I'm thinking about branching JK, so adding
http://svn.apache.org/viewvc/tomcat/connectors/branches/jk1.2.x
and initially populate the branch with the contents of the 1.2.28 tag.
The motivation is to stabilize 1.2 and restrict further changes on 1.2
to patches only.
Costin Manolache wrote:
On Tue, Mar 24, 2009 at 8:13 AM, Henri Gomez wrote:
If you look at my message, my favourite is *not* a JK3. I'm in favor of
jk
1.3. The difference for me is that 1.3 will be very close to 1.2 without
any
bug architectural changes like migrating to APR.
ok.
I adde
On 24.03.2009 16:29, Costin Manolache wrote:
On Tue, Mar 24, 2009 at 8:13 AM, Henri Gomez wrote:
Why not moving into mod_proxy? If httpd were approaching a major version
change (e.g. httpd 3.0), then there would be the freedom of doing big
changes to mod_proxy. But httpd is moving towards 2.4.
On Tue, Mar 24, 2009 at 8:13 AM, Henri Gomez wrote:
> > If you look at my message, my favourite is *not* a JK3. I'm in favor of
> jk
> > 1.3. The difference for me is that 1.3 will be very close to 1.2 without
> any
> > bug architectural changes like migrating to APR.
>
> ok.
>
> > I added some e
On 24.03.2009 15:40, Remy Maucherat wrote:
On Tue, 2009-03-24 at 15:24 +0100, Rainer Jung wrote:
So (and now I am talking about me personally) I think I can still add
interesting features to a mod_jk 1.3 with not to much effort, whereas
the barrior of porting existing mod_jk features to mod_prox
On 24.03.2009 16:13, Henri Gomez wrote:
Why not moving into mod_proxy? If httpd were approaching a major version
change (e.g. httpd 3.0), then there would be the freedom of doing big
changes to mod_proxy. But httpd is moving towards 2.4. That means the
architecture of mod_proxy will not change. B
> If you look at my message, my favourite is *not* a JK3. I'm in favor of jk
> 1.3. The difference for me is that 1.3 will be very close to 1.2 without any
> bug architectural changes like migrating to APR.
ok.
> I added some examples of new features in my original mesage. You can find
> more exa
On Tue, 2009-03-24 at 15:24 +0100, Rainer Jung wrote:
> So (and now I am talking about me personally) I think I can still add
> interesting features to a mod_jk 1.3 with not to much effort, whereas
> the barrior of porting existing mod_jk features to mod_proxy before
> adding the new stuff is pr
Hello Henri,
On 24.03.2009 15:15, Henri Gomez wrote:
Well a jk3 is a good idea but :
- What new features will be included ? I take a look at mod_cluster
and it seems very promising.
- Why not move jk(3) to Apache HTTPD core, like mod_proxy / mod_ajp ?
If you look at my message, my favourite
Well a jk3 is a good idea but :
- What new features will be included ? I take a look at mod_cluster
and it seems very promising.
- Why not move jk(3) to Apache HTTPD core, like mod_proxy / mod_ajp ?
2009/3/24 Rainer Jung :
> Hello,
>
> I'm thinking about branching JK, so adding
>
> http://svn.
26 matches
Mail list logo
