aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Flynn (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ARIES-1084) Subsystem : Failure on restart after framework crash
Date Fri, 21 Jun 2013 12:54:20 GMT

     [ https://issues.apache.org/jira/browse/ARIES-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Stephen Flynn updated ARIES-1084:
---------------------------------

    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.


  was:
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.


    
> 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

Mime
View raw message