Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
What complexity does JNI add to jk2 ? There are separate files, using the same protocol.
The real important lesson in Jk2 is that JNI works faster and better if it is not used to pass objects.
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 ?
JMX seems to simplify tomcat5 pretty well, and I think it would be a big lost if we would say 'let's simplify tomcat5 and remove jmx'.
If you don't have the ability to deal with the changes in the cluster and the added/removed webapps - why bother, just use mod_proxy and you're done. Why write a special connector if it wouldn't take advantage of almost any tomcat benefit ?
Regarding multiple servers - if JMX, then the code will probably have some modularity that would allow this anyway.
One thing is clear - if you start with the idea "let's not have JMX, may be will add it later", it'll be impossible to do it. That's what we tried in jk2, and it's not very nice. If you start with a dynamic design - and take into account the implications on config, code structure, etc - then it may be a bit more complex that the "simplest connector", however you'll have a good base for future changes.
Well JK2 inherited too many things from the past and add too many features to be used today.
I'd rather prefer a pragmatic approach :
- step 1: rewrite mod_ajp module with simplicity and Apache 2.x admin habbits in mind, with simple real worker. Decent documentation about this first version.
- step 2: add load-balancing support in using ajp/network and also good documentation about it.
- step 3: add JMX-like features by handling special URL (ajp-handler or via AJP/1.3 and provide a good JMX support console for it.
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).
One of the things I'm very interested in is getting tomcat "connected" with other, non-web server applications. I realize this is crazy and most people don't need such a thing - but we all have crazy ideas, and it happens that having a generic support that works for IIS or iPlanet will also allow other kinds of connectors.
Don't use mod_ajp for this, but use the ajp library with custom code.
If JMX is used, then it'll require modularity which will then allow other connectors based on the same components.
JMX is great but a good console will be required...
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
