Can a servlet receive its own request?
Simple question, but it's driving me nuts. I really don't want to get into the whole web service business - all I need is for a servlet to be the recipient of its own request. Or - in other words - can a servlet act like a web browser - just without the GUI? Use case: - Servlet issues https request to an outside server (via getServletContext().getRequestDispatcher(https://www.someoutsideserver/) ) - Outside server processes request and responds with POST response (also via https). - Servlet [somehow] is able to be the recipient of the response. - Servlet parses the response and stores data to the database. Notes: - The servlet is not the default servlet on that tomcat instance. - Everything happens via https and I expect the outside server will listen on 443 and tomcat on 8443 ANY suggestions would be very helpful - this seems to be a tricky one. TIA, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Can a servlet receive its own request?
I don't think so. You will have to have something start the request. Servlets are loaded by the container and are run in response to a request. Once the servlet is running, there is no reason why it could not make an http request for data from another server/servlet and parse the response. Robert S. Harper Senior Engineer Information Access Technology, Inc. 1100 East 6600 South Suite 300 Salt Lake City, Utah USA 84121-7411 (801)265-8800 Ext. 255 FAX (801)265-8880 This e-mail is intended only for the addressee and may contain confidential and/or privileged information. Any review, retransmission, or action taken upon this information by persons other than the intended recipient is prohibited by law. If you received this communication in error, please contact us immediately at 801-265-8800. Although this e-mail and any attachments are believed to be free of any virus or other defect, it is the responsibility of the recipient to ensure that anything received or opened is virus free. No responsibility is accepted by IAT for any loss or damage in the event that such a virus or defect exists. -Original Message- From: Michael Mehrle [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 9:59 AM To: Tomcat Users List Subject: Can a servlet receive its own request? Simple question, but it's driving me nuts. I really don't want to get into the whole web service business - all I need is for a servlet to be the recipient of its own request. Or - in other words - can a servlet act like a web browser - just without the GUI? Use case: - Servlet issues https request to an outside server (via getServletContext().getRequestDispatcher(https://www.someoutsideserver/) ) - Outside server processes request and responds with POST response (also via https). - Servlet [somehow] is able to be the recipient of the response. - Servlet parses the response and stores data to the database. Notes: - The servlet is not the default servlet on that tomcat instance. - Everything happens via https and I expect the outside server will listen on 443 and tomcat on 8443 ANY suggestions would be very helpful - this seems to be a tricky one. TIA, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can a servlet receive its own request?
You *probably* could do this... I'm not 100% sure. What I *AM* sure about though is that this would be pretty ugly :) I'm not sure what you mean by Outside server processes request and responds with POST response (also via https). though... Is the idea that the request to the outside server is to be asychronous, or will your servlet be awaiting a reply? If the former, then you probably can go with your approach and it won't be all that ugly... it's essentially nothing more than another request coming in to the servlet, same as always, your just going to process it differently... as long as you get enough information back to be able to complete the transaction, it should work fine. Just treat the initial request to your servlet and the response back from the outside server as two separate requests and you should be fine. If however, as I suspect might be the case, your servlet is going to actually be awaiting a reply from the outside server, then you should look at using Commons HTTPClient. I'm relatively sure it supports SSL connections, and then all your doing is making a remote request, awaiting the response and processing accordingly. It'd be just like using the standard URL object, but it's more robust than that. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, May 18, 2005 11:58 am, Michael Mehrle said: Simple question, but it's driving me nuts. I really don't want to get into the whole web service business - all I need is for a servlet to be the recipient of its own request. Or - in other words - can a servlet act like a web browser - just without the GUI? Use case: - Servlet issues https request to an outside server (via getServletContext().getRequestDispatcher(https://www.someoutsideserver/) ) - Outside server processes request and responds with POST response (also via https). - Servlet [somehow] is able to be the recipient of the response. - Servlet parses the response and stores data to the database. Notes: - The servlet is not the default servlet on that tomcat instance. - Everything happens via https and I expect the outside server will listen on 443 and tomcat on 8443 ANY suggestions would be very helpful - this seems to be a tricky one. TIA, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can a servlet receive its own request?
Requests from from a browser or any other suitable socket based mechanism that sends requests. Servlets and servers don't send requests, although you can have a client in a server that does send requests. You could, I suppose, even build a request making mechanism inside a servlet or as a field for a servlet. But, that does not mean the servlet is making the request qua Servlet. Servlets handle requests and return responses. Responses are not requests. Responses tend to be HTML and requests are name value pairs and streams. On 5/18/05, Michael Mehrle [EMAIL PROTECTED] wrote: Simple question, but it's driving me nuts. I really don't want to get into the whole web service business - all I need is for a servlet to be the recipient of its own request. Or - in other words - can a servlet act like a web browser - just without the GUI? Use case: - Servlet issues https request to an outside server (via getServletContext().getRequestDispatcher(https://www.someoutsideserver/) ) - Outside server processes request and responds with POST response (also via https). - Servlet [somehow] is able to be the recipient of the response. - Servlet parses the response and stores data to the database. Notes: - The servlet is not the default servlet on that tomcat instance. - Everything happens via https and I expect the outside server will listen on 443 and tomcat on 8443 ANY suggestions would be very helpful - this seems to be a tricky one. TIA, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can a servlet receive its own request?
You might want to look at the COS message classes. On 5/18/05, Michael Mehrle [EMAIL PROTECTED] wrote: Simple question, but it's driving me nuts. I really don't want to get into the whole web service business - all I need is for a servlet to be the recipient of its own request. Or - in other words - can a servlet act like a web browser - just without the GUI? Use case: - Servlet issues https request to an outside server (via getServletContext().getRequestDispatcher(https://www.someoutsideserver/) ) - Outside server processes request and responds with POST response (also via https). - Servlet [somehow] is able to be the recipient of the response. - Servlet parses the response and stores data to the database. Notes: - The servlet is not the default servlet on that tomcat instance. - Everything happens via https and I expect the outside server will listen on 443 and tomcat on 8443 ANY suggestions would be very helpful - this seems to be a tricky one. TIA, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can a servlet receive its own request?
Those classes are browsers without a GUI. I do this sort of thing all the time. On 5/18/05, Dakota Jack [EMAIL PROTECTED] wrote: You might want to look at the COS message classes. On 5/18/05, Michael Mehrle [EMAIL PROTECTED] wrote: Simple question, but it's driving me nuts. I really don't want to get into the whole web service business - all I need is for a servlet to be the recipient of its own request. Or - in other words - can a servlet act like a web browser - just without the GUI? Use case: - Servlet issues https request to an outside server (via getServletContext().getRequestDispatcher(https://www.someoutsideserver/) ) - Outside server processes request and responds with POST response (also via https). - Servlet [somehow] is able to be the recipient of the response. - Servlet parses the response and stores data to the database. Notes: - The servlet is not the default servlet on that tomcat instance. - Everything happens via https and I expect the outside server will listen on 443 and tomcat on 8443 ANY suggestions would be very helpful - this seems to be a tricky one. TIA, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can a servlet receive its own request?
Thanks for your elaborate reply - actually, someone else also suggested to use commons HTTPClient. I might have over-explained all this - the major difference is that the servlet is being launched by Quartz, not by an outside HTTP request. Thus, it is the servlet that needs to be able to receive the response to its own request, and it appears that HTTPClient might enable the servlet to do this. Michael - Original Message - From: Frank W. Zammetti [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Cc: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Wednesday, May 18, 2005 10:05 AM Subject: Re: Can a servlet receive its own request? If however, as I suspect might be the case, your servlet is going to actually be awaiting a reply from the outside server, then you should look at using Commons HTTPClient. I'm relatively sure it supports SSL connections, and then all your doing is making a remote request, awaiting the response and processing accordingly. It'd be just like using the standard URL object, but it's more robust than that. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can a servlet receive its own request?
From: Michael Mehrle [EMAIL PROTECTED]
Sent: Wednesday, May 18, 2005 8:58 AM
- Servlet issues https request to an outside server (via
getServletContext().getRequestDispatcher(https://www.someoutsideserver/) )
- Outside server processes request and responds with POST response (also
via
https).
- Servlet [somehow] is able to be the recipient of the response.
- Servlet parses the response and stores data to the database.
Your problem is with the whole model.
There is no reason why a Servlet can't send an HTTP(S) request to another
server.
But the server that you are making the request shouldn't be making an
independent POST back to you, rather it should just send you the data you
want back as the reply body. You then parse the reply and move on.
IF you insist that the reply be in the manner of a POST from the other
server (really really silly IMHO), then, simply, you need to make the
request to the other server be the last thing your Servlet does. Then when
the POST comes back, you pick up where you left off, tracking your state
through a request parameter.
So, your Servlet may start with a request like:
http://otherserver.com/processData?mysession=123stage=1
Then the otherserver replies with a POST to:
http://yourserver.com/yourServlet?mysession=123stage=2
You use the mysession information to maintain your state between requests.
But the key is that your servlet ends each time, and Tomcat then restarts it
when the POST comes back.
It's still a silly idea. You don't need Webservices, SOAP, XML-RPC, etc to
talk to another server via HTTP. You can easily stream serialized Java
objects to each other if you want, use the simple Java Properties file
format for your responses, etc. I think if you have control over both
servers, WEB RPC can be very simple for a limited domain. If you don't
have control over the other server, then you do what you have to do.
I mean, seriously:
public class AddNumberServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
PrintWriter out = response.getWriter();
String arg1 = request.getParameter(arg1);
String arg2 = request.getParameter(arg2);
int i1 = Integer.parseInt(arg1);
int i2 = Integer.parseInt(arg2);
int result = i1 + i2;
out.println(answer= + result);
}
}
public class RequesterServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
PrintWriter out = response.getWriter();
URL reqURL = new
URL(http://otherserver/AddNumberServlet?arg1=2arg2=4);
Properties result = new Properties();
result.load(reqURL.openStream());
String answer = result.get(answer);
out.println(HTMLBODYWhen you add up 2 and 4 you get + answer
+ /BODY/HTML);
}
}
There. Instant web service.
Error checking and robustness are left as an exercise for the reader, but
you can see that you don't need a 500 page book to get some data from
another web server.
Not to discount the XML-RPC and SOAPs, they have their place most certainly.
No doubt XML-RPC started just like this and grew from there (and then into
SOAP), but its just a simple example of how easy this can be when you have
control over the whole shebang.
Regards,
Will Hartung
([EMAIL PROTECTED])
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can a servlet receive its own request?
I've done something a little similar w/ the HTTPClient. What I ended up w/ was a Object that was run in the Servlet container but was not itself a servlet. Nit-picking. Anyway, you can do this, you just have to use other libraries (like the Commons HTTPClient). Michael Mehrle wrote: Thanks for your elaborate reply - actually, someone else also suggested to use commons HTTPClient. I might have over-explained all this - the major difference is that the servlet is being launched by Quartz, not by an outside HTTP request. Thus, it is the servlet that needs to be able to receive the response to its own request, and it appears that HTTPClient might enable the servlet to do this. Michael -- Robert r. Sanders Chief Technologist iPOV (334) 821-5412 www.ipov.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can a servlet receive its own request?
I don't think saying it's silly is really helpful, or even necessarily
accurate...
If the idea is that the request to the outside server is meant to to
asynchronous, i.e., maybe it feeds a queue or something, then it's a
reasonable model. It doesn't sound like that's what the OP meant, but if
it was, it would be reasonable.
Of course, even in that case the servlet is not receiving its own
request, it is simply making a request, at which point it is done, and at
some future time receiving a request with the results.
I agree with you that Web Services need not be as complicated as some make
it out to be... no need to involve SOAP or XML-RPC or any other of the
numerous alphabet soup entries. I was doing Web Services seven years
ago, long before I heard the term. I suppose you could say that's not
standards-compliant, which is one of the goals behind Web Services of
course... if everyone used the same mechanisms than theoretically it would
all be interoperable with no effort, and that's not the case if you
essentially cook up your own protocols, but since the reality is that even
following the standards you rarely get that right now, it's not such a
problem :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Wed, May 18, 2005 2:53 pm, Will Hartung said:
From: Michael Mehrle [EMAIL PROTECTED]
Sent: Wednesday, May 18, 2005 8:58 AM
- Servlet issues https request to an outside server (via
getServletContext().getRequestDispatcher(https://www.someoutsideserver/)
)
- Outside server processes request and responds with POST response (also
via
https).
- Servlet [somehow] is able to be the recipient of the response.
- Servlet parses the response and stores data to the database.
Your problem is with the whole model.
There is no reason why a Servlet can't send an HTTP(S) request to another
server.
But the server that you are making the request shouldn't be making an
independent POST back to you, rather it should just send you the data you
want back as the reply body. You then parse the reply and move on.
IF you insist that the reply be in the manner of a POST from the other
server (really really silly IMHO), then, simply, you need to make the
request to the other server be the last thing your Servlet does. Then when
the POST comes back, you pick up where you left off, tracking your state
through a request parameter.
So, your Servlet may start with a request like:
http://otherserver.com/processData?mysession=123stage=1
Then the otherserver replies with a POST to:
http://yourserver.com/yourServlet?mysession=123stage=2
You use the mysession information to maintain your state between requests.
But the key is that your servlet ends each time, and Tomcat then restarts
it
when the POST comes back.
It's still a silly idea. You don't need Webservices, SOAP, XML-RPC, etc to
talk to another server via HTTP. You can easily stream serialized Java
objects to each other if you want, use the simple Java Properties file
format for your responses, etc. I think if you have control over both
servers, WEB RPC can be very simple for a limited domain. If you don't
have control over the other server, then you do what you have to do.
I mean, seriously:
public class AddNumberServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
PrintWriter out = response.getWriter();
String arg1 = request.getParameter(arg1);
String arg2 = request.getParameter(arg2);
int i1 = Integer.parseInt(arg1);
int i2 = Integer.parseInt(arg2);
int result = i1 + i2;
out.println(answer= + result);
}
}
public class RequesterServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
PrintWriter out = response.getWriter();
URL reqURL = new
URL(http://otherserver/AddNumberServlet?arg1=2arg2=4);
Properties result = new Properties();
result.load(reqURL.openStream());
String answer = result.get(answer);
out.println(HTMLBODYWhen you add up 2 and 4 you get +
answer
+ /BODY/HTML);
}
}
There. Instant web service.
Error checking and robustness are left as an exercise for the reader, but
you can see that you don't need a 500 page book to get some data from
another web server.
Not to discount the XML-RPC and SOAPs, they have their place most
certainly.
No doubt XML-RPC started just like this and grew from there (and then into
SOAP), but its just a simple example of how easy this can be when you have
control over the whole shebang.
Regards,
Will Hartung
([EMAIL PROTECTED])
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Re: Can a servlet receive its own request?
Yes, I'm now going the HttpClient route - and yes, I also realized that the object to be launched doesn't have to be a servlet at all. I was just anchored in thinking along those lines since I thought that the servlet would be the one receiving its own response. Anyway, I think I'm on the right track now. Many thanks to everyone who replied to my post - every input was very valuable. Michael - Original Message - From: Robert r. Sanders [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Wednesday, May 18, 2005 1:08 PM Subject: Re: Can a servlet receive its own request? I've done something a little similar w/ the HTTPClient. What I ended up w/ was a Object that was run in the Servlet container but was not itself a servlet. Nit-picking. Anyway, you can do this, you just have to use other libraries (like the Commons HTTPClient). Michael Mehrle wrote: Thanks for your elaborate reply - actually, someone else also suggested to use commons HTTPClient. I might have over-explained all this - the major difference is that the servlet is being launched by Quartz, not by an outside HTTP request. Thus, it is the servlet that needs to be able to receive the response to its own request, and it appears that HTTPClient might enable the servlet to do this. Michael -- Robert r. Sanders Chief Technologist iPOV (334) 821-5412 www.ipov.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
