RE: non Http connector

[David Tildesley]

Of course you can use whatever you like - you just need to start your
protocol listener from a servlet that has been autostarted from Tomcat - you
then create your own threads from the servlet to handle multiple sessions. I
have done such a thing for Tibco Rendezvous messaging for a rather peculiar
requirement.

-Original Message-
From: Yves Duhem [mailto:yves.duhem@;cryptolog.com]
Sent: Friday, 15 November 2002 10:03 p.m.
To: Tomcat Users List
Subject: Re: non Http connector


Thanks for your answer,
in fact I don't want to use http at all and I was wondering if it was
possible with tomcat.
I already have my own protocol, and since the communication will be
wrapped in ssl I don't need http. The only feature from http that I
might need is multiplexing. So I was wondering if the connector
architecture of tomcat allowed (without too much trouble) to use another
protocol.
But it's true that using http is not a big problem and I'll probably end
up doing that.
yves

Milt Epstein wrote:
> On Thu, 14 Nov 2002, Yves Duhem wrote:
>
>
>>Hi,
>>I would like to use servlets and tomcat without having to communicate
>>via http.
>>my request's first line would indicate in some way the target servlet
>>and the rest would be the data to transmit to the servlet
>>the response would be only the data (no headers).
>>(and all this would be used with SSL.)
>>
>>I would like to know if a connector behaving like this exists somewhere,
>>or if i'll have to modify one of the existing connectors (and in that
>>case is there any developer documentation about the connector framework?).
>
>
> Are you saying that you really don't want to use HTTP (as a protocol),
> or just that you want to do this outside the context of a web browser?
> Because in the current HTTP framework there's nothing that's stopping
> you from using it outside of a web browser.  You can, for example, set
> up a java application that opens a URLConnection to a Tomcat server.
> You can even transfer objects this way (to a certain degree) instead
> of just parameters, because you'll have direct control of
> reading/writing the I/O streams.
>
> I'm not really sure what not using HTTP buys you, because then you're
> essentially creating your own client/server system and defining your
> own protocol, and you have to set everything up.  If you use HTTP, you
> get a lot essentially "for free" (including parameter passing,
> sessions, cookies, ssl, etc.)
>
> Milt Epstein
> Research Programmer
> Integration and Software Engineering (ISE)
> Campus Information Technologies and Educational Services (CITES)
> University of Illinois at Urbana-Champaign (UIUC)
> [EMAIL PROTECTED]
>
>
> --
> To unsubscribe, e-mail:
<mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
> For additional commands, e-mail:
<mailto:tomcat-user-help@;jakarta.apache.org>
>



--
To unsubscribe, e-mail:
<mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail:
<mailto:tomcat-user-help@;jakarta.apache.org>



--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>

RE: non Http connector

[Turner, John]

JK is known as "ajp13".  JK2 is known as, I believe, "ajp14".  The precursor
to JK was JServ, and that is known as "ajp12".

The Coyote Connector (org.apache.coyote.tomcat4.CoyoteConnector) can "speak"
JK and JK2.  The Ajp13Connector (org.apache.ajp.tomcat4.Ajp13Connector) only
"speaks" JK.

CoyoteConnector: JK, JK2, SSL, HTTP
Ajp13Connector: JK

If you look in your server.xml, you will see
org.apache.coyote.tomcat4.CoyoteConnector used as ALL default connectors in
4.1.12, regardless of protocol.

>From what I understand (someone correct me if I am wrong), the administrator
app in 4.1.12 uses something call MBeans...Ajp13Connector has problems with
this.  So, if you must use Ajp13Connector, comment out the MBeans tags in
server.xml, they look like this:

  
  

If you disable the mbeans Listeners, the administrator app will not work.
So, you basically have a choice:

CoyoteConnector: everything works, including the administration app
Ajp13Connector: JK only works, admin app doesn't

Some people are using Ajp13Connector because that's what they used in
previous versions of Tomcat, and some may feel that CoyoteConnector is still
untested.  That's cool as long as they are using mod_jk and they don't mind
not having the administration app.  If they want to use JK2 (mod_jk2) or
enable the administration app, then they need to use CoyoteConnector.

HTH

John

> -Original Message-
> From: John B. Moore [mailto:jbm@;microps.com]
> Sent: Friday, November 15, 2002 11:56 AM
> To: Tomcat Users List
> Subject: Re: non Http connector
> 
> 
> John,
> 
> Maybe you can clear this up for me..  I get the hint from several 
> different messages that the CoyoteConnector handles both JK and JK2. 
>  Looking at the server.xml it appears that, based on the comments in 
> that file
> 
> 
> port="8009" minProcessors="5" maxProcessors="75"
>enableLookups="true" redirectPort="8443"
>acceptCount="10" debug="0" connectionTimeout="2"
>useURIValidationHack="false"
>
> protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/>
> 
> 
> ...that the CoyoteConnector is ONLY for JK2 and that the 
> "commented" tag 
> below that:
> 
> 
> 
> 
> ...is for JK..  Last I tried this, uncommenting this code 
> threw errors..
> 
> This Saturday I'm making another run at getting Apache2 and Tomcat4 
> talking, and maybe clearing this up might help..
> 
> Thanks...
> 
>  John...
> 
> Turner, John wrote:
> 
> >Well, JK/JK2 are their own protocols, and the 
> CoyoteConnector class handles
> >them just fine. 
> >
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail:
<mailto:tomcat-user-help@;jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>

Re: non Http connector

[John B. Moore]

John,

   Maybe you can clear this up for me..  I get the hint from several 
different messages that the CoyoteConnector handles both JK and JK2. 
Looking at the server.xml it appears that, based on the comments in 
that file


   
  port="8009" minProcessors="5" maxProcessors="75"
  enableLookups="true" redirectPort="8443"
  acceptCount="10" debug="0" connectionTimeout="2"
  useURIValidationHack="false"
  
protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/>


...that the CoyoteConnector is ONLY for JK2 and that the "commented" tag 
below that:


   

...is for JK..  Last I tried this, uncommenting this code threw errors..

This Saturday I'm making another run at getting Apache2 and Tomcat4 
talking, and maybe clearing this up might help..

   Thanks...

John...

Turner, John wrote:

Well, JK/JK2 are their own protocols, and the CoyoteConnector class handles
them just fine. 



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

RE: non Http connector

[Turner, John]

Well, JK/JK2 are their own protocols, and the CoyoteConnector class handles
them just fine.  It even can handle SSL.  Perhaps you could take a look at
org.apache.coyote.tomcat4.CoyoteConnector and see if it will help you get a
jump start on your own code.

John


> -Original Message-
> From: Yves Duhem [mailto:yves.duhem@;cryptolog.com]
> Sent: Friday, November 15, 2002 4:03 AM
> To: Tomcat Users List
> Subject: Re: non Http connector
> 
> 
> Thanks for your answer,
> in fact I don't want to use http at all and I was wondering if it was
> possible with tomcat.
> I already have my own protocol, and since the communication will be 
> wrapped in ssl I don't need http. The only feature from http that I 
> might need is multiplexing. So I was wondering if the connector 
> architecture of tomcat allowed (without too much trouble) to 
> use another 
> protocol.
> But it's true that using http is not a big problem and I'll 
> probably end 
> up doing that.
> yves
> 
> Milt Epstein wrote:
> > On Thu, 14 Nov 2002, Yves Duhem wrote:
> > 
> > 
> >>Hi,
> >>I would like to use servlets and tomcat without having to 
> communicate
> >>via http.
> >>my request's first line would indicate in some way the 
> target servlet
> >>and the rest would be the data to transmit to the servlet
> >>the response would be only the data (no headers).
> >>(and all this would be used with SSL.)
> >>
> >>I would like to know if a connector behaving like this 
> exists somewhere,
> >>or if i'll have to modify one of the existing connectors 
> (and in that
> >>case is there any developer documentation about the 
> connector framework?).
> > 
> > 
> > Are you saying that you really don't want to use HTTP (as a 
> protocol),
> > or just that you want to do this outside the context of a 
> web browser?
> > Because in the current HTTP framework there's nothing 
> that's stopping
> > you from using it outside of a web browser.  You can, for 
> example, set
> > up a java application that opens a URLConnection to a Tomcat server.
> > You can even transfer objects this way (to a certain degree) instead
> > of just parameters, because you'll have direct control of
> > reading/writing the I/O streams.
> > 
> > I'm not really sure what not using HTTP buys you, because 
> then you're
> > essentially creating your own client/server system and defining your
> > own protocol, and you have to set everything up.  If you 
> use HTTP, you
> > get a lot essentially "for free" (including parameter passing,
> > sessions, cookies, ssl, etc.)
> > 
> > Milt Epstein
> > Research Programmer
> > Integration and Software Engineering (ISE)
> > Campus Information Technologies and Educational Services (CITES)
> > University of Illinois at Urbana-Champaign (UIUC)
> > [EMAIL PROTECTED]
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
<mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
> For additional commands, e-mail:
<mailto:tomcat-user-help@;jakarta.apache.org>
> 



--
To unsubscribe, e-mail:
<mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail:
<mailto:tomcat-user-help@;jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>

Re: non Http connector

[Yves Duhem]

Thanks for your answer,
in fact I don't want to use http at all and I was wondering if it was
possible with tomcat.
I already have my own protocol, and since the communication will be 
wrapped in ssl I don't need http. The only feature from http that I 
might need is multiplexing. So I was wondering if the connector 
architecture of tomcat allowed (without too much trouble) to use another 
protocol.
But it's true that using http is not a big problem and I'll probably end 
up doing that.
yves

Milt Epstein wrote:
On Thu, 14 Nov 2002, Yves Duhem wrote:



Hi,
I would like to use servlets and tomcat without having to communicate
via http.
my request's first line would indicate in some way the target servlet
and the rest would be the data to transmit to the servlet
the response would be only the data (no headers).
(and all this would be used with SSL.)

I would like to know if a connector behaving like this exists somewhere,
or if i'll have to modify one of the existing connectors (and in that
case is there any developer documentation about the connector framework?).



Are you saying that you really don't want to use HTTP (as a protocol),
or just that you want to do this outside the context of a web browser?
Because in the current HTTP framework there's nothing that's stopping
you from using it outside of a web browser.  You can, for example, set
up a java application that opens a URLConnection to a Tomcat server.
You can even transfer objects this way (to a certain degree) instead
of just parameters, because you'll have direct control of
reading/writing the I/O streams.

I'm not really sure what not using HTTP buys you, because then you're
essentially creating your own client/server system and defining your
own protocol, and you have to set everything up.  If you use HTTP, you
get a lot essentially "for free" (including parameter passing,
sessions, cookies, ssl, etc.)

Milt Epstein
Research Programmer
Integration and Software Engineering (ISE)
Campus Information Technologies and Educational Services (CITES)
University of Illinois at Urbana-Champaign (UIUC)
[EMAIL PROTECTED]


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





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

Re: non Http connector

[Milt Epstein]

On Thu, 14 Nov 2002, Randy Secrist wrote:

> He could also implement the Remote interface and set up RMI
> communication on a different port than what the HTTP connector runs
> on - which gives you quite a bit of the protocol set up for free.
> Any HTTP servlet which implements this interface can also act as a
> RMI server.  IMHO one of the biggest problems with HTTP is that it
> is a stateless protocol - and passing objects around, and callbacks
> are clunky at best.  For most things though, HTTP does suffice.
>
> If setting up a customized client / server model is really necessary
> - then an RMI server, or EJB container would seem to be the best
> choices available at this time.

Good points.  I agree about statelessmess -- it's perhaps the biggest
limitation of HTTP (for applications that would benefit from it, of
course), and if you really need that, that would be a good reason to
not use HTTP.


> - Original Message -
> From: "Milt Epstein" <[EMAIL PROTECTED]>
> To: "Tomcat Users List" <[EMAIL PROTECTED]>
> Sent: Thursday, November 14, 2002 11:00 AM
> Subject: Re: non Http connector
>
>
> > On Thu, 14 Nov 2002, Yves Duhem wrote:
> >
> > > Hi,
> > > I would like to use servlets and tomcat without having to communicate
> > > via http.
> > > my request's first line would indicate in some way the target servlet
> > > and the rest would be the data to transmit to the servlet
> > > the response would be only the data (no headers).
> > > (and all this would be used with SSL.)
> > >
> > > I would like to know if a connector behaving like this exists somewhere,
> > > or if i'll have to modify one of the existing connectors (and in that
> > > case is there any developer documentation about the connector
> framework?).
> >
> > Are you saying that you really don't want to use HTTP (as a protocol),
> > or just that you want to do this outside the context of a web browser?
> > Because in the current HTTP framework there's nothing that's stopping
> > you from using it outside of a web browser.  You can, for example, set
> > up a java application that opens a URLConnection to a Tomcat server.
> > You can even transfer objects this way (to a certain degree) instead
> > of just parameters, because you'll have direct control of
> > reading/writing the I/O streams.
> >
> > I'm not really sure what not using HTTP buys you, because then you're
> > essentially creating your own client/server system and defining your
> > own protocol, and you have to set everything up.  If you use HTTP, you
> > get a lot essentially "for free" (including parameter passing,
> > sessions, cookies, ssl, etc.)
> >
> > Milt Epstein
> > Research Programmer
> > Integration and Software Engineering (ISE)
> > Campus Information Technologies and Educational Services (CITES)
> > University of Illinois at Urbana-Champaign (UIUC)
> > [EMAIL PROTECTED]
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:tomcat-user-help@;jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
>

Milt Epstein
Research Programmer
Integration and Software Engineering (ISE)
Campus Information Technologies and Educational Services (CITES)
University of Illinois at Urbana-Champaign (UIUC)
[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>

Re: non Http connector

[Randy Secrist]

He could also implement the Remote interface and set up RMI communication on
a different port than what the HTTP connector runs on - which gives you
quite a bit of the protocol set up for free.  Any HTTP servlet which
implements this interface can also act as a RMI server.  IMHO one of the
biggest problems with HTTP is that it is a stateless protocol - and passing
objects around, and callbacks are clunky at best.  For most things though,
HTTP does suffice.

If setting up a customized client / server model is really necessary - then
an RMI server, or EJB container would seem to be the best choices available
at this time.

Randy

- Original Message -
From: "Milt Epstein" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Thursday, November 14, 2002 11:00 AM
Subject: Re: non Http connector


> On Thu, 14 Nov 2002, Yves Duhem wrote:
>
> > Hi,
> > I would like to use servlets and tomcat without having to communicate
> > via http.
> > my request's first line would indicate in some way the target servlet
> > and the rest would be the data to transmit to the servlet
> > the response would be only the data (no headers).
> > (and all this would be used with SSL.)
> >
> > I would like to know if a connector behaving like this exists somewhere,
> > or if i'll have to modify one of the existing connectors (and in that
> > case is there any developer documentation about the connector
framework?).
>
> Are you saying that you really don't want to use HTTP (as a protocol),
> or just that you want to do this outside the context of a web browser?
> Because in the current HTTP framework there's nothing that's stopping
> you from using it outside of a web browser.  You can, for example, set
> up a java application that opens a URLConnection to a Tomcat server.
> You can even transfer objects this way (to a certain degree) instead
> of just parameters, because you'll have direct control of
> reading/writing the I/O streams.
>
> I'm not really sure what not using HTTP buys you, because then you're
> essentially creating your own client/server system and defining your
> own protocol, and you have to set everything up.  If you use HTTP, you
> get a lot essentially "for free" (including parameter passing,
> sessions, cookies, ssl, etc.)
>
> Milt Epstein
> Research Programmer
> Integration and Software Engineering (ISE)
> Campus Information Technologies and Educational Services (CITES)
> University of Illinois at Urbana-Champaign (UIUC)
> [EMAIL PROTECTED]
>
>
> --
> To unsubscribe, e-mail:
<mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
> For additional commands, e-mail:
<mailto:tomcat-user-help@;jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>

Re: non Http connector

[Milt Epstein]

On Thu, 14 Nov 2002, Yves Duhem wrote:

> Hi,
> I would like to use servlets and tomcat without having to communicate
> via http.
> my request's first line would indicate in some way the target servlet
> and the rest would be the data to transmit to the servlet
> the response would be only the data (no headers).
> (and all this would be used with SSL.)
>
> I would like to know if a connector behaving like this exists somewhere,
> or if i'll have to modify one of the existing connectors (and in that
> case is there any developer documentation about the connector framework?).

Are you saying that you really don't want to use HTTP (as a protocol),
or just that you want to do this outside the context of a web browser?
Because in the current HTTP framework there's nothing that's stopping
you from using it outside of a web browser.  You can, for example, set
up a java application that opens a URLConnection to a Tomcat server.
You can even transfer objects this way (to a certain degree) instead
of just parameters, because you'll have direct control of
reading/writing the I/O streams.

I'm not really sure what not using HTTP buys you, because then you're
essentially creating your own client/server system and defining your
own protocol, and you have to set everything up.  If you use HTTP, you
get a lot essentially "for free" (including parameter passing,
sessions, cookies, ssl, etc.)

Milt Epstein
Research Programmer
Integration and Software Engineering (ISE)
Campus Information Technologies and Educational Services (CITES)
University of Illinois at Urbana-Champaign (UIUC)
[EMAIL PROTECTED]


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