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]