I have an applet that communicates with a servlet using Http (Not sockets). Currently, each instance of the applet (i.e. when each applet is run by a different client on a different computer), all the instances communicate with the same servlet. What I want is that each instance of the applet communicate with different instances of the same servlet. Is this possible?
You don't want to have different instances of the same servlet in webapp's lifetime. The normal practice is to use the HttpSession to distinguish between clients. You need to pass the HttpSession#getId() as parameter to the applet in question:
<param name="jsessionid" value="${pageContext.session.id}">
Then, in the Applet connect the Servlet as follows:
String jsessionid = getParameter("jsessionid");
URL servlet = new URL(getCodeBase(), "servleturl;jsessionid=" + jsessionid);
URLConnection connection = servlet.openConnection();
// ...
Here servleturl obviously should match servlet's url-pattern in web.xml. You can alternatively also set a Cookie request header using URLConnection.setRequestProperty().
Finally, in the Servlet, to get and store client specific data, do as follows:
// Store:
request.getSession().setAttribute("data", data);
// Get:
Data data = (Data) request.getSession().getAttribute("data");
Hope this helps.
From your question it seems that your servlet contains state. Every applet will have a session with the servlet container which your servlet can access. You can create an object that holds the state per session and place that object as attribute in the session of the caller. This way the servlet container is free to share one servlet instance among many clients.
The usual way to handle instance-specific actions is to have information stored in the session scope made available by the servlet container, not by having information stored in the servlet itself.
For it to work, your applet must correctly send cookies or the JSESSIONID attribute as provided by the web container or the applet must request a instance specific URL inside the servlet.
I would suggest you familiarize yourself further with the Servlet API specification in order to learn more about what is available to you.
Also note that some application servers support the notion of "clients" which are programs invoked with code served from the application server which have direct access to the inside of the application server code. The actual communication is handled by libraries also provided by the applcation server so this is simple. Glassfish and Trifork can do this.
Related
I have a tomcat server running a webapp. In the webapp's startup, I'm setting few context parameters using an implemented class for interface ServletContextListener. The parameter that I am initializing here are a couple of connection objects for a database running on a different machine.
The doubt that i have is whether the connection objects that I created here are one for each instance (since tomcat creates one instance per client request), or one for the entire webapp itself?.
If it is one per webapp, then can the server handle large simultaneous requests (in the order of thousand request per second) to perform the CRUD operations on the database?.
ServletContext is created one per webApp. The server reads the web.xml file from the web app and creates a ServletContext based on the configuration you provide on web.xml. Once created it is shared between the components of the web app. If you have multiple webapp installed on your server, you will have multiple ServletContext - each for the web app.
For reference please have a look here
A webapp has only one instance of ServletContext and the atributes in ServletContext are application scoped.
Regarding you database connection, it's better to use connection pooling (DataSource) instead of adding Connection objects as attributes in ServletContext.
Not sure if you mean this but the requests are handled by Servlets and not ServletContext.
If your setting an attribute on the ServletContext the attribute will be scoped for the entire application.
From the Java EE 7 Spec:
There is one instance object of the ServletContext interface
associated with each Web application deployed into a container.
only one ServletContext is loaded irrespective of the number of requests made.
This is even the advantage of servlets over CGI.
Hope it helps.
Is HttpSession object available to all the applications that is running in the same java enterprise application server?
For my work, i have login application which does the authentication and then it will be forwarded to another application.In Second application, filter is added to prevent the direct access to the URL
ServletContext - gets only the context of the current webapplication.
What is the correct approach to handle this scenario?
The HttpSession objects are scoped at the application (or servlet context) level.
An excerpt from Java™ Servlet Specification:
HttpSession objects must be scoped at the application (or servlet
context) level. The underlying mechanism, such as the cookie used to
establish the session, can be the same for different contexts, but the
object referenced, including the attributes in that object, must never
be shared between contexts by the container.
To illustrate this requirement with an example: if a servlet uses the
RequestDispatcher to call a servlet in another Web application, any
sessions created for and visible to the servlet being called must be
different from those visible to the calling servlet.
An approach to handle this scenario:
You can get access to the resources available for one servlet context from the other by using servletContext.getContext("/otherWebappContext") method as below:
request.setAttribute("userToken", <token>);
RequestDispatcher requestDispatcher = getServletContext().getContext(
"/otherWebappContext").getRequestDispatcher("/resource");
requestDispatcher.forward(request, response);
But any session created for the servlet being called is different from that of the calling servlet. Once the request is forwarded to the second application, it can create a new session with the data received through the request attributes.
But for security reasons, servlet containers normally prevent these cross-context operations. So you need to change the default behavior. For example, in Tomcat 6 you need to set the crossContext attribute to "true" for <Context> element in TOMCAT_HOME/conf/context.xml file as below:
<?xml version='1.0' encoding='utf-8'?>
<Context crossContext="true">
<!-- Default set of monitored resources -->
<WatchedResource>WEB-INF/web.xml</WatchedResource>
</Context>
No HttpSession Object is not available to all the applications present in the same server.
To verify,
create 2 apps,
In one app use seesion.setAttribute("hello","hello");
Now run second app
if(session.getAttribute("hello")==null)
{
//some codes to check
}
else
{
//some codes to check
}
You will see if part will be executed
No HttpSession objects are not shared among applications. The standard way of sharing an information among different applications in a container is to use ServletContext. The only limitation with ServletContext is that if a web applicationa is distributed between multiple JVM this will not work because context info is within one JVM.
As a developer of Java web application, when do I need to use URL Rewriting and what is the difference between URL Rewriting and Forwarding?
I searched on other websites, I get contradictory information depending upon whom you are talking to like SEO people would answer this question differently.
AFAIK in both cases the client (browser) is not informed of the change and the end user sees exactly same URL that the client originally requested when the repose is returned from the server.
Please that this question is in the context of Java Servlet API in which forward method and sendRedirect methods are defined in which redirecting and forwarding are completely 2 different things. This question is about the difference between forward (as defined by forward method in the Servlet API's) and URL rewriting. The question clearly states that the answer should be in the context of Java servlet. Most importantly when do I need to use URL rewriting, again in the context of developing Java web application.
The term "forwarding" is ambiguous in this question. In JSP/Servlet world, "forwarding" is more known from the MVC concept that the request URL (as visible in browser address bar) effectively calls the servlet (as matched by its URL pattern in web.xml or #WebServlet) which acts as a controller to prepare the model and uses a JSP as view to present the model. That JSP in turn is been called by "forwarding". This is done by RequestDispatcher#forward():
request.getRequestDispatcher("/WEB-INF/foo.jsp").forward(request, response);
This does indeed not reflect the JSP's URL in the browser address bar. This takes place entirely server side. Basically, the servlet "loads" the JSP and passes the request/response to it so that it can do its job of generating the HTML stuff. Note that the JSP in the above example is hidden in /WEB-INF folder which makes it inaccessible for endusers trying to enter its full path in browser address bar.
In general web development world, the term "forwarding" is also known from "URL forwarding" which is essentially the same as URL redirection. This in turn indeed causes a change in the browser address bar. This is in JSP/Servlet world more formally known as "redirecting" (although most starters initially confuse it with "forwarding"). This is done by HttpServletResponse#sendRedirect():
response.sendRedirect("another-servlet-url");
Basically, the server tells the client by a HTTP 3nn response with a Location header that the client should make a new GET request on the given Location. The above is effectively the same as the following:
response.setStatus(302);
response.setHeader("Location", "another-servlet-url");
As it's the client (the webbrowser) who is been instructed to do that job, you see this URL change being reflected back in the browser address bar.
The term "URL rewriting" is also ambiguous. In JSP/Servlet world, "URL rewriting" is the form of appending the session ID to the URL so that cookieless browsers can still maintain a session with the server. You'll probably ever have seen a ;jsessionid=somehexvalue attribute in the URL. This is by default not done automatically, but most Servlet based MVC frameworks will do it automatically. This is done by HttpServletResponse#encodeURL() or encodeRedirectURL():
String encodedURL = response.encodeURL(url); // or response.encodeRedirectURL(url)
// Then use this URL in links in JSP or response.sendRedirect().
(Which in turn is -again- an ambiguous term. With "URL encoding" you'd normally think of percent encoding. There's no Servlet API provided facility for this, this is normally to be done by URLEncoder#encode() or, MVC-technically more correct, in the JSP by JSTL's <c:url> and <c:param> or any UI component provided by the servlet-based MVC framework, such as JSF's <h:outputLink>)
In general web development world (especially with Apache HTTPD / PHP folks), "URL rewriting" is more known as whatever Apache HTTPD's mod_rewrite is doing: mapping incoming URLs to the concrete resources without reflecting the URL change in the client side. In JSP/Servlet world this is also possible and it's usually done by a Filter implementation which uses RequestDispatcher#forward(). A well known implementation is the Tuckey's URLRewriteFilter.
I admit that this has also confused me for long when I just started with JSP/Servlet, for sure while having my roots in the Apache HTTPD / PHP world.
Rewriting is a layer (often before your servlet) that causes a URL to be handled like a different URL by modifying the URL before the request is served. The servlet responds through a single request as if the rewritten URL was requested, usually having never known the rewrite occured.
Forwarding (or redirection) is performed by the browser (typically automatically) when instructed by the server via some 3xx error codes (when redirection is allowed by the client). In this case two requests would be served (not necessarily both from your servlet); the first responding with an error code and a URL to redirect to, and the second serving the proper request after the client redirects.
Is there a tutorial or a simple applet example with JSF? How do I perform a request to a Managed Bean from an applet?
Don't use a JSF managed bean. It is not suitable for this job. Use a servlet or a webservice. To exchange data, use the session scope with an unique autogenerated key which you pass as parameter to the applet beforehand. This way the data will be available to JSF as well.
JSF (and hence managed beans) executes on the server to produce HTML; An applet executes on the client's machine - so you can't just pass a reference to a managed bean to an applet.
If you just need to pass a value from a managed bean to an Applet at start time, you can use the <param> sub-element of the tag to pass this value.
If you need some kind of dynamic access to the managed bean, it's going to be a lot harder - basically, you'll need to build some kind of web service that's backed by the managed bean so that the applet can make http requests back to the server to get the values it needs.
My application consists of 2 servlets,the major one loads the config files in init method and processes get/post requests,
if anything fails during config load, i need to stop the application.
as far i know, i couldnt be able to stop whole application context through some java code ,hence i'm throwing UnavailableException in Servlet.hence i wont be processing get/post request.
but the second servlet does some dynamic reload of configuration on demand.but irrespective of major servlet failed or succeed,it processes reloading requests.
can you suggest a way to check the status of major servlet (running,stopped).so that second servlet can take decision whether to accept reload request or not.
Just share some status variable, like AtomicBoolean between two servlets. By the way, it's more clear design to make both servlets just accept http requests, decode them and pass requests to corresponding business-logic objects. This way, servlets will contain only logic concerned with HTTP sending/receiving.