Costin Manolache wrote:
Remy Maucherat wrote:
Shapira, Yoav wrote:
One area to keep in mind there is performance. There's no argument on the utility of JMX at all. I also think most of the performance hit would be at initialization (and shutdown), as you're creating/naming/binding JMX operations/attributes. This is better than having a performance hit in the request processing pipeline, so we're OK, but it's nonetheless something to keep in mind as we're adding JMX instrumentation all over the place.
AFAIK, the performance hit would be minimal (JBoss runs ok to me, so JMX seems fast enough overall). It's an issue of cleaning the code, so it's not useful by itself. I think Costin wanted to do that migration to full JMX (we're a bit too much middle ground, and all those listener interfaces are definitely not trendy these days ;) ).
For the critical path probably it's good to keep using an interface, but for all "container changes" and other notification - there is no performance issue.
Yes, but we can't be too bad either: if we take one minute to deploy a webapp (unless we're precompiling on deploy ;) ) then it would be bad.
I don't know if anyone has read the Eclipse design and code - it has some very interesting ideas with the "extension points" and osgi.
Nope, I haven't read that.
If you are going to touch the architecture - one thing I allways hated was using the same path ( "extension point" ) for all request processing. That was one of my fundamental problems with the valves. Keep the valves if you like them - but have separate chains for authentication, authorization, logging, etc. It not only cleans the code, but it also opens stuff for reuse.
I still like the genericity actually, and since the pattern is still:
1) going in
2) invoke next (if you want to; if you don't processing stops)
2) going out
JBoss does the same with its interceptors, and the API they used is the same as the pre-TC 4 (ie, you get a pointer to the next interceptor).
I don't quite see how "typed" valves would fit into this: instead the chains are associated with the containers.
I plan to start working on this refactoring in a "catalina2" folder in jakarta-tomcat-catalina (with an associated build script in jakarta-tomcat-5), and I'll mark it as a proposal. I don't know what's the chance of this making it in a full fledged release before the next Servlet spec (athough it hasn't been started yet, so who knows when it'll happen ...), so if there are benefits a new intemediate branch will be needed. I assume we're not going to get rid of the current servlet container impl, here.
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
