Remy Maucherat wrote:
Allistair Crossley wrote:
Hi,
Personally I am less interested in a small footprint Tomcat and more
interested in tools that help manage and report on the internals of
Tomcat. Instrumentation, JMX, effective and stable debugging and
deployment, clustering and load balancing are the types of areas that
would help me out with our corporate intranet.
I doubt any of these issues are of real concern to the development team
because they are supporting of the main container, but they matter on
the front-line and often piecing together different technologies via
modules which have varying amounts of documentation and stability is
tough and time-consuming. I've been fighting getting in WebLogic,
WebSphere and Jboss but it looks like it's going that way in 2006 :(
Personally, I am also not interested at all in changes to the
container architecture either, and I plan to keep using the current
codebase to do the Servlet 2.5 support in JBoss. It mostly does what I
need, and I think changing it a lot would break more things than what
it would fix.
- Debugging: No idea, do you have some ?
- Deployment: Ok, it's an independent module (HostConfig, and the
associated manager webapp, basically); I did it twice already, I think
it's half decent, but I am sick of it, so if anyone feels like doing
it again, go ahead.
- Clustering: We have clustering already. What's wrong with it besides
bugs ? (if it had bugs, it's because of not enough users, testing, and
bugfix contributors: you can help)
- Load balancing: We have mod_jk, and now mod_proxy in Apache 2.2. Do
you need more ? I had ideas for an AJP APR client implementation, but
I am not sure there's an actual demand for that (I don't see the point
of having a Tomcat as a front end server, given it's a single purpose
task and exisitng ASF software seem to be doing it just as well).
The main item you didn't mention is instrumentation/JMX. This is an
area that should not require any substantive rearchitecture and could
greatly benefit most users. I know JBoss has more JMX stuff, but having
the Tomcat end of things quite well instrumented in Tomcat proper seems
like the right way to go.
I have to support a number of servlet engines, so I ended up doing my
own MBeans for things I can get at via the servlet APIs, i.e. so I have
portable request and session monitoring/timing/logging, etc. There are,
however, things that are not accessible via the servlet APIs or are just
a royal pain to do at that level (e.g. accurate per request I/O byte
counting/logging).
I'm also uncertain what debugging improvements should be made if any --
apart from the fact that precompilation of JSPs does not seem to
generate full SMAP information even when told to do so (yes, I filed
this on BZ, but I've not had a chance to delve further myself). That's
either user error on my part (though I'm baffled as to how this could
be) or a plain/simple bug, though.
The only bit with deployment I can think of is
easing/automating/documenting means of deploying to a cluster of Tomcats
at once. I could just be overlooking wonderful capabilities in this
regard, however, as I've not really looked all that hard here.
BTW, I am biased, but I don't see a move to JBoss as being that bad.
If you use a web oriented configuration, you end up with something
that has the same web capabilities as Tomcat, but with a few more
robust components for important functionality (TM, datasource,
clustering, etc). Unfortunately, it uses more resources ;)
There is something to be said for using just enough hammer. Unless you
need EJBs, a TM (i.e. other than JOTM), or JMS, it's not clear why you'd
add the extra layers. [I suspect someone will pipe in with info on a
nice open source, maybe even XA-aware JMS provider that can be used
without an app server as well.]
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
