[jboss-as7-dev] Undeploy due to server shutdown vs. explicit undeploy operation

[Thomas Diesler]

The general use case is that a subsystem maintains state (on behalf of a 
deployment) that should be removed on explicit user interaction (i.e. 
mgmt op) but not on subsystem/server shutdown. This should also work in 
the domain case. Perhaps the ApplicationServerService (or similar) could 
be queried about whether it is currently shutting down.

--thomas

On 11/16/2012 11:07 AM, Jaikiran Pai wrote:
> On Friday 16 November 2012 03:30 PM, Thomas Diesler wrote:
>> An OSGi bundle has a persistent storage area (see 
>> standalone/data/osgi-store). When a bundle gets uninstalled the 
>> persistent storage is supposed to get removed. 
> Is the bundle uninstall a management operation? IMO, clearing the 
> storage area should perhaps be outside of the DUPs, so that the 
> undeploy just functions the same irrespective of whether it's a 
> undeploy or shutdown.
>
> -Jaikiran
>> On server shutdown we also undeploy every bundle. In this case 
>> however I don't want to remove the bundle's storage area.
>>
>> Currently, we never remove the storage area 
>> (https://issues.jboss.org/browse/AS7-5948).
>>
>> On 11/16/2012 10:52 AM, Jaikiran Pai wrote:
>>> Hi Thomas,
>>>
>>> What kind of a state is it and where do you maintain that state? Also,
>>> what's the use case that requires this behaviour? That might help us
>>> understand this a bit better.
>>>
>>> -Jaikiran
>>>
>>> On Friday 16 November 2012 03:16 PM, Thomas Diesler wrote:
>>>> Folks,
>>>>
>>>> an explicit undeploy operation should remove state that otherwise 
>>>> needs
>>>> to survive server restart.
>>>> How can I distinguish between these two cases in a DUP?
>>>>
>>>> cheers
>>>> --thomas
>>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>

-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx