jakarta-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@costin.dnt.ro>
Subject Re: ServletRequest - not HttpServletRequest
Date Mon, 24 Apr 2000 19:35:42 GMT
Lucas Gonze wrote:

> > My recomandation is to use an API that fits your protocol, and create
> > adapters if you want to use servlets to generate dynamic content for
> > your application. There are APIs for mail, IIOP, SNMP, etc - use the
> > right tool.
> The reason to use tomcat for non-http protocols is to take
> advantage of its many resources.  The support code for
> getresourceasstream, WAR files, the installer, etc. is all stuff
> I'd have to implement myself.
> As I mentioned, I have a little tcpserver that I subclass to make
> specialized servers.  This approach works well for experimental
> tools, but when it comes to adding polish I'd rather piggyback on
> other people's work.
> Also, the support code for servlets themselves is very handy.  I
> have now moved completely to tomcat from my http subclass of my
> tcp server, because the toolkit is so useful.  I'd like to not
> have to support both.

You can use tomcat implementation ( ThreadPools,
XML stuff, deployment, etc).  The TCP part is HTTP-independent
and can be used in any server, the threading, etc. The only place
where Tomcat is HTTP specific is in the implementation of the
servlet API ( i.e. tomcat.core and the interceptors - are HTTP-specific).
Even in this case - the interceptor itself is supposed to be a
bridge between Servlets/HTTP world and various non-http APIs.

The only problem is if you want to use Request/Response as an API
to model your protocol. If your protocol is not stateless it will be even

Most protocols I know already have a defined API. If it's a new
protocol - it's still better to define an API based
on your use of the protocol. If it's close enough to HTTP and
servlets - it's probably  a good idea to try to just use HTTP.

Of course, this is just IMHO. I'm curious to understand
what protocols do you want to support and how far they are
from HTTP.


View raw message