We know that whenever a request for a servlet comes, servlet container will first check web.xml file for url and corresponding servlet classes. This is fine, But the confusion comes after that. Suppose I am using load-on-startup property. SO, the servlet should be ready before first call comes in. In that case container need servlet Config object to make servlet in work. But again load-on-start up and init-parameter for servlet is defined in web.xml file. So when exactly container uses web.xml?( when load-on-startup property is used then container can not obviously wait for first call, again container has to read web.xml file to know whether that property is used with any servlet.)
It will be better if some one can clear my confusion. Please provide some dependable link also if possible.
Loading and Instantiation:
The servlet container is responsible for loading and instantiating servlets. The loading and instantiation can occur when the container is started, or delayed until the container determines the servlet is needed to service a request.
When the servlet engine is started, needed servlet classes must be located by the servlet container. The servlet container loads the servlet class using normal Java class loading facilities. The loading may be from a local file system, a remote file system, or other network services. And as the servlets are declared in the web.xml, this file is loaded and read by the container during container startup.
Initialization:
After the servlet object is instantiated, the container must initialize the servlet before
it can handle requests from clients.The container initializes the servlet instance by calling the init method of the Servlet interface with a unique (per servlet declaration) object implementing the ServletConfig interface.
Ref: JSR-000315 JavaTM Servlet 3.0
web.xml is read as soon as you deploy your application on a web server. For the sake of understanding, you can assume container is nothing but your web server. Although web server has more than just a web container.
Web server reads the web.xml, and loads the context config, load on startup servelts,etc. web.xml is the file through which you tell your container/server about your application. Your web application sits inside the web server, and server intercepts all the incoming requests, decides to which application the request should be forwarded depending on the context.
Related
A java webapp must choose between either static context or "webcontext". Why do we need a webcontext just for a web server like jetty and why must we route everything to the same "webcontext" ?
Because Jetty is a JEE servlet container and in the JEE world there is a one to one relationship between a webapplication and the web context. The intention is to be able to run several independent webapplications within the same servlet container. So it is easy to route to the appropriate webapplication by the first part of the URL path.
Theoretically it would be possible to declare more than one webcontext for a webapplication but it is specified otherwise. See section 10.2 "Relationship to ServletContext" in Java Servlet Specification 3.1:
The servlet container must enforce a one to one correspondence between
a Web application and a ServletContext. A ServletContext object
provides a servlet with its view of the application.
I am looking for using jersey with embedded Jetty for implementing web APIs for our service. I see code where ServletContextHandler , ServletHolder and all these classes are used to let Jetty know about the Jersey handlers. I am interested to know under the hood, like what happens when we compile this code, how jetty actually discovers the jersey handlers. I know that if I start reading the documentation, I will be able to figure out, however, looking for some quick links that covers this topic. Is there any such link?
Thanks.
Jetty can act as a http server and also a servlet container who deals with the lifecycle of servlets (init, service, destroy)
etc. A servlet is a java class that extends HttpServlet class and can override init, service, destroy methods etc. Once jetty
receives a request whose URL matches with that of a servlet, it loads the servlet in memory (if not already there), calls
service method, and keeps it in memory until it destroys it.
Jersey library has provided a standard way of writing RESTful APIs where classes are annotated with tags like say GET/POST
etc and the URL. These classes are called resource classes. It has also provided a servlet whose name is ServletContainer
to hook up with Jetty's servlet container, that intercepts Jetty's request to process servlet (like for any servlet request to jetty
this is the one class, that receives the request first).
What this servlet does is it examines the request, matches with the resource classes URL that it is informed about, and then transfers
control to that method of that resource class (i think it uses reflection for this routing). Therefore, the resource
classes are not servlet itself, but the ServletContainer class of jersey is the only servlet active in the system.
The list of resource classes ServletContainer knows about is configured by this property called "com.sun.jersey.config.property.packages"
The benefit of using Jersey is implementing your REST APIs is you are using standard way of writing your code that you can
deploy to any other standard servlet container if needed in future like tomcat, ...
We have a web application which is an ear file containing 1 war and 1 MDB jar.
Problem is that I load some properties file in my servlet when first request for servlet comes. These properties I will also need in my MDB. How can I access my Servlet class(inside war) in the EJB jar classes. Is there any way to use my war file as a utility jar.
Application is running on weblogic server.
You don't as a servlet is invoked through a HTTP call. You could hack it by doing an URLConnection to the servlet, but I would rather refactor your code a bit so you can call the initialization code on server startup in stead of by invoking the servlet. A context listener or an EJB init() could already do it.
Extract out your property management into a common, utility JAR that can be accessed from both tiers of your app.
Permanent servlets are loaded when the server is started, and live until the server is
shutdown.
I have requirement to start some server side java programs and These programs then provide functionality that is totally unique and independent of the web server. I wish to do it on Tomcat startup. Solution I see is Permanent Servlet, Which will invokes these Java programs.
So How to configure Permanent Servlets in Tomcat 6 ?
More Details about Permanent Servlets from http://java.sun.com/developer/onlineTraining/Servlets/Fundamentals/servlets.html
Temporary versus Permanent Servlets
Servlets can be started and stopped for each client request, or they can be started as the web server is started and kept alive until the server is shut down. Temporary servlets are loaded on demand and offer a good way to conserve resources in the server for less-used functions.
Permanent servlets are loaded when the server is started, and live until the server is shutdown. Servlets are installed as permanent extensions to a server when their start-up costs are very high (such as establishing a connection with a DBMS), when they offer permanent server-side functionality (such as an RMI service), or when they must respond as fast as possible to client requests.
There is no special code necessary to make a servlet temporary or permanent; this is a function of the server configuration.
Because servlets can be loaded when a web server starts, they can use this auto-loading mechanism to provide easier loading of server-side Java programs. These programs can then provide functionality that is totally unique and independent of the web server. For example, a servlet could provide R-based services (rlogin, rsh, ...) through TCP/IP ports while using the servlet request/response protocol to present and process HTML pages used to manage the servlet.
You can do what you need with a ServletContextListener. Register one in your web.xml, e.g.:
<listener>
<listener-class>com.example.MyServletContextListener</listener-class>
</listener>
Then create that class to do what you want:
public class MyServletContextListener implements ServletContextListener {
public void contextInitialized(ServletContextEvent sce) {
// initialize and startup whatever you need here
}
public void contextDestroyed(ServletContextEvent sce) {
// shutdown and destroy those things here
}
}
I think what they are referring to when they say "permanent servlets" are just the servlets you define in the web.xml, a la,
<servlet>
<description>I'm permanent</description>
<display-name>Servlet</display-name>
<servlet-name>Servlet</servlet-name>
<servlet-class>com.servlet.MyServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
This servlet will be started up when the server starts and will be kept around until it shuts down, probably (See below).
An example temporary servlet would be a .jsp file. It wont load the file up until it is requested and it will probably dispose of it after servicing the request.
Looking at the Servlet Specification about servlet lifecycles,
When the servlet engine is started, needed servlet classes must be located by the
servlet container. The servlet container loads the servlet class using normal Java class
loading facilities. ...
After loading the Servlet class, the container instantiates it for use.
Then for eol,
The servlet container is not required to keep a servlet loaded for any particular
period of time. A servlet instance may be kept active in a servlet container for a
period of milliseconds, for the lifetime of the servlet container (which could be a
number of days, months, or years), or any amount of time in between.
When the servlet container determines that a servlet should be removed from
service, it calls the destroy method of the Servlet interface to allow the servlet to
release any resources it is using and save any persistent state. For example, the
container may do this when it wants to conserve memory resources, or when it is
being shut down.
Before the servlet container calls the destroy method, it must allow any threads that
are currently running in the service method of the servlet to complete execution, or
exceed a server-defined time limit.
Once the destroy method is called on a servlet instance, the container may not route
other requests to that instance of the servlet. If the container needs to enable the
servlet again, it must do so with a new instance of the servlet’s class.
After the destroy method completes, the servlet container must release the servlet
instance so that it is eligible for garbage collection.
So I think bottom line, the servlet specification makes no guarantee as to how long a servlet will be kept, it is implementation specific, but I think its a pretty safe bet that if you load it on start up it will remain loaded for the whole time the server is running.
For your specific use case though, follow WhiteFang34, as using a servlet for something other than servicing requests is abusing the API IMO.
[Edit] Everywhere I look to see how a servlets' lifecycle is managed seems to say that it will remain loaded for the entirety of the webapps lifetime.
Servlets
What is the difference between JSF, Servlet and JSP?
java servlet instantiation and session variables
But nowhere can I find a reference that says that, so I just don't know for certain.
is there any difference between servlet and filter lifecycle?.
No, both a servlet and a filter:
are instantiated (once) when the context starts
the init(..) method is called
they handle each request - first it passes through all filters and then reaches the servlet
when the context is destroyed (i.e. when your container stops, or your application is undeployed from the manager console), the destroy(..) method is called
So far I was also wondering the differences. I created a web project to observe life-cycle of them. It can be check-outed at
http://dntuan-java-workspace.googlecode.com/svn/trunk/simple-web
Once it is deployed on tomcat, you can observe logs from the console to see that filters are initialized before context is started. Whereas servlet is only initialized when a request is made (e.g. http://localhost:8080/simple-web/servlet/life.jsp)
More information from JSR-000315 JavaTM Servlet 3.0:
2.3.1 Loading and Instantiation
The servlet container is responsible for loading and instantiating
servlets. The loading and instantiation can occur when the container
is started, or delayed until the container determines the servlet is
needed to service a request.
6.2.1 Filter Lifecycle
After deployment of the Web application, and before a request causes
the container to access a Web resource, the container must locate the
list of filters that must be applied to the Web resource as described
below. The container must ensure that it has instantiated a filter of
the appropriate class for each filter in the list, and called its
init(FilterConfig config)method.