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 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.
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
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.
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.
Regards,
Rainer
2009/3/24 Rainer Jung<rainer.j...@kippdata.de>:
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 such a plan, the more difficult discussion is about the goals
of the JK trunk. I basically see two options:
Option A) The big new thing
We collected ideas for a JK3 some years ago. Those included e.g. migrating
to APR and other big changes.
Option B) Proceed with relatively small changes and feature additions, which
are mostly locally. So then trunk would head for a 1.3 release.
I'm personally are in favour of option B. Not because of technical reasons,
but because of limited working time for the development task. I'm very
concerned, that if we decide for option A, we'll not be able to proceed far
enough for a stable release.
If we do option B: is it worth while? I think yes, there are still lots of
interesting and easy to implement features we can provide. For instance
- 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 much more.
Comments?
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
