[ARIES-1084] Subsystem : Failure on restart after framework crash

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: subsystem-core-2.0.4, subsystem-bundle-2.0.4
• Component/s: 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

• Assignee: John Ross
• Reporter: Stephen Flynn
• Created: 21/Jun/13 12:51
• Updated: 22/Oct/15 12:23
• Resolved: 22/Oct/15 12:23

Description

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.

Issue Links

• blocks: ARIES-1377 Subsystems 2.0.4 Release