I'm creating an atmosphere servlet application, which uses the following servlet in web.xml https://atmosphere.java.net/nonav/apidocs/org/atmosphere/cpr/AtmosphereServlet.html.
When this service starts up I would like to start to an Akka actor system and have it available throughout the life of the application.
How is this done?
I believe what you want to do is initialize an actor system within the servlet context. This question/answer should help. Don't forget to include the ContextListener in your web.xml.
Related
I'm planing to migrate my old app to Spring-Boot.
I want to stop using web.xml descriptor and register old pure Servlet ("async-supported" enabled) and an associated ServletContextListener.
Spring Boot will automatically register any Servlet beans in your application context with the servlet container. By default async supported is set to true so there's nothing for you to do beyond creating a bean for your Servlet.
If, for whatever reason, you want to take more control over your servlet's registration, then, rather than exposing the Servlet itself as a bean, you can wrap it in a ServletRegistrationBean.
Put a #EnableAsync on your application class.
See here for more details.
servletRegistrationBean.isAsyncSupported() is by default true which decides whether the Async functionality is supported or not.
.
If you are facing below issue then follow the link
java.lang.IllegalArgumentException: Async support must be enabled on a
servlet and for all filters involved in async request processing. This
is done in Java code using the Servlet API or by adding
"true" to servlet and filter
declarations in web.xml. Also you must use a Servlet 3.0+ container
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 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.
I asked this question earlier:
Jersey app-run initialization code on startup to initialize application
Is there any way to run this initialization code after the server has initialized the web app fully ? I am running into a catch-22 problem in that I need the web app fully started by Tomcat before I can run my login call once ?
There are a few considerations. First, Jersey is implemented as a servlet, and that's how it gets loaded. The simplest way to decouple servlet startup from servlet context startup is to not load it on startup. Accomplish this by omitting the load-on-startup element from the servlet descriptor in the web.xml. Setting it to a non-positive should also work.
If you must load the servlet on startup but still want to decouple it, which was my case, you'll probably have to write some custom code, which I did. I couldn't think of any other way. Use a listener of some type--a ServletContextListener or Spring ApplicationListener, depending on exactly how your app is set up--to kick off a new thread that will initialize your Jersey servlet by making an HTTP request to it. It feels a little dirty, but like I said, it's the only thing I and my team could come up with.
Is there a way to initialize the ServletContext for a webapp on a Resin server using a method? I need something like that runs once, when the server starts up.
You need to use a ServletContextListener.
http://www.java-tips.org/java-ee-tips/java-servlet/how-to-work-with-servletcontextlistener.html
This J2EE tip demonstrates use of
ServletContextListener. This event
class handles notifications about
changes to the servlet context of the
Web application that they are part of.
This can be explained as if someone is
present on the server and dynamically
informing us about the events that are
occuring on the server. There acquire
need of Listners. Therefore,
ServletContextListner is helpful in
informing about context Initilazation
and destruction.
Use the <load-on-startup/> in the <servlet> tag.