On 01/12/2012 21:15, Jost Boekemeier wrote: > Hi, > > I don't think tomcat is hard-wired the way you suggest.
[sigh] Suggest? Tomcat, as does the Servlet Spec, focuses on web applications, ie ones served over HTTP. The Connector implementations are configurable, but there is no UDP implementation shipped with Tomcat. Nor is there a raw Servlet, TCP implementation. > And the servlet spec doesn't require http. What a strange statement. The javax.servlet.http package, (being part of the spec), does rather seem to focus on it and the 3.0 spec mentions HTTP on a fairly large number of it's pages. > In the past I've written a > servlet container which uses raw tcp instead of http. Smashing. > The tomcat jee container is needed by php java bridge to rund php code from > Java. Is that the context of your problem, or just some random info? > Probably the tomcat dev ml is more appropriate. Ahh, the dismissal. Bueno. p > Am 01.12.2012 21:50 schrieb "Pid" <p...@pidster.com>: > >> On 01/12/2012 17:22, Mark Eggers wrote: >>> On 12/1/2012 5:16 AM, Jost Boekemeier wrote: >>>> Hello, >>>> >>>> I am developing a JEE web application which has to handle HTTP, TCP >>>> and UDP connections. >>>> >>>> Can Tomcat >= 7 handle raw TCP and UDP connections? Are there >>>> extensions (connectors?) available which can handle them? >>>> >>>> *I am aware of mina.apache.org, and I can write my own socket server, >>>> so please don't point me to these solutions. The requirement is a JEE >>>> (Tomcat) web app.* >>>> >>>> >>>> I think persistent TCP connections should easy to implement. But what >>>> about UDP? >>>> >>>> >>>> Any pointers welcome. >>>> >>>> >>>> Regards, Jost Bökemeier >>>> >>> >>> Jost, >>> >>> I wrote up a nice analysis of how you can accomplish your goals. Then I >>> read the following lines: >>> >>>> *I am aware of mina.apache.org, and I can write my own socket server, >>>> so please don't point me to these solutions. The requirement is a JEE >>>> (Tomcat) web app.* >>> >>> I glanced at the Tomcat code, and it seems to be built in complete >>> protocol stacks (HTTP, AJP, clustering). So without major Tomcat surgery >>> I don't think so. >>> >>> I was thinking of a command and control application along with a >>> stand-alone server, much like Derby has: >>> >>> http://db.apache.org/derby/docs/10.1/adminguide/cadminservlet98430.html >>> >>> However, the above constraint eliminates that approach. >>> >>> There are some really interesting hackish ways to approach this (JNDI >>> beans for clients, ServletContextListener to start servers), but that's >>> far off the beaten path. >>> >>> Maybe if you stepped back and wrote what you're trying to accomplish >>> people can suggest some approaches. >>> >>> All of that is probably quite a bit off-topic from the mailing list. >> >> Well, that saves me some work. >> >> I'll just add the following: it's really important to comprehend that >> Tomcat is a Servlet Container and by extension, to understand what a >> Servlet Container is. >> >> Reading an appropriate version of the Servlet Specification is therefore >> a good idea. >> >> >> p >> >> >> >> >> -- >> >> [key:62590808] >> >> > -- [key:62590808]
signature.asc
Description: OpenPGP digital signature
