I am trying to identify when a servlet is initilazed (not the init() method called), when container try to load an individual servlet ? Or, any mechanism which keeps track of servlet initialized / destroyed / pending to load.
I am aware of the ServletContextListner, which invoked on application start & shutdown. But, I am looking for kind of listener, which probably trigger on individual servlet load / destroy event.
So, scenario would be like :
/Servlet1
/Servlet2
An listener which trigger on servlet1 load and then for Servlet2.
I guess this is the listener you are looking for .You want to know each time a request comes in, so that you can log it.
javax.servlet.ServletRequestListener . Following are the methods requestInitialized requestDestroyed
Related
I'm trying to set different handlers for different types of tasks created via TimerService , ejb.
I need to figure out a way where I can create a schedule tasks with extra information including the handler type so when a timeout occurs different handlers should be fired according to the timer identification.
Eventually the solution to the problem as i tried to explain is by adding Serialized handler, which is set when you create a timer event.
after you set a handler you can get it from the timer object, so when a timeout occurs we can execute an action according to the relevant handler.
In Servlet 3.0, an application's ServletContainerInitializer implementation (if any) is called when the application first BEGINS starting and any ServletContextListeners (if any) are called soon after, but still as the context is BEGINNING initialization. Likewise, if you have any Servlets with load-on-startup set, their init methods are called as the Servlets are starting up, but still BEFORE the context completes initialization.
In all of these cases, the context has not completed initialization. That is fine and I understand and agree with the reasons for that. What I'm looking for, however, is a way to be notified immediately AFTER the context has completed initialization and is open for business. As an example, it should be possible (not saying I want to do this) for this listener of sorts to perform a web request to the application it resides in. That wouldn't be possible for any of the above mentioned listeners/initializers, since they are called before the application is listening for requests.
Is it possible to do this? Doesn't have to strictly be a Servlet-spec-provided method. Could be Spring Framework or some other library that performs this task.
You can use JBoss Seam they have servlet lifecycle event #Initialized.
public void observeServletContextInitialized(#Observes #Initialized ServletContext ctx)
{
System.out.println(ctx.getServletContextName() + " initialized");
}
How can I unload a servlet from its container using the servlet's constructor or init() method?
If I unload it using the servlet constructor, will the init() method still be called?
Should I throw an exception? If so, checked or runtime?
Just throwing an exception in the servlet's constructor or init() method will prevent it from being taken in the servlet mapping of the servletcontainer.
You can not unload it at a later time when it has already been constructed and initialized successfully. Best what you can do is to just throw an exception in any of the HTTP methods based on some condition.
The right approach however depends on the sole functional requirement. Most probably you do not need a servlet at all. Simply because the desire to unload it manually makes design technically no utter sense.
if we call destroy() on servlet then it doesn't mean that our servlet will be unloaded/destroyed. It simply calls destroy leaving servlet untouched, nothing harm to servlet instance. It is still alive because you called destroy method. It is not container mechanism which is calling destroy method.
when container decides to destroy/unload the servlet instance from memory then container runs destruction mechanism and destroy method is one(along with several steps) of steps of the destruction mechanism. Destruction mechanism give chance to user/developer to clean-up resources which were initialized during the construction/initializing of the instance.
When to use and not to use global.asax file in asp.net application? I heard that you should use that file only at a pinch.
The Global.asax file is used to implement application and session level events, such as:
Application_Init - fired when an application first initializes
Application_Start - fired when the application first starts
Application_End - the final event fired when the application ends or times out
Session_Start - fired the first time a user’s session is started
Application_BeginRequest - fired with each new request
Application_EndRequest - fired when the application ends
Application_AuthenticateRequest - the event indicates that a request is ready to be authenticated.
Application_Error - fired when an unhandled error occurs within the application
Session_End - fired whenever a single user Session ends or times out.
Implementing these handlers can all be legitimate uses of the global.asax. For example, the Application_Error event handler typically logs any global errors, and the Application_End event handler typically contains application cleanup logic. These are good uses of the Global.asax. Use them whenever necessary, and don't be afraid if the file grows.
However, I have seen cases where developers have added all sorts of global methods to the global.asax that are indeed un-justified. For example, keep business logic related to a particular domain object inside the object itself rather than in the global.asax. If you find methods in the Global.asax that shouldn't be there refactor the work into the right location.
global.asax is a HTTPModule. All requests go through the global.asax and other modules before they reach your page handlers. Use this to perform certain tasks on your request or response, like url routing, global error handlign etc.
If you need something special to happen on Application start/end or Session start/end, or globally handle exceptions you could use it to map the events in the Apllication and Session life cycles.
We are using objects that at times need to sync up with the server via
the mx.data.DataService, The problem is in case of explicit method
invocation over the dataservice object we are able to trap the fault
events using the fault handlers.
The problem arises when dataservice is sync'ing the object in
background. In case of a fault event (such as session timeout or
server down) the error is not trapped via the fault handler added on
the dataservice using the addEventListener(FaultEvent.FAULT).
Any suggestions on how to trap the fault events generated via
background sync invocations of the DataService?
Try DataServiceFaultEvent.FAULT instead of FaultEvent.FAULT