On 10/5/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hubert Rabago <[EMAIL PROTECTED]> wrote on 10/05/2005 02:27:59 PM: > > > For your case, initializing an app-wide collection, consider using a > > ServletContextListener. Even in Struts, this would be recommended for > > containers that support it. > > oh ok I actually know how to do that..;)) Btw, is there some secret reason > why a listener is better than a plugin..? :)
A listener is the right answer to meeting this need. As to the second question, consider a little bit of history for a moment. Why does Struts have a plugin architecture in the first place? The answer is that Struts 1.xwas originally designed to run on top of Servlet 2.2, which does not have listeners (or even filters). Yet, it was clear that application startup and shutdown events were a usefu thing to have. (Technically, plugins actually have a risk that listeners don't that you should be aware of. They are implemented by being called from the init() and destroy() methods of ActionServlet. The risk is that a servlet container is perfectly free to take an already initialized servlet out of service, causing the shutdown listeners to be called, even if the application is still deployed -- which means you might end up paying the initialization price again on the next request to that servlet. The ServletContextListener is guaranteed to be called once at app startup time, and once at app shutdown time, only.) Further, there is more than just ServletContextListener (the equivalent of a Struts PlugIn) available. Consider listeners that implement the following: * ServletContextAttributeListener - you get notified any time an application scope attribute is added, replaced, or removed * HttpSessionListener - you get notified when sessions are created or destroyed * HttpSessionAttributeListener - you get notified when a session scope attribute is added, replaced, or removed * ServletRequestListener - you get notified when a request starts or stops * ServletRequestAttributeListener - you get notified when a request scope attribute is added, replaced, or removed > > > Hubert > > > > (Can this count as my first answer to a [shale] question? No? Aww.) > > Thanks! (and if you answer this question too, it counts...;)) > Geeta > > There's another message that I'd like to get across here as well. One of the key reasons that Shale is so small is that it does *not* try to redundantly implement features supported by the base platform. That's why there is no "Shale PlugIn" or "Shale Container Managed Security" or things like that. The underlying platform facilities work just fine, and are recommended for use. Craig
