tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: Tomcat 6 plans (JSP 2.1)
Date Thu, 22 Dec 2005 15:21:41 GMT
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).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message