Costin Manolache wrote:
Remy Maucherat wrote:
My turn :)
Sorry, I won't help code it (well, maybe a little for the Java part); so I don't know if I have a say in any decision, but I though I should participate as well.
- it should be simpler than JK 1 or 2
+1
- it should have a name which doesn't confuse folks :)
mod_tomcat would be good.
- Apache 2.x specific using APR (with the goal being the inclusion in the Apache distribution as a default module: no more compilation problems, etc); for other servers, I think we should keep the current JK
That's good if it means "generic library plust apache2 specific code", but it's really bad if it means all new functionality will only work in apache2 and for all other servers ( and no-server use cases ) we'll be stuck with jk.
- it should try to optimize keepalive if possible for performance
- it should support quality of service (messages to notify that a webapp is being serviced on one node, etc)
- (nice to have) it should be possible to configure the cluster dynamically
I would upgrade this to MUST have, not only for cluster but also webapps. Tomcat5 is pretty dynamic. If this is missing - why bother ?
- there should be a clear documentation for which connector to use (I'm not talking about specific needs, but general case: one server -> standalone HTTP/1.1, cluster -> mod_newthing)
- the configuration should be in Apache's config file, rather than some complex properties file
-0 - apache config file is the best choice for 'close integration', but it can't be used in a JMX-like dynamic environment.
There are use cases where you want one, but the other is as important.
- it should have good defaults (I like good defaults :) )
Big +1.
- it should work well with other modules (I guess if somehow it is accepted into the Apache codebase, it will be required)
- I think the protocol should be an extension of AJP/1.3
+1 - or a standard, existing protocol. No new arbitrary protocols. ( XDR subset remains my favorite ).
Well AJP/1.3 exist on TC 3.3.x, 4.1.x and 5.x.
Adding some Ajp/1.3++ features is just evolution, not a complete rewrite like an XDR based coyote connector.
- No JNI in this module IMO: I think it would be better to have another separate module dedicated to JNI (and trying to use, for example, the in memory protocol handler or similar techniques) if there's interest, rather than add complexity to this module, which has very different needs
What complexity does JNI add to jk2 ? There are separate files, using the same protocol.
Many and add minima that HTTPD 2.0 didn't require JNI. Frankly I'd prefer to see JNI in a mod_java project instead...
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"
JNI stuff could goes in mod_jni/mod_java, less complexity, no users/admins questions about auto-configuring/compiling/setup...
=> Better acceptation by Apache 2.x admins for the mod_ajp module
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
