Costin Manolache wrote:
For C++ servers - yes.
For Java servers - is anyone else using it besides tomcat ? Even in
tomcat - how many
people are using the bindings ( compared with the non-apr connector ) ?
Unfortunately - NIO is the well-accepted solution for java servers (
all except tomcat
are using it ). We know APR is better - but can't pretend it's an
'accepted' solution.
The truth is, few people are using Java web servers, and it's not going
to change. I'm curious to know how NIO is a well accepted solution for
web servers, BTW.
Not a new abstraction layer - just adjustments to the current one.
For example - add the 'long' socket to TcpConnection - and adjust comments in
TcpConnectionHandler - so it can be used instead of the Handler. Then most Apr
classes could extend the corresponding non-APR classes, and only
override what's
different.
It's not the perfect abstraction - but if you also add NIO, you could
later extract
a base class that has none of the apr/nio/classic methods, and avoid
duplication.
Adding NIO in the same way as APR was added would be a nightmare - the current
APR code is already messy ( Sendfile for example ).
I'm sorry, I like APR, but I can't like the current implementation (
except as a good
initial step ).
Again, I completely disagree. The low level code is small enough that an
abstraction layer is useless. Similarly, a lot of the code in j-t-c/util
should go (starting with the "threads" package).
To get down to the root of the problem, I don't like the argument that
NIO is any good as an IO API. Besides the (many) utility classes like
the buffers, and as a JNI access method, both of which can be used
without sencond thoughts (and are actually used right now), all the
actual IO code is still all native (no surprise) and the Java API on top
is over engineered. It doesn't make sense to me.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
