[jira] [Resolved] (ARIES-1417) Aries Subsystems implementation bundle must provide official capabilities
[
https://issues.apache.org/jira/browse/ARIES-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Ross resolved ARIES-1417.
--
Resolution: Fixed
Assignee: John Ross
> Aries Subsystems implementation bundle must provide official capabilities
> -
>
> Key: ARIES-1417
> URL: https://issues.apache.org/jira/browse/ARIES-1417
> Project: Aries
> Issue Type: Improvement
> Components: Subsystem
>Affects Versions: subsystem-2.0.6, subsystem-2.0.8
>Reporter: Cristiano Gavião
>Assignee: John Ross
>
> Compendium v6.0.0 states in 134.19 - Capabilities:
> * A capability in the osgi.implementation namespace declaring the implemented
> specification to be osgi.subsystem. This capability must also declare a uses
> constraint for the org.osgi.service.subsystem package. For example:
> {code}
> Provide-Capability: osgi.implementation;
> osgi.implementation="osgi.subsystem";
> version:Version="1.1";
> uses:="org.osgi.service.subsystem"
> {code}
> *This capability must follow the rules defined for the osgi.implementation
> Namespace on page 997.
> * A capability in the osgi.service namespace representing the Subsystem
> service. This capability
> must also declare a uses constraint for the org.osgi.service.subsystem
> package. For example:
> {code}
> Provide-Capability: osgi.service;
> objectClass:List="org.osgi.service.subsystem.Subsystem";
> uses:="org.osgi.service.subsystem"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1417) Aries Subsystems implementation bundle must provide official capabilities
[
https://issues.apache.org/jira/browse/ARIES-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159622#comment-15159622
]
ASF subversion and git services commented on ARIES-1417:
Commit 1731952 from [~jwr...@us.ibm.com] in branch 'aries/trunk'
[ https://svn.apache.org/r1731952 ]
[ARIES-1417] Aries Subsystems implementation bundle must provide official
capabilities
Note that I wasn't able to figure out how to get the new Provide-Capability to
work with aries/parent/pom.xml so I copied the maven-bundle-plugin definition
from
there to subsystem-core.
Plus test.
> Aries Subsystems implementation bundle must provide official capabilities
> -
>
> Key: ARIES-1417
> URL: https://issues.apache.org/jira/browse/ARIES-1417
> Project: Aries
> Issue Type: Improvement
> Components: Subsystem
>Affects Versions: subsystem-2.0.6, subsystem-2.0.8
>Reporter: Cristiano Gavião
>
> Compendium v6.0.0 states in 134.19 - Capabilities:
> * A capability in the osgi.implementation namespace declaring the implemented
> specification to be osgi.subsystem. This capability must also declare a uses
> constraint for the org.osgi.service.subsystem package. For example:
> {code}
> Provide-Capability: osgi.implementation;
> osgi.implementation="osgi.subsystem";
> version:Version="1.1";
> uses:="org.osgi.service.subsystem"
> {code}
> *This capability must follow the rules defined for the osgi.implementation
> Namespace on page 997.
> * A capability in the osgi.service namespace representing the Subsystem
> service. This capability
> must also declare a uses constraint for the org.osgi.service.subsystem
> package. For example:
> {code}
> Provide-Capability: osgi.service;
> objectClass:List="org.osgi.service.subsystem.Subsystem";
> uses:="org.osgi.service.subsystem"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARIES-1383) Provide option to disable the provisioning of dependencies at install time.
[ https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ross resolved ARIES-1383. -- Resolution: Fixed This seems pretty well vetted and complete to me. Any further issues or work should be handled in new JIRAs. > Provide option to disable the provisioning of dependencies at install time. > --- > > Key: ARIES-1383 > URL: https://issues.apache.org/jira/browse/ARIES-1383 > Project: Aries > Issue Type: Improvement > Components: Subsystem >Affects Versions: subsystem-2.0.6, subsystem-2.0.8 >Reporter: John Ross >Assignee: John Ross > Attachments: TEST-org.osgi.test.cases.subsystem-6.0.0.html > > > PROBLEM > - > The Subsystems specification states that all dependencies of a subsystem must > have been installed in order to attain the INSTALLED state. If required > dependencies are not found, the installation must fail. > This functionality was described in order to achieve fail-fast functionality. > If an environment cannot support the dependencies of a subsystem, it is > rejected right away. > However, there are deployment situations where it is valuable to delay the > installation of dependencies. For example, you may wish to independently and > simultaneously install a suite of subsystems whose contents have interleaving > dependencies. This is currently not possible because the local repository of > one subsystem is not available to others. The resources will not be available > to others until they become part of the System Repository (assuming a > compatible sharing policy) once the INSTALLED state is acquired. In the > meantime, the other subsystems fail installation. > There are three potential workarounds to this issue, none of which may be > acceptable to a particular Subsystems consumer. > (1) Provide all content as part of a remote repository. Note that this would > require the Subsystem-Content header to be computed by the subsystem provider > and not by the implementation. > (2) Package all subsystems into a single ESA and make use of parent-child > relationships. > (3) Manage the install order manually. Note that this would not handle the > case of circular dependencies. > A solution that will allow for the independent and simultaneous installation > of multiple subsystems with interleaving content dependencies, thus giving a > deployer more flexibility, is desirable. > PROPOSED SOLUTION > - > A custom directive is introduced: apache-aries-provision-dependencies. The > possible values are "install" and "resolve", which indicate the time at which > dependency provisioning should occur. The default value is "install" which > results in the current behavior. This directive may be specified as part of > the Subsystem-Type header. A value of "resolve" indicates that dependencies > should not be provisioned at installation time. Rather, this step will occur > when the subsystem is resolved which typically happens as part of the start > process. > A subsystem with apache-aries-provision-dependencies:=resolve will remain in > the INSTALLING state until it is started. This is an indication to > administration programs monitoring subsystems via the service registry that > the subsystem has not yet had its dependencies provisioned. When the > subsystem is started, the transition from INSTALLING to INSTALLED will then > occur as it does today. Assuming the provisioning of dependencies succeeds, > the subsystem will then immediately transition into the RESOLVING state and > proceed as normal. > State transitions when apache-aries-provision-dependencies:=start: > install() : -> INSTALLING > -> INSTALLING -> INSTALL_FAILED -> UNINSTALLING > -> UNINSTALLED (if installation fails for some reason other than dependency > provisioning) > start() : INSTALLING -> INSTALLED -> RESOLVING -> RESOLVED -> STARTING > -> ACTIVE >INSTALLING -> INSTALLING (if provisioning of dependencies > fails) > INSTALLING -> INSTALLED -> RESOLVING -> INSTALLED (if > runtime resolution fails) > >INSTALLING -> INSTALLED -> RESOLVING -> RESOLVED -> > STARTING -> RESOLVED (if starting fails) > Child scoped subsystems inherit the apache-aries-provision-dependencies value > of the first scoped ancestor unless explicitly overridden. Unscoped > subsystems always inherit the apache-aries-provision-dependencies value of > the first scoped ancestor and may not override the value. The root subsystem > always has a value of apache-aries-provision-dependencies:=install. > ALTERNATIVE SOLUTIONS > - > (1) Make the local repositories of installing subsystems
[jira] [Resolved] (ARIES-1441) Subsystem core tries to shutdown the framework when it has a framework dependency like org.osgi.util.tracker
[ https://issues.apache.org/jira/browse/ARIES-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ross resolved ARIES-1441. -- Resolution: Fixed Assignee: John Ross > Subsystem core tries to shutdown the framework when it has a framework > dependency like org.osgi.util.tracker > > > Key: ARIES-1441 > URL: https://issues.apache.org/jira/browse/ARIES-1441 > Project: Aries > Issue Type: Bug > Components: Subsystem >Affects Versions: subsystem-2.0.6, subsystem-2.0.8 > Environment: karaf > pax exam >Reporter: Bas >Assignee: John Ross > Labels: patch, test > Attachments: AriesStopSubsystem.java.test.patch, > patch-stop-subsystem.patch > > > When performing a shutdown of the subsystem core bundle it tries to stop the > framework because there is a org.osgi.util.tracker import package. > Also in the same situation described above when trying to shutdown the > framework by calling stop on bundle 0 it can fail with: > [org.apache.aries.subsystem.core.internal.StopAction] : An error occurred > while stopping resource osgi.identity; osgi.identity="org.eclipse.osgi"; > type="osgi.bundle"; version:Version="3.10.0.v20140606-1445"; > singleton:="true" of subsystem > org.apache.aries.subsystem.core.internal.BasicSubsystem@25760667 > org.osgi.framework.BundleException: Unable to acquire the state change lock > for the module: osgi.identity; osgi.identity="org.eclipse.osgi"; > type="osgi.bundle"; version:Version="3.10.0.v20140606-1445"; > singleton:="true" [id=0] STOPPED [STOPPED] invalid > at org.eclipse.osgi.container.Module.lockStateChange(Module.java:329) > at > org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule.asyncStop(EquinoxBundle.java:151) > at > org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle.stop(EquinoxBundle.java:272) > at > org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle.stop(EquinoxBundle.java:277) > at > org.apache.aries.subsystem.core.internal.StopAction.stopBundleResource(StopAction.java:97) > at > org.apache.aries.subsystem.core.internal.StopAction.stopResource(StopAction.java:109) > at > org.apache.aries.subsystem.core.internal.StopAction.run(StopAction.java:67) > at > org.apache.aries.subsystem.core.internal.StopAction.stopSubsystemResource(StopAction.java:135) > at > org.apache.aries.subsystem.core.internal.StopAction.stopResource(StopAction.java:107) > at > org.apache.aries.subsystem.core.internal.StopAction.run(StopAction.java:67) > at > org.apache.aries.subsystem.core.internal.Activator.deactivate(Activator.java:162) > at > org.apache.aries.subsystem.core.internal.Activator.removedService(Activator.java:291) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:967) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:870) > at > org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) > at > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:909) > at > org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:109) > at > org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:914) > at > org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) > at > org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:862) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:801) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:222) > at > org.eclipse.equinox.internal.region.RegionManager.stop(RegionManager.java:67) > at > org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:827) > at > org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:1) > at java.security.AccessController.doPrivileged(Native Method) > at > org.eclipse.osgi.internal.framework.BundleContextImpl.stop(BundleContextImpl.java:820) > at > org.eclipse.osgi.internal.framework.EquinoxBundle.stopWorker0(EquinoxBundle.java:950) > at > org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.stopWorker(EquinoxBundle.java:324) > at org.eclipse.osgi.container.Module.doStop(Module.java:626) > at
[jira] [Commented] (ARIES-1441) Subsystem core tries to shutdown the framework when it has a framework dependency like org.osgi.util.tracker
[ https://issues.apache.org/jira/browse/ARIES-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159461#comment-15159461 ] John Ross commented on ARIES-1441: -- This defect goes to the heart of a question that has persisted since the subsystems specification and implementation were introduced, namely, exactly which bundles fall under the scope of being managed? For these purposes, a "managed bundle" will be defined as one whose full life cycle must be controlled by the implementation, but particularly with regard to stopping and uninstalling. Examples of Managed Bundles (1) Any bundle installed as a consequence of invoking one of the install methods on the Subsystem or AriesSubsystem interfaces. (2) Any bundle installed using the bundle context of a managed bundle. [a] Examples of Unmanaged Bundles [b] (1) The region context bundle of the root subsystem. [c] (2) Any bundle installed using the bundle context of an unmanaged bundle. [d] While the fix provided here handles the immediate issue, there may yet remain inconsistencies between the definition provided here and the actual behavior. Finally, uninstalling the implementation bundle without first uninstalling all subsystems except root is out of scope [c]. This would result in all of the managed bundles as defined here remaining in the framework along with their regions. [a] This includes the region context bundles of all subsystems except root (see (1) under Examples of Unmanaged Bundles). It also includes bundles installed via the Eclipse Equinox Region API using a region created by the implementation. [b] Unmanaged bundles may be resolved and started by the implementation. [c] This exception exists because the region context bundle of the root subsystem cannot be uninstalled by the implementation. Similar to the system bundle, the specification does not define UNINSTALLING and UNINSTALLED state transitions for the root subsystem. Moreover, there is no UNINSTALLING bundle event and therefore no way for a bundle to respond to being uninstalled. [d] This includes bundles installed via the Eclipse Equinox Region API using a region not created by the implementation, including the kernel region. > Subsystem core tries to shutdown the framework when it has a framework > dependency like org.osgi.util.tracker > > > Key: ARIES-1441 > URL: https://issues.apache.org/jira/browse/ARIES-1441 > Project: Aries > Issue Type: Bug > Components: Subsystem >Affects Versions: subsystem-2.0.6, subsystem-2.0.8 > Environment: karaf > pax exam >Reporter: Bas > Labels: patch, test > Attachments: AriesStopSubsystem.java.test.patch, > patch-stop-subsystem.patch > > > When performing a shutdown of the subsystem core bundle it tries to stop the > framework because there is a org.osgi.util.tracker import package. > Also in the same situation described above when trying to shutdown the > framework by calling stop on bundle 0 it can fail with: > [org.apache.aries.subsystem.core.internal.StopAction] : An error occurred > while stopping resource osgi.identity; osgi.identity="org.eclipse.osgi"; > type="osgi.bundle"; version:Version="3.10.0.v20140606-1445"; > singleton:="true" of subsystem > org.apache.aries.subsystem.core.internal.BasicSubsystem@25760667 > org.osgi.framework.BundleException: Unable to acquire the state change lock > for the module: osgi.identity; osgi.identity="org.eclipse.osgi"; > type="osgi.bundle"; version:Version="3.10.0.v20140606-1445"; > singleton:="true" [id=0] STOPPED [STOPPED] invalid > at org.eclipse.osgi.container.Module.lockStateChange(Module.java:329) > at > org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule.asyncStop(EquinoxBundle.java:151) > at > org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle.stop(EquinoxBundle.java:272) > at > org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle.stop(EquinoxBundle.java:277) > at > org.apache.aries.subsystem.core.internal.StopAction.stopBundleResource(StopAction.java:97) > at > org.apache.aries.subsystem.core.internal.StopAction.stopResource(StopAction.java:109) > at > org.apache.aries.subsystem.core.internal.StopAction.run(StopAction.java:67) > at > org.apache.aries.subsystem.core.internal.StopAction.stopSubsystemResource(StopAction.java:135) > at > org.apache.aries.subsystem.core.internal.StopAction.stopResource(StopAction.java:107) > at > org.apache.aries.subsystem.core.internal.StopAction.run(StopAction.java:67) > at > org.apache.aries.subsystem.core.internal.Activator.deactivate(Activator.java:162) > at >
[jira] [Commented] (ARIES-1441) Subsystem core tries to shutdown the framework when it has a framework dependency like org.osgi.util.tracker
[ https://issues.apache.org/jira/browse/ARIES-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159394#comment-15159394 ] ASF subversion and git services commented on ARIES-1441: Commit 1731925 from [~jwr...@us.ibm.com] in branch 'aries/trunk' [ https://svn.apache.org/r1731925 ] [ARIES-1441] Subsystem core tries to shutdown the framework when it has a framework dependency like org.osgi.util.tracker I chose to take a different approach than in the patch. Bundles that are constituents of root will now automatically receive an active use count increment when the subsystem being acted upon is root. This will prevent them from being stopped or uninstalled. This does not affect dependencies that were provisioned to root in support of child subsystems. These are managed by the child subsystems themselves. Plus test. > Subsystem core tries to shutdown the framework when it has a framework > dependency like org.osgi.util.tracker > > > Key: ARIES-1441 > URL: https://issues.apache.org/jira/browse/ARIES-1441 > Project: Aries > Issue Type: Bug > Components: Subsystem >Affects Versions: subsystem-2.0.6, subsystem-2.0.8 > Environment: karaf > pax exam >Reporter: Bas > Labels: patch, test > Attachments: AriesStopSubsystem.java.test.patch, > patch-stop-subsystem.patch > > > When performing a shutdown of the subsystem core bundle it tries to stop the > framework because there is a org.osgi.util.tracker import package. > Also in the same situation described above when trying to shutdown the > framework by calling stop on bundle 0 it can fail with: > [org.apache.aries.subsystem.core.internal.StopAction] : An error occurred > while stopping resource osgi.identity; osgi.identity="org.eclipse.osgi"; > type="osgi.bundle"; version:Version="3.10.0.v20140606-1445"; > singleton:="true" of subsystem > org.apache.aries.subsystem.core.internal.BasicSubsystem@25760667 > org.osgi.framework.BundleException: Unable to acquire the state change lock > for the module: osgi.identity; osgi.identity="org.eclipse.osgi"; > type="osgi.bundle"; version:Version="3.10.0.v20140606-1445"; > singleton:="true" [id=0] STOPPED [STOPPED] invalid > at org.eclipse.osgi.container.Module.lockStateChange(Module.java:329) > at > org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule.asyncStop(EquinoxBundle.java:151) > at > org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle.stop(EquinoxBundle.java:272) > at > org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle.stop(EquinoxBundle.java:277) > at > org.apache.aries.subsystem.core.internal.StopAction.stopBundleResource(StopAction.java:97) > at > org.apache.aries.subsystem.core.internal.StopAction.stopResource(StopAction.java:109) > at > org.apache.aries.subsystem.core.internal.StopAction.run(StopAction.java:67) > at > org.apache.aries.subsystem.core.internal.StopAction.stopSubsystemResource(StopAction.java:135) > at > org.apache.aries.subsystem.core.internal.StopAction.stopResource(StopAction.java:107) > at > org.apache.aries.subsystem.core.internal.StopAction.run(StopAction.java:67) > at > org.apache.aries.subsystem.core.internal.Activator.deactivate(Activator.java:162) > at > org.apache.aries.subsystem.core.internal.Activator.removedService(Activator.java:291) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:967) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:870) > at > org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) > at > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:909) > at > org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:109) > at > org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:914) > at > org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) > at > org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:862) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:801) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:222) > at > org.eclipse.equinox.internal.region.RegionManager.stop(RegionManager.java:67) > at >
[jira] [Commented] (ARIES-1441) Subsystem core tries to shutdown the framework when it has a framework dependency like org.osgi.util.tracker
[ https://issues.apache.org/jira/browse/ARIES-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159117#comment-15159117 ] John Ross commented on ARIES-1441: -- Starting the subsystem is necessary for the following reason. When the subsystems implementation bundle is stopped, a deactivation occurs. As part of the deactivation, the root subsystem is stopped. As part of stopping the root subsystem, the child subsystem is stopped. Because the child subsystem references the bundle providing the necessary package, the bundle is stopped, The issue does not occur if the subsystem is not started because (1) there is no child subsystem to stop, and (2) protection against stopping unmanaged bundles is already provided by line 147 of StartAction when stopping the root subsystem. > Subsystem core tries to shutdown the framework when it has a framework > dependency like org.osgi.util.tracker > > > Key: ARIES-1441 > URL: https://issues.apache.org/jira/browse/ARIES-1441 > Project: Aries > Issue Type: Bug > Components: Subsystem >Affects Versions: subsystem-2.0.6, subsystem-2.0.8 > Environment: karaf > pax exam >Reporter: Bas > Labels: patch, test > Attachments: AriesStopSubsystem.java.test.patch, > patch-stop-subsystem.patch > > > When performing a shutdown of the subsystem core bundle it tries to stop the > framework because there is a org.osgi.util.tracker import package. > Also in the same situation described above when trying to shutdown the > framework by calling stop on bundle 0 it can fail with: > [org.apache.aries.subsystem.core.internal.StopAction] : An error occurred > while stopping resource osgi.identity; osgi.identity="org.eclipse.osgi"; > type="osgi.bundle"; version:Version="3.10.0.v20140606-1445"; > singleton:="true" of subsystem > org.apache.aries.subsystem.core.internal.BasicSubsystem@25760667 > org.osgi.framework.BundleException: Unable to acquire the state change lock > for the module: osgi.identity; osgi.identity="org.eclipse.osgi"; > type="osgi.bundle"; version:Version="3.10.0.v20140606-1445"; > singleton:="true" [id=0] STOPPED [STOPPED] invalid > at org.eclipse.osgi.container.Module.lockStateChange(Module.java:329) > at > org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule.asyncStop(EquinoxBundle.java:151) > at > org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle.stop(EquinoxBundle.java:272) > at > org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle.stop(EquinoxBundle.java:277) > at > org.apache.aries.subsystem.core.internal.StopAction.stopBundleResource(StopAction.java:97) > at > org.apache.aries.subsystem.core.internal.StopAction.stopResource(StopAction.java:109) > at > org.apache.aries.subsystem.core.internal.StopAction.run(StopAction.java:67) > at > org.apache.aries.subsystem.core.internal.StopAction.stopSubsystemResource(StopAction.java:135) > at > org.apache.aries.subsystem.core.internal.StopAction.stopResource(StopAction.java:107) > at > org.apache.aries.subsystem.core.internal.StopAction.run(StopAction.java:67) > at > org.apache.aries.subsystem.core.internal.Activator.deactivate(Activator.java:162) > at > org.apache.aries.subsystem.core.internal.Activator.removedService(Activator.java:291) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:967) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:870) > at > org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) > at > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:909) > at > org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:109) > at > org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:914) > at > org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) > at > org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:862) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:801) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:222) > at > org.eclipse.equinox.internal.region.RegionManager.stop(RegionManager.java:67) > at >
[jira] [Commented] (ARIES-1441) Subsystem core tries to shutdown the framework when it has a framework dependency like org.osgi.util.tracker
[ https://issues.apache.org/jira/browse/ARIES-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15158811#comment-15158811 ] John Ross commented on ARIES-1441: -- This issue can be reproduced simply by the following. (1) Install an application, composite, or feature containing a single bundle with a single package import as a child of the root subsystem. (2) Start the subsystem. (3) Stop the subsystems implementation bundle. The value of the package import does not appear to matter as long as it's provided by a root subsystem bundle that should not be managed (e.g., a bundle that pre-existed the initialization of the root subsystem). > Subsystem core tries to shutdown the framework when it has a framework > dependency like org.osgi.util.tracker > > > Key: ARIES-1441 > URL: https://issues.apache.org/jira/browse/ARIES-1441 > Project: Aries > Issue Type: Bug > Components: Subsystem >Affects Versions: subsystem-2.0.6, subsystem-2.0.8 > Environment: karaf > pax exam >Reporter: Bas > Labels: patch, test > Attachments: AriesStopSubsystem.java.test.patch, > patch-stop-subsystem.patch > > > When performing a shutdown of the subsystem core bundle it tries to stop the > framework because there is a org.osgi.util.tracker import package. > Also in the same situation described above when trying to shutdown the > framework by calling stop on bundle 0 it can fail with: > [org.apache.aries.subsystem.core.internal.StopAction] : An error occurred > while stopping resource osgi.identity; osgi.identity="org.eclipse.osgi"; > type="osgi.bundle"; version:Version="3.10.0.v20140606-1445"; > singleton:="true" of subsystem > org.apache.aries.subsystem.core.internal.BasicSubsystem@25760667 > org.osgi.framework.BundleException: Unable to acquire the state change lock > for the module: osgi.identity; osgi.identity="org.eclipse.osgi"; > type="osgi.bundle"; version:Version="3.10.0.v20140606-1445"; > singleton:="true" [id=0] STOPPED [STOPPED] invalid > at org.eclipse.osgi.container.Module.lockStateChange(Module.java:329) > at > org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule.asyncStop(EquinoxBundle.java:151) > at > org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle.stop(EquinoxBundle.java:272) > at > org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle.stop(EquinoxBundle.java:277) > at > org.apache.aries.subsystem.core.internal.StopAction.stopBundleResource(StopAction.java:97) > at > org.apache.aries.subsystem.core.internal.StopAction.stopResource(StopAction.java:109) > at > org.apache.aries.subsystem.core.internal.StopAction.run(StopAction.java:67) > at > org.apache.aries.subsystem.core.internal.StopAction.stopSubsystemResource(StopAction.java:135) > at > org.apache.aries.subsystem.core.internal.StopAction.stopResource(StopAction.java:107) > at > org.apache.aries.subsystem.core.internal.StopAction.run(StopAction.java:67) > at > org.apache.aries.subsystem.core.internal.Activator.deactivate(Activator.java:162) > at > org.apache.aries.subsystem.core.internal.Activator.removedService(Activator.java:291) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:967) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:870) > at > org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) > at > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:909) > at > org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:109) > at > org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:914) > at > org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) > at > org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:862) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:801) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:222) > at > org.eclipse.equinox.internal.region.RegionManager.stop(RegionManager.java:67) > at > org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:827) > at > org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:1) > at
[jira] [Commented] (ARIES-1490) The esa maven plugin provides more flexibility when creating the subsystem manifest
[ https://issues.apache.org/jira/browse/ARIES-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15158786#comment-15158786 ] John Ross commented on ARIES-1490: -- I don't see anything wrong with the tooling providing an option to include all computed dependencies as content. I would personally vote for today's behavior remaining as the default, however, because I suspect that will be the more common desire, and it's consistent with the specification which allows dependencies in addition to content to be packaged in the archive. > The esa maven plugin provides more flexibility when creating the subsystem > manifest > --- > > Key: ARIES-1490 > URL: https://issues.apache.org/jira/browse/ARIES-1490 > Project: Aries > Issue Type: New Feature > Components: ESA Maven Plugin >Affects Versions: esa-maven-plugin-1.0.0 >Reporter: Wouter Bancken > > When determining which dependencies are included in the archive, the ESA > maven plugin provides different possibilities as to which dependencies are > included (transitive dependencies vs only direct dependencies). > When generating the subsystem manifest, the plugin always decides to only > list the direct dependencies and therefore it does not include the transitive > dependencies as part of the subsystem content even though they are present in > the archive. > Additionally, the type of the dependencies (e.g. 'pom') is not taken into > account. This makes it impossible to extract a sequence of related > dependencies into a separate pom file to improve the overall readability. The > readability would improve greatly if a related set of dependencies could be > imported from another pom. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1490) The esa maven plugin provides more flexibility when creating the subsystem manifest
[ https://issues.apache.org/jira/browse/ARIES-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15158555#comment-15158555 ] Tom De Wolf commented on ARIES-1490: Also, when we use the maven dependency tree to include an extender bundle (e.g. blueprint extender) then there is no bundle having a direct Import-Package requirement on that bundle and it will not even get installed while we do want it there. For those bundles we now only have the option to list them separately. So an option 'includeDependenciesInSubsystemContentHeader' would be nice. > The esa maven plugin provides more flexibility when creating the subsystem > manifest > --- > > Key: ARIES-1490 > URL: https://issues.apache.org/jira/browse/ARIES-1490 > Project: Aries > Issue Type: New Feature > Components: ESA Maven Plugin >Affects Versions: esa-maven-plugin-1.0.0 >Reporter: Wouter Bancken > > When determining which dependencies are included in the archive, the ESA > maven plugin provides different possibilities as to which dependencies are > included (transitive dependencies vs only direct dependencies). > When generating the subsystem manifest, the plugin always decides to only > list the direct dependencies and therefore it does not include the transitive > dependencies as part of the subsystem content even though they are present in > the archive. > Additionally, the type of the dependencies (e.g. 'pom') is not taken into > account. This makes it impossible to extract a sequence of related > dependencies into a separate pom file to improve the overall readability. The > readability would improve greatly if a related set of dependencies could be > imported from another pom. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1490) The esa maven plugin provides more flexibility when creating the subsystem manifest
[ https://issues.apache.org/jira/browse/ARIES-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15158534#comment-15158534 ] Tom De Wolf commented on ARIES-1490: Yes, your understanding is correct. We do not want to list all dependencies individually and thus rely on the fact that the esa plugin uses the maven dependency tree to include the transitive dependencies. However, for us they are actual content of the esa subsystem so we would like to mark them as such by including them in the Subsystem-Content header without having to list them again. To structure a big project we also like to use external pom.xml files including a list of dependencies and having the esa plugin able to cope with that would easy the use of the plugin for bigger projects too. Also being able to influence the start order is sometimes needed. It is very confusing that the content specified in the header is out of sync with the content that is actually in the esa. Why make the difference? What would be wrong to at least add all bundles included in the esa archive also to the manifest Subsystem-Content header? Sounds more consistent. > The esa maven plugin provides more flexibility when creating the subsystem > manifest > --- > > Key: ARIES-1490 > URL: https://issues.apache.org/jira/browse/ARIES-1490 > Project: Aries > Issue Type: New Feature > Components: ESA Maven Plugin >Affects Versions: esa-maven-plugin-1.0.0 >Reporter: Wouter Bancken > > When determining which dependencies are included in the archive, the ESA > maven plugin provides different possibilities as to which dependencies are > included (transitive dependencies vs only direct dependencies). > When generating the subsystem manifest, the plugin always decides to only > list the direct dependencies and therefore it does not include the transitive > dependencies as part of the subsystem content even though they are present in > the archive. > Additionally, the type of the dependencies (e.g. 'pom') is not taken into > account. This makes it impossible to extract a sequence of related > dependencies into a separate pom file to improve the overall readability. The > readability would improve greatly if a related set of dependencies could be > imported from another pom. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
