Costin Manolache wrote:
On Tue, Mar 24, 2009 at 8:13 AM, Henri Gomez <henri.go...@gmail.com> 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 examples of new features in my original mesage. You can find
more examples in our TODO file, e.g.
http://svn.eu.apache.org/viewvc/tomcat/connectors/trunk/jk/native/TODO.txt?revision=757083
Thanks
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. But mod_proxy as it is today
doesn't have a clear separation of proxy, balancing and ajp, despite the
various module names.
Nope, I suggested moving the actual mod_jk to httpd or may be a pure
APR version of jk (without the #define #ifdef ...)
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 pretty high for me alone.
No problem but you should find more friends to works on it, mod_warp
and jk2 disapears too quickly since they have too few supporters ,)
I agree - there is a big risk that you'll just waste your time if you
branch. Even worse -
you may risk other people time :-)
AFAIK the current trunk is open for features and changes. You can implement
most
new features with #ifdef or configs protecting the new code, to reduce the
risks,
and you can do them incrementally.
APR is probably the only thing in your list that wouldn't work well
incrementally -
but I'm not so sure it's worth it. If it really makes your life easier for
the new features
I guess you can probably just use it for the new code ( with makefile magic
).
I agree with Remy that mod_cluster seems to add useful feature - so +1 to
add better features in mod_jk :-). Better clustering - in particular better
support
for multiple apache frontends talking to large number of tomcat backends
would
be quite interesting. And if this requires a new protocol - I would just
pick one
of the many existing RPC standards, and maybe move the loadbalancing
decisions
to a dedicated service. I mean - no need to modify AJP protocol if you need
new
features :-)
Even it is a bit of topic. mod_cluster use HTTP as protocol to send the
information about the cluster nodes to httpd.
Cheers
Jean-Frederic (hoping to see Costin committing code in Tomcat like in
the old time :-) )
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
