Jess Holle wrote:
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.
Ah ok. Well, I thought you could get a lot of JMX stuff already.
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.
Of all the things that I quoted, I guess the biggest one is the
deployer. I can't help but notice the JBoss deployer looks more robust
to me, but then reinventing it doesn't look to too productive to me.
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.]
I don't see a big difference with Tomcat, which is also an appserver
(hopefully, you don't associate EJB <-> appserver, because if you do,
I'm not talking to you ever again :) ). Marketting is king, though, and
I understand the desire to look like a rebel and refuse the "big fat
appserver" in favor of a random set of "independent" components which in
the end do and are actually the exact same thing. Unless the appserver
is monolithic, but that's not the current trend (but even if it is,
sometimes they are actually small).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
