tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject Re: Tomcat 6 plans (JSP 2.1)
Date Thu, 22 Dec 2005 14:47:32 GMT
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message