Another thought is that servlets maintain contextual information and resources .. that's nice, saves a lot of time. As soon as you need a database resource or an extension of your pruned-back HTTP implementation on the server socket, you'll be rebuilding what Tomcat has already done?
On 5/6/19, Paul Carter-Brown <paul.carter-br...@jini.guru> wrote: > lol on the Semaphore Telegraph, > > I can't use a request dispatcher as the request is being initiated from > code that has no context. I already have it working with HTTP using > asynchttp library, but I want to avoid the overhead. E.g. lets say I wrote > my own server socket listener on port 10000 running in the Tomcat JVM and > got some request in some propriatary protocol called X. Now I want to call > a Tomcat servlet in the current JVM with some info I got over X without > going out on TCP and back in.... > > On Mon, May 6, 2019 at 4:40 PM John Dale <jcdw...@gmail.com> wrote: > >> If you're wanting to forward control to another servlet deployed in >> the same context: >> https://www.javatpoint.com/requestdispatcher-in-servlet >> >> If you are okay going through TCP to facilitate some future or current >> distribution of services, Use HTTPURLConnection (not sure what you're >> wanting to do with the result of the request, if anything): >> >> https://stackoverflow.com/questions/2793150/how-to-use-java-net-urlconnection-to-fire-and-handle-http-requests >> >> If you need more sophisticated HTTP interactions, Apache maintains a >> very useful library for that: http://hc.apache.org/ >> >> If these don't work-out for you, rather than using .NET, PHP, Python, >> or some other Java facsimile at best, I recommend using the semaphore >> telegraph: >> https://en.wikipedia.org/wiki/Semaphore_telegraph >> >> Sincerely, >> >> John >> DB2DOM >> >> On 5/6/19, Paul Carter-Brown <paul.carter-br...@jini.guru> wrote: >> > Hi John, >> > >> > Thanks for your feedback. >> > >> > The request I'm initiating should not or need not carry any context >> > from >> > the originating code. There is also no session to worry about as its >> > just >> > for rest calls. So basically I have the headers, path and body and need >> to >> > generate a http servlet request and get an http servlet response (or >> > similar) back. I have this working by calling into localhost but >> > ideally >> > want to skip the trombone out and back in. >> > >> > Have you got any basic code examples? >> > >> > Paul >> > >> > On Tue, Apr 30, 2019 at 5:27 PM John Dale <jcdw...@gmail.com> wrote: >> > >> >> Another thought .. you can do some request dispatching, but without >> >> knowing more about the tools you're using, I can't say for sure if >> >> this is the direction you'll want to go. >> >> >> >> On 4/29/19, Paul Carter-Brown <paul.carter-br...@jini.guru> wrote: >> >> > Hi >> >> > >> >> > I'm trying to design a Kafka consumer and producer that will run >> inside >> >> the >> >> > tomcat jvm and pick up messages off a Kafka topic and translate them >> >> into a >> >> > servlet request and pass it through tomcat and then when the >> >> > response >> >> > is >> >> > complete then translate it into a Kafka message and put it onto >> another >> >> > topic as a reply. This way I can reuse our existing jax-rs rest >> >> > services >> >> > and expose them as an async api over Kafka. The idea is to make the >> >> > Kafka >> >> > messages similar to http in that they would consist of headers and a >> >> body. >> >> > The body would be json. >> >> > >> >> > Now I know this could be done by calling localhost with an http call >> to >> >> > trombone the requests back into tomcat but I'd like to avoid the >> >> associated >> >> > latency and overhead. Is it possible to call tomcat directly >> >> > in-process. >> >> > This does not need to be portable to other containers so can be >> >> > proprietary. >> >> > >> >> > I'm using tomcat 8. In fact its tomee 8 but guessed this is more a >> >> > tomcat >> >> > question than tomee but have sent to both groups just in case. >> >> > >> >> > Thanks for any insights. >> >> > >> >> > Paul >> >> > >> >> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
