Mladen Turk wrote:
-----Original Message----- From: Remy Maucherat
The only 2 JNI models that actually work are jk2 "protocol marshalling, pass only byte[]" and eclipse swt "small simple calls with mostly int and byte[] params"
All that is cool, but what you propose looks a lot like JK 2 (JMX dynamic features, support for many webservers, etc), and we know that almost no developer understands it anymore. This clashes head on with the "it has to be simple" requirement: how do you expect the issue to be solved ?
This is the point about dropping server portability, among other things. Sorry to say it aloud, but for new developments I don't care about IIS (it should die) nor Apache 1.3, which are the two other servers that matter. To support these, we have mod_jk 1.2 (and too bad if people don't get the extra features).
I agree with you. We've tried to hard to mix a bunch of different concepts together. At some time the JNI even worked, but only on single-child servers (Apache2 on Win32 and IIS).
IMO we should focus on the 'APR/APR-UTIL' based protocol and TCP/IP transport for now, with in memory config dynamically updatable via API calls, using as little as possible specific 'ap_xxx' calls. I like the Henri's idea to have a little lib and a small app like ab, to test the protocol, and all core functionality. It would be a tremendous achievement to be able to effectively test the core module functionality without server itself. It would give a common playground for protocol testing, auto-config, etc...
The JNI is totally different, cause you can have only one VM per Apache2 instance, but you can have 100+ forked childs each trying to load it's own VM, so the inprocess TC instance has a very limited usability, and is very server specific.
IIS is also something different, and if one wish to write the good extension it has to be done in a different way. Still, some core functionality can be reused, but not making some 'common' code, but rather making common codebase, that some inexperienced (in a JK/JK2 sense) developer will be able to cope with.
I agree with Costin that the JMX is a great stuff, but not if we wish to build a simple and _reliable_ module with finite (or static like Costin said) set of functionality.
The AJP13 protocol will have to be enhanced (or better enabled) to use the
'Service channel' and 'Data Filter'. It is not necessary to define all
Service channel modes like server topology, or server readiness, neither to
define all the Data Filter modes like cryptography or compression. I was
thinking of something like 'extensions' to the protocol, meaning that one
can extend the protocol to some desired level.
Yes.
My initial idea for AJP/1.4 wass to mix on the same wire request forwaring which is the core functionnality of AJP/1.3 with system messaging.
- Service channel is a channel to send/received update between Apache and Tomcats :
- Negociation between Apache and Tomcat.
* Should we use an authentification scheme between Apache and
Tomcat (ajp1.3 make that Tomcat trust any Web server
caming via AJP13).* Should we compress the requests/replies
* Should we crypt the requests/replies.
- Web Applications state updates :
* a Web Application is added
* a Web Application is removed
- Updates in cluster configurations :
* worker1 was handling 25% of total load, now it could handle
35%.* worker2 in cluster is down for maintenance....
* Apache 2 could use worker3 for this cluster, it could reach it
at IP/PORT....
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
