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 Costin Manolache <cos...@gmail.com>: > On Tue, Mar 24, 2009 at 8:46 AM, Rainer Jung <rainer.j...@kippdata.de>wrote: > >> On 24.03.2009 16:29, Costin Manolache wrote: >> >>> On Tue, Mar 24, 2009 at 8:13 AM, Henri Gomez<henri.go...@gmail.com> >>> 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. 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 :-) >>> >> >> But if we do not branch, then we need to go on doing all changes on the >> production branch. trunk is identical to 1.2 and is the only code line we do >> use at the moment. >> >> The proposal says we branch of trunk to 1.2 and keep that stable. There are >> people around here who do not like the idea of having many more 1.2.x >> releses of JK, because each new feature brings a risk of breaking the >> existing code, that is pretty stable. > > > >> >> Separate trunk and 1.2 branches would give us a chance of going a slightly >> higher risk in 1.3. Another important thing: in Jk 1.2 we follow the policy >> to mostly not change the default behaviour between the 1.2.x releases. But >> most important timeouts were created late in the release cycle, so all of >> them are of by default and as a user you need to do a pretty lengthy >> configuration for getting a good usage experience. With 1.3 we could improve >> our defaults a lot. > > > I think the mistake with jk2/webapp/etc was the same - assuming we can do > major destabilizing work ( including changes to configs, etc ) > and at some point people will just migrate - while at the same time > maintaining the 'stable' code. Which of course everyone sticks to. > > I see no reason why you can't add features to trunk. If people want to be > sure it is stable - they should review and test the changes > and make sure the new features are modular enough and don't change existing > behavior. We have labels for each release, and if > a major bug happens we can branch and release an emergency 1.2.x.y fix. But > we shouldn't say '1.2 branch is for stable work, 1.3 for > new features/risks'. All new features go to trunk, the trunk should be > mostly stable at all points - and have releases after a number of features > get added to avoid 'big change' problems. > > Timeouts and features should be set in the config - you can just ship a > 'backward compat config' and 'new config'. > > > >> >> >> 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. >>> >> >> The discussion is exactly about "how open for changes should trunk=1.2 >> stay, now that JK is pretty useful and feature rich". Many #ifdefs are a >> nightmare and using config means everything will stay off by default. One of >> the major problems we now have (with 28 released versions of history). > > > Well, trunk and 1.2 are just names. Trunk means 'active development goes > there', 1.2 is the major version and means 'we'll keep it backward > compatible until we change the label to 1.3'. > > For many of the features in your list you don't need ifdefs, just new files > and config options - and I don't see anything wrong with > having the options off in the default config file. Just add a new config > with all the options 'on' :-) > > > > >> >> 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 actually do want to proceed working incrementally in the future trunk=1.3 >> too. Exactly because there is a big risk of not enough commitment for a big >> lengthy change like the APR migration. > > > Than just leave '1.3' out, and work on the other features in trunk. > > I see no problem of mod_jk having an optional dependency on APR for the new > code, or having an optional > dependency on some RPC library with compatible licence. ( using an external > library would also avoid the > problem of nobody having time to implement a new ajp protocol ). > > Costin > > >> >> 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 :-) >>> >> >> I totally agree about the usefulness of this. I would love if someone would >> chime in and work on that. >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
