Hi,

I just answered to your comment in the JIRA:

So you're saying it would be better not to destroy all session beans on a
container shutdown, because they are maybe serialized? Then what about a
config parameter to turn this feature on or off?

And what about view and request beans?

Regards,
Jakob

2010/1/14 Bernhard Huemer <bernhard.hue...@gmail.com>

> Hey,
>
> sorry, I haven't noticed this thread, so I've already commented on the
> according JIRA issue (https://issues.apache.org/jira/browse/MYFACES-2485).
> Basically I've already mentioned it there, but I think the reason why only
> the "contextDestroyed"-callbacks are invoked is that Tomcat, by default,
> serializes and preserves sessions once it shuts down.
>
> However, I'm pretty much sure that implementing such a registry introduces
> more issues than it resolves (assuming that you consider this to be an issue
> at all - which I wouldn't do). As Jan-Kees has already pointed out, you
> can't just invalidate sessions once a container shuts down in a clustered
> environment. I think it would break the whole idea of a clustered
> environment.
>
> regards,
> Bernhard
>
> Jakob Korherr wrote on 01/13/2010 09:17 PM (GMT):
>
>> Hi,
>>
>> MyFaces is already using all available Listeners
>> (HttpSessionAttributeListener, HttpSessionListener, ServletContextListener,
>> ServletContextAttributeListener, ServletRequestListener,
>> ServletRequestAttributeListener) to invoke @PreDestroy on the Managed Beans
>> and this happens via a pass-through from StartupServletContextListener, so
>> you don't have to configure two listeners in web.xml (or tld).
>>
>> The problem is, as you thought, that those listeners (e.g.
>> HttpSessionListener) are not invoked on a container shutdown/restart. Only
>> contextDestroyed from ServletContextListener is invoked (tested today on
>> Apache Tomcat 6).
>>
>> I will not change anything of the existing behavior, I just want to make
>> sure that all still existing ManagedBeans get their @PreDestroy method
>> called in contextDestroyed. But I would not get a reference to them, if I do
>> not register them in a ManagedBeanRegistry.
>>
>> Regards,
>> Jakob
>>
>> 2010/1/13 Jan-Kees van Andel <jankeesvanan...@gmail.com <mailto:
>> jankeesvanan...@gmail.com>>
>>
>>
>>    Hey,
>>
>>    How about an HttpSessionListener? I'm not sure if
>>    HttpSessionListener.contextDestroyed is invoked on shutdownthough.
>>    Probably not...
>>
>>    I'm afraid the only option is custom bookkeeping, maybe using an
>>    HttpSessionListener/ServletContextListener to publish events to the
>>    Registry.
>>    I see some issues with this approach:
>>    1 Configuration becomes more difficult for the application developer,
>>    because these two Listeners become required configuration.
>>    2 Managing objects yourself may be tricky business. An option could be
>>    to use WeakReference/WeakHashMap for this so you don't accidentally
>>    keep your objects alive.
>>    3 What to do with regards to session replication on a clustered
>>    environment? I'm not sure this will become an issue, but it wouldn't
>>    surprise me if it will.
>>
>>    Regards,
>>    Jan-Kees
>>
>>
>>    2010/1/13 Jakob Korherr <jakob.korh...@gmail.com
>>    <mailto:jakob.korh...@gmail.com>>:
>>
>>     > Hi guys,
>>     >
>>     > To ensure the execution of the ManagedBean's @PreDestroy methods on
>> a
>>     > container shutdown/restart, I would like to introduce a
>>    ManagedBeanRegistry,
>>     > in which all active ManagedBeans from all scopes are referenced.
>>     >
>>     > The problem is the following: At the moment on a container
>>    shutdown or
>>     > restart, only contextDestroyed is invoked (tested in tomcat 6),
>>    thus only
>>     > the @PreDestroy methods of all ApplicationScoped ManagedBeans will
>> be
>>     > invoked, but not those of any existing ManagedBeans in session,
>>    request,
>>     > view (and maybe also custom) scope, because they can not be
>>    referenced in
>>     > contextDestroyed().
>>     >
>>     > Any opinions on that?
>>     >
>>     > Thanks in advance!
>>     >
>>     > Regards,
>>     > Jakob
>>     >
>>
>>
>>
>

Reply via email to