You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Bob DeRemer <bo...@thingworx.com> on 2011/06/29 19:10:57 UTC
HOW TO: create custom Tomcat 6 connector to do port sharing
Hi Tomcat gurus:
I've scoured the net for information on how to do port sharing within the context of a Tomcat Servlet-based web application process. While there's some discussion, there still doesn't appear to be any solutions [YET] - that I could find yet.
What I need to do is the following:
* receive both HTTP and XMPP traffic on a single port [either 80 or 443 - depending on security configuration]
* route the HTTP traffic to Tomcat's HTTP Connector [or sub-processing component] if possible
* route the XMPP to an embedded Vysper server
* ALL running in the context of a single Tomcat Server process
This will enable us to leverage the power/investment in our servlet infrastructure and Vysper XMPP all together without having to open multiple ports.
If this is possible in either Tomcat 6 or Tomcat 7, please let me know how I should go about this:
* doing some custom extension in Tomcat (i.e. custom Tomcat connector that uses Netty for example)
* or, some other approach ???
please advise on how you would recommend achieving our goal.
Thanks in advance,
Bob
Bob DeRemer
Senior Director, Architecture and Development
http://www.thingworx.com<http://www.thingworx.com/>
Skype: bob.deremer
O: 717.505.7923
M: 717.881.3986
RE: HOW TO: create custom Tomcat 6 connector to do port sharing
Posted by Bob DeRemer <bo...@thingworx.com>.
When installing into certain corporate environments, opening multiple ports can be a problem with IT. By leveraging 80/443 for both protocols, we can eliminate this inevitable deployment problem.
-----Original Message-----
From: Pid [mailto:pid@pidster.com]
Sent: Wednesday, June 29, 2011 3:02 PM
To: Tomcat Users List
Subject: Re: HOW TO: create custom Tomcat 6 connector to do port sharing
On 29/06/2011 19:51, Christopher Schultz wrote:
> Honestly, I'd look for a non-Tomcat-centric solution because it's
> probably already been built elsewhere.
>
> -chris
Why is opening another port a problem?
p
RE: HOW TO: create custom Tomcat 6 connector to do port sharing
Posted by Bob DeRemer <bo...@thingworx.com>.
Very well stated and completely understood. My gut is already telling me that trying to customize/extend Tomcat in this way is way outside the scope of how Tomcat was designed or intended to be used. And, I would bet you're right with regard to parts of the Tomcat architecture having certain "HTTP expectations".
Thanks again for your risk assessment - this will help in making our decision on how to move forward.
-bob
-----Original Message-----
From: André Warnier [mailto:aw@ice-sa.com]
Sent: Thursday, June 30, 2011 6:27 AM
To: Tomcat Users List
Subject: Re: HOW TO: create custom Tomcat 6 connector to do port sharing
Hi.
To round up what I am trying to say :
Tomcat is a java servlet engine. In the principle, there is nothing that says that it cannot handle protocols other than HTTP/HTTPS, and run servlets which handle other kinds of messages than HTTP/HTTPS messages.
However, my general impression is that
1) this is not being done very often
2) therefore, even apart from the Connectors, there may be quite a few aspects in Tomcat which are HTTP(S)-centric, and which have not really been investigated a lot with
non-HTTP(S) messages.
For example, there was a discussion recently on this list, concerning "HTTP 100 Continue"
status codes, and if I remember correctly this implied that a Listener should be configured at the level of the Connector, and it also implied that this would trigger the immediate parsing of request headers as soon as a request came in.
Now I can quite easily imagine that this could be much more complicated if some requests which come in, are non-HTTP(S).
In summary, I have the feeling that creating a "discriminating Connector" which would dispatch HTTP(S)/XMPP requests as appropriate, could just be the tip of the iceberg, and that you could find yourself sucked into making many more changes than what you imagine at first.
Now take this with a grain of salt, since I am neither a java nor a Tomcat expert. I just happen to remember the classic line which says that "90% of a software project is done in 90% of the time; the remaining 10% also."
Bob DeRemer wrote:
> Hi Andre,
>
> Yes, XMPP typically uses port 5222, but is capable of using 80/443 as well. If we're able to share a port, it solves various IT administration issues when deployed in corporate environments. In addition, it will enable us to have a single server process and ultimately a simpler overall architecture because we won't have to configure/manage 2 separate server applications.
>
> I'm still not sure this is feasible or the best way to go, but it's worth the investigation. Given a lot of work I've done on the Microsoft side of things, their WCF infrastructure provides a TCP port sharing service, which is somewhat similar in nature to what we're looking to do. At the end of the day - both HTTP and XMPP are TCP-based. So, if I can front a single port for the incoming TCP request and then route it to the appropriate protocol-specific endpoint, there would be some significant benefits to us architecturally because we are not forced to break the functionality into 2 separate applications - unless we wanted to.
>
> That said, if I can find a solution, we'll have to validate the performance and stability - no doubt.
>
> Thanks,
> Bob
>
> -----Original Message-----
> From: André Warnier [mailto:aw@ice-sa.com]
> Sent: Wednesday, June 29, 2011 3:30 PM
> To: Tomcat Users List
> Subject: Re: HOW TO: create custom Tomcat 6 connector to do port
> sharing
>
> Pid wrote:
>> On 29/06/2011 19:51, Christopher Schultz wrote:
>>> Honestly, I'd look for a non-Tomcat-centric solution because it's
>>> probably already been built elsewhere.
>>>
>>> -chris
>> Why is opening another port a problem?
>>
>
> +1
>
> I do not know XMPP, but from the original OP description it sounds
> like a protocol which uses its own transport protocol, and normally
> some other standard port than 80/443. (*)
>
> Without even going into what kind of issues you may encounter at the Tomcat level when trying to process requests/responses which are not HTTP/HTTPS, I would also think that if you mix 2 different protocols on the same port, you will be forcing whatever equipment/software which separates and dispatches them, to look *inside* each TCP packet to determine which protocol this one is about. That in itself will introduce quite a bit of overhead.
>
> Then again, if the connection is (sometimes) over SSL, that would also probably mean that the packets have to be decrypted, even before their HTTP/XMPP nature can be discriminated.
>
> Looking at XMPP in Wikipedia, it looks like there is something called "XMPP over HTTP transport". Is that what the OP has in mind ?
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HOW TO: create custom Tomcat 6 connector to do port sharing
Posted by André Warnier <aw...@ice-sa.com>.
Hi.
To round up what I am trying to say :
Tomcat is a java servlet engine. In the principle, there is nothing that says that it
cannot handle protocols other than HTTP/HTTPS, and run servlets which handle other kinds
of messages than HTTP/HTTPS messages.
However, my general impression is that
1) this is not being done very often
2) therefore, even apart from the Connectors, there may be quite a few aspects in Tomcat
which are HTTP(S)-centric, and which have not really been investigated a lot with
non-HTTP(S) messages.
For example, there was a discussion recently on this list, concerning "HTTP 100 Continue"
status codes, and if I remember correctly this implied that a Listener should be
configured at the level of the Connector, and it also implied that this would trigger the
immediate parsing of request headers as soon as a request came in.
Now I can quite easily imagine that this could be much more complicated if some requests
which come in, are non-HTTP(S).
In summary, I have the feeling that creating a "discriminating Connector" which would
dispatch HTTP(S)/XMPP requests as appropriate, could just be the tip of the iceberg, and
that you could find yourself sucked into making many more changes than what you imagine at
first.
Now take this with a grain of salt, since I am neither a java nor a Tomcat expert. I just
happen to remember the classic line which says that "90% of a software project is done in
90% of the time; the remaining 10% also."
Bob DeRemer wrote:
> Hi Andre,
>
> Yes, XMPP typically uses port 5222, but is capable of using 80/443 as well. If we're able to share a port, it solves various IT administration issues when deployed in corporate environments. In addition, it will enable us to have a single server process and ultimately a simpler overall architecture because we won't have to configure/manage 2 separate server applications.
>
> I'm still not sure this is feasible or the best way to go, but it's worth the investigation. Given a lot of work I've done on the Microsoft side of things, their WCF infrastructure provides a TCP port sharing service, which is somewhat similar in nature to what we're looking to do. At the end of the day - both HTTP and XMPP are TCP-based. So, if I can front a single port for the incoming TCP request and then route it to the appropriate protocol-specific endpoint, there would be some significant benefits to us architecturally because we are not forced to break the functionality into 2 separate applications - unless we wanted to.
>
> That said, if I can find a solution, we'll have to validate the performance and stability - no doubt.
>
> Thanks,
> Bob
>
> -----Original Message-----
> From: André Warnier [mailto:aw@ice-sa.com]
> Sent: Wednesday, June 29, 2011 3:30 PM
> To: Tomcat Users List
> Subject: Re: HOW TO: create custom Tomcat 6 connector to do port sharing
>
> Pid wrote:
>> On 29/06/2011 19:51, Christopher Schultz wrote:
>>> Honestly, I'd look for a non-Tomcat-centric solution because it's
>>> probably already been built elsewhere.
>>>
>>> -chris
>> Why is opening another port a problem?
>>
>
> +1
>
> I do not know XMPP, but from the original OP description it sounds like a protocol which uses its own transport protocol, and normally some other standard port than 80/443. (*)
>
> Without even going into what kind of issues you may encounter at the Tomcat level when trying to process requests/responses which are not HTTP/HTTPS, I would also think that if you mix 2 different protocols on the same port, you will be forcing whatever equipment/software which separates and dispatches them, to look *inside* each TCP packet to determine which protocol this one is about. That in itself will introduce quite a bit of overhead.
>
> Then again, if the connection is (sometimes) over SSL, that would also probably mean that the packets have to be decrypted, even before their HTTP/XMPP nature can be discriminated.
>
> Looking at XMPP in Wikipedia, it looks like there is something called "XMPP over HTTP transport". Is that what the OP has in mind ?
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: HOW TO: create custom Tomcat 6 connector to do port sharing
Posted by Bob DeRemer <bo...@thingworx.com>.
Hi Andre,
Yes, XMPP typically uses port 5222, but is capable of using 80/443 as well. If we're able to share a port, it solves various IT administration issues when deployed in corporate environments. In addition, it will enable us to have a single server process and ultimately a simpler overall architecture because we won't have to configure/manage 2 separate server applications.
I'm still not sure this is feasible or the best way to go, but it's worth the investigation. Given a lot of work I've done on the Microsoft side of things, their WCF infrastructure provides a TCP port sharing service, which is somewhat similar in nature to what we're looking to do. At the end of the day - both HTTP and XMPP are TCP-based. So, if I can front a single port for the incoming TCP request and then route it to the appropriate protocol-specific endpoint, there would be some significant benefits to us architecturally because we are not forced to break the functionality into 2 separate applications - unless we wanted to.
That said, if I can find a solution, we'll have to validate the performance and stability - no doubt.
Thanks,
Bob
-----Original Message-----
From: André Warnier [mailto:aw@ice-sa.com]
Sent: Wednesday, June 29, 2011 3:30 PM
To: Tomcat Users List
Subject: Re: HOW TO: create custom Tomcat 6 connector to do port sharing
Pid wrote:
> On 29/06/2011 19:51, Christopher Schultz wrote:
>> Honestly, I'd look for a non-Tomcat-centric solution because it's
>> probably already been built elsewhere.
>>
>> -chris
>
> Why is opening another port a problem?
>
+1
I do not know XMPP, but from the original OP description it sounds like a protocol which uses its own transport protocol, and normally some other standard port than 80/443. (*)
Without even going into what kind of issues you may encounter at the Tomcat level when trying to process requests/responses which are not HTTP/HTTPS, I would also think that if you mix 2 different protocols on the same port, you will be forcing whatever equipment/software which separates and dispatches them, to look *inside* each TCP packet to determine which protocol this one is about. That in itself will introduce quite a bit of overhead.
Then again, if the connection is (sometimes) over SSL, that would also probably mean that the packets have to be decrypted, even before their HTTP/XMPP nature can be discriminated.
Looking at XMPP in Wikipedia, it looks like there is something called "XMPP over HTTP transport". Is that what the OP has in mind ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HOW TO: create custom Tomcat 6 connector to do port sharing
Posted by André Warnier <aw...@ice-sa.com>.
Pid wrote:
> On 29/06/2011 19:51, Christopher Schultz wrote:
>> Honestly, I'd look for a non-Tomcat-centric solution because it's
>> probably already been built elsewhere.
>>
>> -chris
>
> Why is opening another port a problem?
>
+1
I do not know XMPP, but from the original OP description it sounds like a protocol which
uses its own transport protocol, and normally some other standard port than 80/443. (*)
Without even going into what kind of issues you may encounter at the Tomcat level when
trying to process requests/responses which are not HTTP/HTTPS,
I would also think that if you mix 2 different protocols on the same port, you will be
forcing whatever equipment/software which separates and dispatches them, to look *inside*
each TCP packet to determine which protocol this one is about. That in itself will
introduce quite a bit of overhead.
Then again, if the connection is (sometimes) over SSL, that would also probably mean that
the packets have to be decrypted, even before their HTTP/XMPP nature can be discriminated.
Looking at XMPP in Wikipedia, it looks like there is something called "XMPP over HTTP
transport". Is that what the OP has in mind ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HOW TO: create custom Tomcat 6 connector to do port sharing
Posted by Pid <pi...@pidster.com>.
On 29/06/2011 19:51, Christopher Schultz wrote:
> Honestly, I'd look for a non-Tomcat-centric solution because it's
> probably already been built elsewhere.
>
> -chris
Why is opening another port a problem?
p
RE: HOW TO: create custom Tomcat 6 connector to do port sharing
Posted by Bob DeRemer <bo...@thingworx.com>.
I'm not sure on the XMPP over HTTP, since we require the real-time always-on connectivity provided by XMPP. I'll have to see exactly what XMPP over HTTP does under the hood. We can't afford to have our XMPP connections doing long-polling or anything.
-bob
-----Original Message-----
From: Pid [mailto:pid@pidster.com]
Sent: Thursday, June 30, 2011 3:45 AM
To: Tomcat Users List
Subject: Re: HOW TO: create custom Tomcat 6 connector to do port sharing
On 30/06/2011 02:10, Bob DeRemer wrote:
> Chris,
>
> Thanks for the feedback. I haven't come across squid yet, so I will take a look. With regard to HTTP proxying, no, I don't want to do HTTP proxying. I would like to insert a TCP-based NIO request router in place of Tomcat's Connector. Specifically, I would like to do something similar to the Netty Port Unification sample, but with HTTP AND XMPP protocols. Netty has the ability to inspect the incoming request and then get outta the way - adding the appropriate Channel for processing the request.
>
> The problem I'm facing is that we're using Tomcat as our App Server and we can't easily replace that with a non-servlet based solution at this point. As a result, I was trying to determine if there is a way to create some type of Tomcat extension that where I could do the initial request routing and pass HTTP request on to the Tomcat's plumbing without running the built-in HTTP connector(s).
You'd have to write your own connector implementation, or hack an existing one - in Tomcat 7.0 there's some work being done to consolidate the connector code, so you'd be wise to start there.
Is XMPP over HTTP a possibility, and if so could the applicable code run inside a Servlet?
Sounds like a 'square peg, round hole' type situation...
p
> Thanks,
> Bob
>
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Wednesday, June 29, 2011 2:51 PM
> To: Tomcat Users List
> Subject: Re: HOW TO: create custom Tomcat 6 connector to do port
> sharing
>
> Bob,
>
> On 6/29/2011 1:10 PM, Bob DeRemer wrote:
>> I've scoured the net for information on how to do port sharing within
>> the context of a Tomcat Servlet-based web application process.
>> While there's some discussion, there still doesn't appear to be any
>> solutions [YET] - that I could find yet.
>
>> What I need to do is the following:
>
>> * receive both HTTP and XMPP traffic on a single port [either 80 or
>> 443 - depending on security configuration]
>
>> * route the HTTP traffic to Tomcat's HTTP Connector [or
>> sub-processing component] if possible
>
>> * route the XMPP to an embedded Vysper server
>
> All of the above should be doable using something like Squid. Does Squid do pretty much everything?
>
>> * ALL running in the context of a single Tomcat Server process
>
> Oh.
>
> You want Tomcat to do HTTP proxying? AFAIK, nobody has done that. Most people who want HTTP proxying just use some other web server out in front of Tomcat (like Apache httpd, Squid, Nginx, lighttpd, HTTP lb, etc.). I have to imagine that at least one of those products can do content-detection to determine where to route messages.
>
> Does it /have to/ be Tomcat-based?
>
>> This will enable us to leverage the power/investment in our servlet
>> infrastructure and Vysper XMPP all together without having to open
>> multiple ports.
>
>> If this is possible in either Tomcat 6 or Tomcat 7, please let me
>> know how I should go about this:
>
>> * doing some custom extension in Tomcat (i.e. custom Tomcat
>> connector that uses Netty for example)
>
>> * or, some other approach ???
>
> If you want to brute-force it, you could write a servlet Filter (or, better yet, a Tomcat-specific Valve that runs before the request is mapped to a webapp) to intercept the messages and proxy them over to your other service(s). You'll have to do the HTTP proxying yourself, though.
>
>> please advise on how you would recommend achieving our goal.
>
> Honestly, I'd look for a non-Tomcat-centric solution because it's probably already been built elsewhere.
>
> -chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HOW TO: create custom Tomcat 6 connector to do port sharing
Posted by Pid <pi...@pidster.com>.
On 30/06/2011 02:10, Bob DeRemer wrote:
> Chris,
>
> Thanks for the feedback. I haven't come across squid yet, so I will take a look. With regard to HTTP proxying, no, I don't want to do HTTP proxying. I would like to insert a TCP-based NIO request router in place of Tomcat's Connector. Specifically, I would like to do something similar to the Netty Port Unification sample, but with HTTP AND XMPP protocols. Netty has the ability to inspect the incoming request and then get outta the way - adding the appropriate Channel for processing the request.
>
> The problem I'm facing is that we're using Tomcat as our App Server and we can't easily replace that with a non-servlet based solution at this point. As a result, I was trying to determine if there is a way to create some type of Tomcat extension that where I could do the initial request routing and pass HTTP request on to the Tomcat's plumbing without running the built-in HTTP connector(s).
You'd have to write your own connector implementation, or hack an
existing one - in Tomcat 7.0 there's some work being done to consolidate
the connector code, so you'd be wise to start there.
Is XMPP over HTTP a possibility, and if so could the applicable code run
inside a Servlet?
Sounds like a 'square peg, round hole' type situation...
p
> Thanks,
> Bob
>
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Wednesday, June 29, 2011 2:51 PM
> To: Tomcat Users List
> Subject: Re: HOW TO: create custom Tomcat 6 connector to do port sharing
>
> Bob,
>
> On 6/29/2011 1:10 PM, Bob DeRemer wrote:
>> I've scoured the net for information on how to do port sharing within
>> the context of a Tomcat Servlet-based web application process.
>> While there's some discussion, there still doesn't appear to be any
>> solutions [YET] - that I could find yet.
>
>> What I need to do is the following:
>
>> * receive both HTTP and XMPP traffic on a single port [either 80 or
>> 443 - depending on security configuration]
>
>> * route the HTTP traffic to Tomcat's HTTP Connector [or
>> sub-processing component] if possible
>
>> * route the XMPP to an embedded Vysper server
>
> All of the above should be doable using something like Squid. Does Squid do pretty much everything?
>
>> * ALL running in the context of a single Tomcat Server process
>
> Oh.
>
> You want Tomcat to do HTTP proxying? AFAIK, nobody has done that. Most people who want HTTP proxying just use some other web server out in front of Tomcat (like Apache httpd, Squid, Nginx, lighttpd, HTTP lb, etc.). I have to imagine that at least one of those products can do content-detection to determine where to route messages.
>
> Does it /have to/ be Tomcat-based?
>
>> This will enable us to leverage the power/investment in our servlet
>> infrastructure and Vysper XMPP all together without having to open
>> multiple ports.
>
>> If this is possible in either Tomcat 6 or Tomcat 7, please let me know
>> how I should go about this:
>
>> * doing some custom extension in Tomcat (i.e. custom Tomcat
>> connector that uses Netty for example)
>
>> * or, some other approach ???
>
> If you want to brute-force it, you could write a servlet Filter (or, better yet, a Tomcat-specific Valve that runs before the request is mapped to a webapp) to intercept the messages and proxy them over to your other service(s). You'll have to do the HTTP proxying yourself, though.
>
>> please advise on how you would recommend achieving our goal.
>
> Honestly, I'd look for a non-Tomcat-centric solution because it's probably already been built elsewhere.
>
> -chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: HOW TO: create custom Tomcat 6 connector to do port sharing
Posted by Bob DeRemer <bo...@thingworx.com>.
Chris,
Thanks for the feedback. I haven't come across squid yet, so I will take a look. With regard to HTTP proxying, no, I don't want to do HTTP proxying. I would like to insert a TCP-based NIO request router in place of Tomcat's Connector. Specifically, I would like to do something similar to the Netty Port Unification sample, but with HTTP AND XMPP protocols. Netty has the ability to inspect the incoming request and then get outta the way - adding the appropriate Channel for processing the request.
The problem I'm facing is that we're using Tomcat as our App Server and we can't easily replace that with a non-servlet based solution at this point. As a result, I was trying to determine if there is a way to create some type of Tomcat extension that where I could do the initial request routing and pass HTTP request on to the Tomcat's plumbing without running the built-in HTTP connector(s).
Thanks,
Bob
-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Wednesday, June 29, 2011 2:51 PM
To: Tomcat Users List
Subject: Re: HOW TO: create custom Tomcat 6 connector to do port sharing
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bob,
On 6/29/2011 1:10 PM, Bob DeRemer wrote:
> I've scoured the net for information on how to do port sharing within
> the context of a Tomcat Servlet-based web application process.
> While there's some discussion, there still doesn't appear to be any
> solutions [YET] - that I could find yet.
>
> What I need to do is the following:
>
> * receive both HTTP and XMPP traffic on a single port [either 80 or
> 443 - depending on security configuration]
>
> * route the HTTP traffic to Tomcat's HTTP Connector [or
> sub-processing component] if possible
>
> * route the XMPP to an embedded Vysper server
All of the above should be doable using something like Squid. Does Squid do pretty much everything?
> * ALL running in the context of a single Tomcat Server process
Oh.
You want Tomcat to do HTTP proxying? AFAIK, nobody has done that. Most people who want HTTP proxying just use some other web server out in front of Tomcat (like Apache httpd, Squid, Nginx, lighttpd, HTTP lb, etc.). I have to imagine that at least one of those products can do content-detection to determine where to route messages.
Does it /have to/ be Tomcat-based?
> This will enable us to leverage the power/investment in our servlet
> infrastructure and Vysper XMPP all together without having to open
> multiple ports.
>
> If this is possible in either Tomcat 6 or Tomcat 7, please let me know
> how I should go about this:
>
> * doing some custom extension in Tomcat (i.e. custom Tomcat
> connector that uses Netty for example)
>
> * or, some other approach ???
If you want to brute-force it, you could write a servlet Filter (or, better yet, a Tomcat-specific Valve that runs before the request is mapped to a webapp) to intercept the messages and proxy them over to your other service(s). You'll have to do the HTTP proxying yourself, though.
> please advise on how you would recommend achieving our goal.
Honestly, I'd look for a non-Tomcat-centric solution because it's probably already been built elsewhere.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4LdBwACgkQ9CaO5/Lv0PDnegCfcTgMDFoAXELLl/dG2O+nDf1r
iSoAn08cn0AfOMfREMMYoS4IkcXJtHx7
=BUTa
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HOW TO: create custom Tomcat 6 connector to do port sharing
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bob,
On 6/29/2011 1:10 PM, Bob DeRemer wrote:
> I've scoured the net for information on how to do port sharing
> within the context of a Tomcat Servlet-based web application process.
> While there's some discussion, there still doesn't appear to be any
> solutions [YET] - that I could find yet.
>
> What I need to do is the following:
>
> * receive both HTTP and XMPP traffic on a single port [either 80 or
> 443 - depending on security configuration]
>
> * route the HTTP traffic to Tomcat's HTTP Connector [or
> sub-processing component] if possible
>
> * route the XMPP to an embedded Vysper server
All of the above should be doable using something like Squid. Does Squid
do pretty much everything?
> * ALL running in the context of a single Tomcat Server process
Oh.
You want Tomcat to do HTTP proxying? AFAIK, nobody has done that. Most
people who want HTTP proxying just use some other web server out in
front of Tomcat (like Apache httpd, Squid, Nginx, lighttpd, HTTP lb,
etc.). I have to imagine that at least one of those products can do
content-detection to determine where to route messages.
Does it /have to/ be Tomcat-based?
> This will enable us to leverage the power/investment in our servlet
> infrastructure and Vysper XMPP all together without having to open
> multiple ports.
>
> If this is possible in either Tomcat 6 or Tomcat 7, please let me
> know how I should go about this:
>
> * doing some custom extension in Tomcat (i.e. custom Tomcat
> connector that uses Netty for example)
>
> * or, some other approach ???
If you want to brute-force it, you could write a servlet Filter (or,
better yet, a Tomcat-specific Valve that runs before the request is
mapped to a webapp) to intercept the messages and proxy them over to
your other service(s). You'll have to do the HTTP proxying yourself, though.
> please advise on how you would recommend achieving our goal.
Honestly, I'd look for a non-Tomcat-centric solution because it's
probably already been built elsewhere.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4LdBwACgkQ9CaO5/Lv0PDnegCfcTgMDFoAXELLl/dG2O+nDf1r
iSoAn08cn0AfOMfREMMYoS4IkcXJtHx7
=BUTa
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org