Yea, but the issue is that only works when calling in the context of a
current servlet call.
Here is the kind of problem I want to solve:
@WebServlet(name = "MyExample", urlPatterns = {"/example"}, loadOnStartup =
1)
public class Example extends HttpServlet {
@PersistenceContext
private EntityManager em;
@Override
public void init(ServletConfig config) {
Thread t = new Thread(() -> {
while (true) {
try {
// Do a GET to /example/ and get the response without
going out on localhost and back in....
// We cant just call doGet as we want the request to
flow through the servlet filters, do the entitymanager injection etc
Thread.sleep(10000);
} catch (Exception e) {
}
}
});
t.start();
}
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
// do stuff like use em
resp.setStatus(200);
resp.getWriter().write("Hello World");
}
}
On Mon, May 6, 2019 at 5:35 PM John Dale <jcdw...@gmail.com> wrote:
> For reference, I did find this after searching "calling a servlet
> programmatically":
> https://docs.oracle.com/cd/E19146-01/819-2634/abxbn/index.html
>
> On 5/6/19, Paul Carter-Brown <paul.carter-br...@jini.guru> wrote:
> > I think we are completely missing each other. Forget sockets - that was
> > just an example. I have code running in a Tomcat App server which is not
> > managed by Tomcat and is not initiated by anything within Tomcat. That
> code
> > now wants to call a servlet hosted in that very same JVM. Any way to do
> > that without going out and back in on TCP?
> >
> >
> > On Mon, May 6, 2019 at 5:14 PM John Dale <jcdw...@gmail.com> wrote:
> >
> >> Sockets are an implementation of TCP/UDP inherently.
> >>
> >> Perhaps a mountaintop signal fire?
> >>
> >> ;)
> >>
> >> John
> >>
> >>
> >> 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
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
