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.
If we agree on suc
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.
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
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
> 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 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
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 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 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.
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
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.
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.
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
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
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
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
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
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
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.
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
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
> - 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
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,
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 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 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
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
27 matches
Mail list logo
