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.
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.
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.
Costin
Another thing is that we might want to write the next Tomcat for JDK
1.5.
Anything specific in JDK 1.5? We already spoke a bit about NIO in some form, but that's JDK 1.4.
Annotations :) (I saw EJB 3)
I have to assume we're going to have some annotations defined in the spec, hence the requirement for JDK 1.5. Of course, this is speculation on this point.
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
