servlets uses init() to initialize servlets status and destroy to clean up. Is there a special class name we need to put init() and destroy()? How does servlets know where to find these methods?
asp.net has a global.asax to handle similar thing in asp.net , servlets has a special class to do the same thing?
Thanks
Servlets will ultimately be a subclass of the javax.servlet.Servlet class, which defines those methods.
It should be in the same class as your Servlet class.
All servlets inherit this method from the base Servlet class. Unless you want to do some additional processing, the inherited method should be fine and you dont need to override this method in each of your servlets.
Servlets are deployed in the Container(Web Server/Application Server),That container will take care of initializing or destroying of servlets,and we dont have predefined classes to initialise and destroy for servlets,if we use particular class that means we are depending on that class(Tightly Coupling) thats not recomended.
Now we are using GenericServlet,and HttpServlet classes for that methods..once refer J2EE API and find this classes and methods in them..
The JVM which runs the Servlet, looks for those methods only in classes, which extend Servlet or HttpServlet.
Servlets are managed objects. This means that they are executed inside a container that manages their lifecycles (instantiates the servlets, call their relevant methods when it is appropiate, and releases them). The container (Tomcat, Glassfish, ...) knows when to call these methods at the right time because it is implemented that way, there is nothing special about that.
If the container had a bug, it could even call, say, destroy() at init time and init() at destroy time. That bug would be fixed quickly, though.
Related
two classes extend Application
One class I've registered in the Manifest and am using as an Application is meant to be
Second class is my utilities class. It does lots of I/O and has a few helper methods. For I/O you need context (getAssets etc), so I reluctantly extended Application.
Note:
Everything is working as it should.
My Question:
Are there any drawbacks of using multiple Application classes? Is this even advised?
A few thoughts:
Like what would happen if I had onCreate and other callback methods defined in both the classes?
How do I register them both in the manifest even?
etc
PS: I know I can just use a field to store context in the second class.
I think this is not advised at all, because there is could only be one instance on Application (thus only one class).
I am very suspicious about what is really working. You're talking about utility class, so maybe you're using static methods that are working well. But you should use your debugger, and I'm almost certain that you'll discover that one of your classes is never instantiated.
By the way, the official documentation states that :
" There is normally no need to subclass Application. In most situations, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), the function to retrieve it can be given a Context which internally uses Context.getApplicationContext() when first constructing the singleton. "
Is there any point in having a constructor in a Java Web Service class? (There seems to be no consensus in the articles I have found so far.)
I am using Jersey to implement a REST web service that needs to have a non-static common object (a string-processing utility class) made available to various (non-static) methods of the service.
Initializing this common object would typically happen in the constructor of the class, if that were not a web service. But what about now that it is?
If a constructor cannot be used, should I put, in every relevant method, a synchronized block that checks whether the common object is available and, if not, initialize it? Or is there a better approach?
Every web service class does have a constructor. If you don't include one then Java automatically adds the default no-arg constructor for you. You can:
Initialize the utility instance when declaring it's class variable
Manually add the default constructor and initialize the utility
instance in it
Or if your using JEE6 you can inject the utility instance into your
web service
It's just an opinion, but if you want to adhere 100% to REST your web service should be stateless. Initializing common objects in web service method calls implies state so it's not the best idea.*
*this is debatable, as can be seen in comments. However any synchronization and shared object initialization if not necesarry IMO should be a no-no in REST applications.
Contructor certainly is a solution, even better one would be to use dependency injection and inject the object you need to your webservice instance at creation.
Try #PostConstruct annotation. It might help you.
I understand that this is normally not done, and I've found a number of instances of this question around the web with answers of the sort: "Your design is wrong if you need to do this." Let me explain my goal.
I have a web app that at one site somehow caused one servlet's init() method to be called repeatedly. I don't know how this happened and I cannot repeat it. However, from a binary heap dump (caused by an out-of-memory exception), it is very clear from objects on the heap that a specific servlet's init() method got called about 10,000 times, as that is the only place these objects are created and there were 10,000+ instances of an object that is supposed to have no more than one instance.
Since I cannot reproduce what happened at this one site, I instead want to forcefully invoke init() many times on this servlet, preferably via a JSP file, so I can test before and after a fix is applied. Testing the "after" case is easy in theory because I can change the code to (for example) stick this servlet into the context so I can get it and repeatedly call init() to prove that there is no leak of this object. But this does not help me test the "before" case with the existing code.
I cannot just "(new MyServlet()).init()" in a JSP. This fails as the servlet is created with a null context and fails to initialize. By Tomcat 5.5, it seems that ServletContext.getServlets() always returns an empty Enumeration and that ServletContext.getServlet(String) always returns null.
It seems the easiest way to test is if I can somehow programmatically (preferably from a JSP) get access to the servlet instance in question, or alternately, programmatically add new mappings to that same servlet class, which might create new instances. (?)
You've already figured out that what you are attempting is highly out of the ordinary and far from a best practice so I won't go into any detail on that subject. Having said that, if you want to invoke MyServlet.init() many times on an instance of MyServlet running within Tomcat, you could subclass MyServlet, override the doGet() or doPost() method, add a loop that simply calls this.init(); 1000 times and then call the parent classes doGet()/doPost(). Edit WEB-INF/web.xml to use your subclass in place of MyServlet. Then just hit the servlet with your web browser and see init() called 1000 times prior to serving the page normally. And you haven't modified the original MyServlet class at all, keeping your before test pure.
You can create a servlet instance like any other class object. Get hold of the servlet config by overriding the method init(ServletConfig config). And create the servlet class instance as many as u want, and call init(ServletConfig config) on all those instances created.
I have an asynchronous method in my EJB singleton that's called from another method in the same class. I already know that I can't call the asynchronous method directly, I have to obtain an EJB proxy. The problem is, I don't want the asynchronous method to be visible outside the class; but when I make it private, it's not executed asynchronously. (I'm using Glassfish v3.)
The javadocs don't say anything about the required access level. So should this be considered a bug in Glassfish?
method annotation cannot be used in private methods. When Glassfish is compiling your EJB it will basically convert your annotation into a piece of code that will surround your code in a proxy. If your method is private it will bypass the proxy Glassfish created... So, in your case I suggest to create a new EJB with your asynchronous method in inject it in your current EJB
That's a very interesting bit of feedback. I can see the value in what you are trying to do. Try marking your bean as an #LocalBean and annotating your #Asynchronous method as protected.
As #LocalBean support is basically done via subclassing the bean class (dynamically or statically), it isn't really possible for the container to override the private method. But I can certainly see your use case. If the protected method approach doesn't work, we can probably add this as an enhancement to EJB.next.
Would still give access to other beans in the same package, but it's at least less public. I've often wished Java had an 'only subclasses' scope. I've almost never used protected and thought, "great, now everyone in my package can access this too."
I am wondering if/where I can put some code to run the VERY first time the Vaadin server is initialized? (Not the first time a user hits the site)
(For example for loading proxy settings from files, starting rss crawlers etc.)
It's quite possible I'm missing a trick with the JavaEE stuff here, I'm pretty new to this stuff.
Use ServletContextListeners. It's an interface whose contextInitialized method is called everytime the server is started. They are really simple to use, just implement the interface and add your context listener to the web-xml, see this example.
Another way would be to extend ApplicationServlet and override the init() method.
Then you have to modify your .xml file to point to this servlet instead of Vaadin's default one.
This method is called once the servlet is brought up by the container.