OK - persistance has paid off :)
I now have a little client that with a small HTTP header will connect
with a servlet, and run a persistent "telnet" like session with it
until either someone times out or decides to quit. The only
requirement is that you initiate the connection with HTTP
head
At 09:42 2/28/2007, you wrote:
Back to the original issue: sounds like you really need to develop your
own connector to handle your proprietary protocol, rather than trying to
twist one of Tomcat's HTTP or AJP connectors into doing your bidding.
What we do is to be determined. What I want to
> From: Peter Kennard [mailto:[EMAIL PROTECTED]
> Subject: Re: HTTP plus
>
> > Excuse the naivety but I thought you couldn't open a socket
> > with J2EE. I was told (I think on this list) that you need
> > to use a JCA to make the connection.
>
> If
Peter Kennard wrote:
Excuse the naivety but I thought you couldn't open a socket with J2EE.
I was told (I think on this list) that you need to use a JCA to make
the connection.
Tomcat is not a full J2EE server, just servlets+JSP, so maybe
it lets you do things which are verboten in J2EE?
If
Yes - I'm assuming J2ee facilities.
At 06:57 2/28/2007, you wrote:
That's certainly correct, raw socket communication
is not J2EE. Peter didn't mention, however, that
J2EE was a necessary precondition for his case.
On the contrary, this communication with some
binary messages sent over sockets
Excuse the naivety but I thought you couldn't open a socket with J2EE.
I was told (I think on this list) that you need to use a JCA to make
the connection.
If this is true I want to know about this. I am so far under the
impression if you needed to connect with another protocol in a
servlet
That's certainly correct, raw socket communication
is not J2EE. Peter didn't mention, however, that
J2EE was a necessary precondition for his case.
On the contrary, this communication with some
binary messages sent over sockets cannot be made
to fit in a J2EE environment easily, save these
option
I understand what you are saying, however that means you also have to
re-do all the "application management" system. Deployment,
connectors, management, adminstration, thread management, load
balancing, SSL key management and configuration and many many other
infrastructure pieces that can be
On Wed, 28 Feb 2007 12:36:03 +0100
Georg Sauer-Limbach <[EMAIL PROTECTED]> wrote:
> If you don't want to deal with HTTP, you should
> not use the Servlet API (which is the Java
> abstraction of HTTP) at all. You can do the
> indicated code with generic sockets, no need to
> mind about Servlets alt
If you don't want to deal with HTTP, you should
not use the Servlet API (which is the Java
abstraction of HTTP) at all. You can do the
indicated code with generic sockets, no need to
mind about Servlets altogether.
Georg
Peter Kennard wrote:
Ok - continuing.
Is it possible to use a "GenricServ
Ok - continuing.
Is it possible to use a "GenricServlet" to do basicly this.
service(req,res)
{
for(;;)
{
readSome(req.getInputStream());
if(writeSome(req.getOutputStream()) {
req.flushBuffer();
} else {
break;
}
}
}
That
I guess I'll answer my own question here after some testing and research
That is:
If you override the "service()" method on servelet all you need is a
"service name" and a "path" to the servlet followed by two newlines
as the "minimal" header.
ie:
X /Z\n\n
for the most minimal header.
"X"
Was this last message of mine just too naive :)
Should I break it into smaller parts?
Still curious :)
Peter K.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional co
I did see a reference to a "socket servlet" which touches on this.
Tomcat has doe a lot in it that is very useful (to re-itterate)
- Administration of sevlets on a "live" server with web interface
- handling of depolyment and undeplyment
- integration with IDEs and build systems (eclipse, ant, et
14 matches
Mail list logo
