Stephen Flynn created ARIES-1084:
------------------------------------
Summary: Subsystem : Failure on restart after framework crash
Key: ARIES-1084
URL: https://issues.apache.org/jira/browse/ARIES-1084
Project: Aries
Issue Type: Bug
Components: Subsystem
Environment: Windows 7
Java 1.6.0_31
OSGi environment...
org.eclipse.osgi 3.8.2.v20130124-134944
slf4j.api 1.7.5
slf4j.simple 1.7.5
org.eclipse.equinox.region 1.1.0.v20120522-1841
org.eclipse.equinox.coordinator 1.1.0.v20120522-1841
org.apache.aries.util 1.1.0
org.apache.aries.proxy 1.0.1
org.apache.aries.blueprint 1.0.0
org.apache.aries.application.api 1.0.0
org.apache.aries.application.modeller 1.0.0
org.apache.aries.application.utils 1.0.0
org.apache.felix.resolver 1.0.0
org.apache.felix.bundlerepository 1.6.6
org.apache.aries.subsystem 1.0.0
Reporter: Stephen Flynn
Situation : I set up OSGi framework, installed Aries subsystem (and all
required bundles), installed a single trivial feature subsystem containing a
single bundle resource. All worked as expected in normal operation with
install/start/stop/uninstall operations working as described in section 134.14
of the OSGi Enterprise Release 5 spec. Starting and stopping the framework
started and stopped installed subsystem's bundle as expected.
Problem : When the framework is not closed down gracefully (say JVM crash) the
subsystem's bundle does not restart. The proximate cause of this appears to be
that...
The state for each subsystem is persisted in the DEPLOYMENT.MF file, under
the header "AriesSubsystem-State", stored in the Aries subsystem bundle's data
storage area.
The state is changed between RESOLVED and ACTIVE (and back again) as the
bundle is started and stopped in a gracefully way.
A JVM crash leaves the "AriesSubsystem-State" value in the file as ACTIVE
for both root and installed subsystem.
Upon restart the my feature subsystem's resource bundle is no longer
started as Aries (presumably) assumes it is already ACTIVE.
I'm fairly sure that the "AriesSubsystem-State" header is causing the problem
because hand editing it in both root and installed DEPLOYMENT.MF files back to
'RESOLVED' prior to starting the framework solves the problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
