Re: [VOTE] Subsystem Gogo Command 1.0.0

[davidb]

We have received 3 binding +1s so this vote passes.

I've promoted the artifacts.

David

On 1 October 2015 at 09:53,   wrote:
> Hi all,
>
> I'm calling a vote on the first release of the Aries Subsystem Gogo
> command bundle. This bundle adds some Gogo commands to manage OSGi
> subsystems as described in
> http://aries.apache.org/modules/subsystems.html.
>
> It's a very humble bundle (it only contains 1 class) but I think it
> would be good to have a released version since it makes it easier to
> work with OSGi subsystems from the Gogo shell.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachearies-1042
>
> Please vote:
>
>  +1 Approve the release
>  -1 Do not approve the release (please explain why)
>
> This vote will be open for at least 72 hours.
>
> Best regards,
>
> David Bosschaert

[jira] [Updated] (ARIES-1399) Trunk fails OSGi R6 CT

[John Ross (JIRA)]

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

John Ross updated ARIES-1399:
-
Fix Version/s: subsystem-2.0.4

> Trunk fails OSGi R6 CT
> --
>
> Key: ARIES-1399
> URL: https://issues.apache.org/jira/browse/ARIES-1399
> Project: Aries
>  Issue Type: Bug
>Reporter: John Ross
>Assignee: John Ross
> Fix For: subsystem-2.0.4
>
> Attachments: TEST-org.osgi.test.cases.subsystem-6.0.0.html, 
> TEST-org.osgi.test.cases.subsystem-6.0.0.html
>
>
> The Subsystems implementation is currently failing three tests in the R6 CT 
> as a result of some of the recent performance tunings:
> org.osgi.test.cases.subsystem.junit.SharingPolicySubsystemTests.test3A1a_BundleIsolationApplication
> org.osgi.test.cases.subsystem.junit.SharingPolicySubsystemTests.test3A1b_BundleIsolationFeatures
> org.osgi.test.cases.subsystem.junit.SharingPolicySubsystemTests.test3A1a_BundleIsolationComposite
> It fails all three for the same reason. The tests explicitly install a bundle 
> using the region bundle context of the root subsystem. The bundle is 
> subsequently started. Using a synchronous bundle listener, the tests 
> reasonably expect to see INSTALLED, RESOLVED, STARTING, and ACTIVE bundle 
> events. However, the RESOLVED event is missing. It is missing because:
> (1) The Bundle Event Hook, registered with a service ranking of 
> Integer.MAX_VALUE, correctly identifies the event as pertaining to an 
> explicitly installed bundle and acts accordingly.
> (2) As normal, the bundle is wrapped by a Bundle Revision Resource in order 
> to compute the service capabilities and requirements if the Application 
> Modeller service is present. Previously, the capabilities and requirements 
> were not cached but (lazily) computed with each request. Today, they are 
> computed once and cached at instantiation.
> (3) Computing the service capabilities and requirements requires searching 
> for Blueprint XML files through Bundle.findEntries which results in the 
> framework attempting to resolve the bundle.
> (4) Region Digraph, through its own bundle event hook, receives the RESOLVED 
> event before the INSTALLED event. Because this is an unknown bundle, the 
> event is filtered and not delivered to any listeners, synchronous or 
> otherwise.
> There are at least a few possible solutions to the problem.
> (1) Have the Bundle Event Hook explicitly add the bundle to the region using 
> Region.addBundle(Bundle) as part of handling the INSTALLED event. This would 
> (+) solve the immediate issue but (-) promote out of order event delivery to 
> other hooks and listeners.
> (2) Prevent bundles under these circumstances from resolving altogether. This 
> would (+) solve the immediate issue and (+) prevent out of order event 
> delivery, but (-) eliminate the possibility of searching fragment bundles for 
> Blueprint XML files. 
> (3) Lazily compute service dependencies and requirements in Bundle Revision 
> Resource as before but still cache them. This would (+) solve the immediate 
> issue, (+) resemble how things already were before performance tuning, (+) 
> not contribute to out of order event delivery, and (+) leave open the 
> possibility of searching fragments for Blueprint XML files.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1408) The RequireCapabilityHeader currently only supports requirements defined by the Aries implementation

[John Ross (JIRA)]

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

John Ross updated ARIES-1408:
-
Fix Version/s: (was: subsystem-2.0.3)
   subsystem-2.0.4

> The RequireCapabilityHeader currently only supports requirements defined by 
> the Aries implementation
> 
>
> Key: ARIES-1408
> URL: https://issues.apache.org/jira/browse/ARIES-1408
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.2
>Reporter: Wouter Bancken
>Assignee: John Ross
> Fix For: subsystem-2.0.4
>
>
> The RequireCapabilityHeader currently only supports requirements defined by 
> the Aries implementation and it does not allow any custom Requirement 
> subclasses.
> This is caused by the following if statement:
> !(requirement instanceof RequireCapabilityRequirement 
> || requirement instanceof OsgiExecutionEnvironmentRequirement)
> This statement was introduced to tackle the issues concerning the equals and 
> hashcode methods in ARIES-1387. A better solution to this issue would be to 
> use the equality specifications from the specs to determine equality of 
> clauses. 
> Additionally the current instanceof comparison only supports 
> RequireCapabilityRequirement and OsgiExecutionEnvironmentRequirement classes 
> from the aries classloader. IllegalArgumentExceptions will be thrown when 
> using a RequireCapabilityRequirement originating from a different classloader.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1404) Restart of the osgi container does not restart subsystem core because of an error related to missing resource org.apache.aries.subsystem.resource.synthesized

[John Ross (JIRA)]

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

John Ross updated ARIES-1404:
-
Fix Version/s: subsystem-2.0.4

> Restart of the osgi container does not restart subsystem core because of an 
> error related to missing resource 
> org.apache.aries.subsystem.resource.synthesized
> -
>
> Key: ARIES-1404
> URL: https://issues.apache.org/jira/browse/ARIES-1404
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.3
> Environment: On karaf 4 with subsystem-2.0.3-SNAPSHOT revision 1702099
>Reporter: Bas
>Assignee: John Ross
>  Labels: patch
> Fix For: subsystem-2.0.4
>
> Attachments: ProvisionResourceSynthesized.patch, 
> provision-resource-synth.zip, synthesized.patch
>
>
> Restart of the osgi container does not restart subsystem core because of an 
> error related to missing resource 
> org.apache.aries.subsystem.resource.synthesized
> The deployment manifest contains the entry below in the provision-resource 
> header:
> org.apache.aries.subsystem.resource.synthesized;resourceId=-1;deployed-version=0.0.0;type=org.apache.aries.subsystem.resource.synthesized
> On restart it tries to load the resource because it is in the deployment 
> manifest and can't find the resource in the osgi framework. 
> It seems the 'synthesized' type is related to something which looks like a 
> missing capability/service capability placeholder while installing/resolving. 
> It is not installed because the ResourceInstaller has an if statement 
> returning an installer which does nothing. So I guess it should also not be 
> added to the manifest.
> I therefore patched the ProvisionResourceHeader to check for this 
> 'synthesized' type and ignore it for the Provision-resource header. I'm not 
> sure if this is the best solution but it does solve the issue we are having.
> The reason for patching it there is because it would be least affecting the 
> entire process. Just like ignoring it before it is installed in the osgi 
> framework it will not also be ignored before adding it to the manifest.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Subsystem Gogo Command 1.0.0

[Jean-Baptiste Onofré]

+1

Regards
JB

On 10/01/2015 10:53 AM, dav...@apache.org wrote:

Hi all,

I'm calling a vote on the first release of the Aries Subsystem Gogo
command bundle. This bundle adds some Gogo commands to manage OSGi
subsystems as described in
http://aries.apache.org/modules/subsystems.html.

It's a very humble bundle (it only contains 1 class) but I think it
would be good to have a released version since it makes it easier to
work with OSGi subsystems from the Gogo shell.

Staging repository:
https://repository.apache.org/content/repositories/orgapachearies-1042

Please vote:

  +1 Approve the release
  -1 Do not approve the release (please explain why)

This vote will be open for at least 72 hours.

Best regards,

David Bosschaert



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

[jira] [Updated] (ARIES-1410) The FelixResourceAdapter does not return all capabilities when given a null namespace.

[John Ross (JIRA)]

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

John Ross updated ARIES-1410:
-
Fix Version/s: subsystem-obr-1.0.4

> The FelixResourceAdapter does not return all capabilities when given a null 
> namespace.
> --
>
> Key: ARIES-1410
> URL: https://issues.apache.org/jira/browse/ARIES-1410
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.2
>Reporter: John Ross
>Assignee: John Ross
> Fix For: subsystem-obr-1.0.4
>
> Attachments: FelixResourceAdapter.patch
>
>
> This is a bug spawned from ARIES-1357, specifically from a group of comments 
> starting with 
> https://issues.apache.org/jira/browse/ARIES-1357?focusedCommentId=14743649=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14743649.
> The adapter responsible for adapting 
> org.apache.felix.bundlerepository.Resource into org.osgi.resource.Resource 
> does not return all capabilities given a null namespace as required by the 
> org.osgi.resource.Resource interface.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1235) Installation of a Subsystem containing Subsystems extremely slow

[John Ross (JIRA)]

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

John Ross updated ARIES-1235:
-
Fix Version/s: subsystem-2.0.4

> Installation of a Subsystem containing Subsystems extremely slow
> 
>
> Key: ARIES-1235
> URL: https://issues.apache.org/jira/browse/ARIES-1235
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-1.0.1
> Environment: Eclipse Equinox 3.9.1, Apache Aries Blueprint 1.1.0
>Reporter: Martin Petzold
>Assignee: John Ross
>  Labels: performance
> Fix For: subsystem-2.0.4
>
>
> If I install a subsystem X containing other subystems (S1..Sn) each 
> containing several bundles, one of them containing b>25 bundles, installation 
> of the subsystem is extremely slow (e.g. 1h). If I install all subsystemn 
> S1..Sn "by hand" individually speed is rather okay (e.g. 2 min.). I can't 
> figure out the exact reason. It could of course be about the resolving 
> mechanism. However, it seems that nested subsystems currently can't be 
> handled because performance is far from acceptable.
> Notice: Nested subsystems (in X) as well as nested bundles (in S1..Sn) are 
> wrapped as content of the archive, no OSGi repository implementation used. X 
> and the one containing b>25 bundles are feature subsystems.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1084) Subsystem : Failure on restart after framework crash

[John Ross (JIRA)]

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

John Ross updated ARIES-1084:
-
Fix Version/s: subsystem-2.0.4

> 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
>Assignee: John Ross
> Fix For: subsystem-2.0.4
>
>
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1423) IllegalArgumentException when GenericHeader has no clauses

[John Ross (JIRA)]

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

John Ross updated ARIES-1423:
-
Fix Version/s: subsystem-2.0.4

> IllegalArgumentException when GenericHeader has no clauses
> --
>
> Key: ARIES-1423
> URL: https://issues.apache.org/jira/browse/ARIES-1423
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.3
>Reporter: Wouter Bancken
>Assignee: John Ross
> Fix For: subsystem-2.0.4
>
> Attachments: MANIFEST.MF
>
>
> When trying to install a subsystem which contains bundles that have a 
> manifest that contains empty headers, the AbstractClauseBasedHeader throws an 
> IllegalArgumentException.
> Example headers are (manifest attached to this issue)
> {code}
> Build-Plan: 
> Build-Number: 
> {code} 
> The exception is caused by the rework of the AbstractClauseBasedHeader for 
> ARIES-1387. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1357) BasicSubsystem can be used by the subsystem install process a factor 6 times faster

[John Ross (JIRA)]

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

John Ross updated ARIES-1357:
-
Fix Version/s: subsystem-2.0.4

> BasicSubsystem can be used by the subsystem install process a factor 6 times 
> faster
> ---
>
> Key: ARIES-1357
> URL: https://issues.apache.org/jira/browse/ARIES-1357
> Project: Aries
>  Issue Type: Improvement
>  Components: Subsystem
>Affects Versions: subsystem-core-1.2.0, subsystem-2.0.1
> Environment: linux windows java
>Reporter: Bas
>Assignee: John Ross
>  Labels: patch, performance
> Fix For: subsystem-2.0.4
>
> Attachments: 1701058.output, FelixResourceAdapter.patch, 
> ManyFeaturesWithSharedBundlesTest.java, PreferredProviderIsEqual.patch, 
> SubsystemResourceInstallerInstallOrder.patch, 
> nl.capesystemsintegration.emagiz.flow.emagiz.mikrotik.process_1.1.0.esa, 
> patch-all-performance-fixes.patch, patch-basicsubsystem.patch, 
> performance-105-afterrestart.nps, subsystem-basicsubsystem-patch.txt, 
> test-cases-1.patch
>
>
> The problem was poor performance while installing a subsystem on a container 
> with 200+ subsystems installed.
> While doing performance analyses on the subsystem install process we noticed 
> the BasicSubsystem is working a lot with its manifest instead of 
> pre-calculating data that is used a lot.
> While using the pre-patch version of BasicSubsystem a subsystem install 
> (while having 200+ running subsystems) could take more than a minute. While 
> using the patched version where we pre-calculate highly used data when a new 
> subsystem manifest or deployment manifest is set we could bring it down to 10 
> seconds. We only pre-calculated the data that was highly used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1381) java.lang.ClassCastException: org.apache.aries.subsystem.core.archive.GenericDirective cannot be cast to org.apache.aries.subsystem.core.archive.VersionRangeAttribute

[John Ross (JIRA)]

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

John Ross updated ARIES-1381:
-
Fix Version/s: subsystem-2.0.4

> java.lang.ClassCastException: 
> org.apache.aries.subsystem.core.archive.GenericDirective cannot be cast to 
> org.apache.aries.subsystem.core.archive.VersionRangeAttribute
> --
>
> Key: ARIES-1381
> URL: https://issues.apache.org/jira/browse/ARIES-1381
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.2
>Reporter: Wouter Bancken
>Assignee: John Ross
>Priority: Minor
> Fix For: subsystem-2.0.4
>
>
> Example:
> Import-Package: 
> org.objectweb.asm;version:="5.0.4,5.0.4]",org.objectweb.asm.signature;version:="[5.0.4,5.0.4]",org.objectweb.asm.tree;version:="[5.0.4,5.0.4]"
> This Import-Package header will cause a "GenericDirective cannot be cast to 
> VersionRangeAttribute" error thrown by the ImportPackageHeader class. 
> This is caused by the fact that the custom version directive is interpreted 
> as the version attribute by the getVersionRangeAttribute method. 
> What should have happened is: 
> 1. The subsystem install should have succeeded.
> 2. The version should have been treated as a custom directive.
> 3. The actual package import versions would assume the default of 
> [0.0.0,infinity) since a version attribute was not specified.
> Link to mailinglist discussion: 
> http://mail-archives.apache.org/mod_mbox/aries-user/201508.mbox/%3CCAL5nZgTwUpc05MY4mWNL3D8-2g13u2it6kYd6JG_ueZNWKJOjA%40mail.gmail.com%3E
> Caused by: java.lang.ClassCastException: 
> org.apache.aries.subsystem.core.archive.GenericDirective cannot be cast to 
> org.apache.aries.subsystem.core.archive.VersionRangeAttribute
>   at 
> org.apache.aries.subsystem.core.archive.ImportPackageHeader$Clause.getVersionRangeAttribute(ImportPackageHeader.java:155)
>   at 
> org.apache.aries.subsystem.core.archive.ImportPackageRequirement.(ImportPackageRequirement.java:42)
>   at 
> org.apache.aries.subsystem.core.archive.ImportPackageHeader$Clause.toRequirement(ImportPackageHeader.java:159)
>   at 
> org.apache.aries.subsystem.core.archive.ImportPackageHeader.toRequirements(ImportPackageHeader.java:218)
>   at 
> org.apache.aries.subsystem.core.internal.BundleResource.computeOsgiWiringPackageRequirements(BundleResource.java:210)
>   at 
> org.apache.aries.subsystem.core.internal.BundleResource.computeRequirementsOtherThanService(BundleResource.java:240)
>   at 
> org.apache.aries.subsystem.core.internal.BundleResource.computeRequirementsAndCapabilities(BundleResource.java:216)
>   at 
> org.apache.aries.subsystem.core.internal.BundleResource.(BundleResource.java:74)
>   at 
> org.apache.aries.subsystem.core.internal.RawSubsystemResource.addResource(RawSubsystemResource.java:435)
>   at 
> org.apache.aries.subsystem.core.internal.RawSubsystemResource.computeResources(RawSubsystemResource.java:420)
>   at 
> org.apache.aries.subsystem.core.internal.RawSubsystemResource.(RawSubsystemResource.java:130)
>   at 
> org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:90)
>   at 
> org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:54)
>   ... 55 more



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1419) Provide-Capability header parser does not support typed attributes.

[John Ross (JIRA)]

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

John Ross updated ARIES-1419:
-
Fix Version/s: subsystem-2.0.4

> Provide-Capability header parser does not support typed attributes.
> ---
>
> Key: ARIES-1419
> URL: https://issues.apache.org/jira/browse/ARIES-1419
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.2
>Reporter: John Ross
>Assignee: John Ross
> Fix For: subsystem-2.0.4
>
> Attachments: require-capability-service-2.patch, 
> require-capability-service.patch
>
>
> I added a patch (require-capability-service.patch) that contains a test case 
> to test the behavior with require-capability and provide-capability and it is 
> failing. Maybe the test case is wrong, can someone check it?
> The test case has a feature with a bundle 1 and an embedded application with 
> a bundle 2.
> Bundle 1 provides a service capability
> Bundle 2 requires a service capability
> I would expect all to be installed correctly but the install fails because of 
> the require-capability for the service not resolving.
> missing requirement 
> org.apache.aries.subsystem.core.archive.RequireCapabilityRequirement: 
> namespace=osgi.service, attributes={}, directives=
> {filter=(objectClass=com.emagiz.osgi.environment.PropertiesSource), 
> effective=active, resolution=mandatory} 
> --
> Try not using typed parameters in Provide-Capability and see what happens. I 
> think there may be a parsing issue in that header.
> In other words, try removing ":List" from 
> "osgi.service;objectClass:List=\"com.emagiz.osgi.environment.PropertiesSource\";effective:=\"active\"".
> 
> Got it working by not using the ":List" but kept the test case 
> because it should work. Tested with type "String" and that works.
> Added another patch 'require-capability-service-2.patch' that contains three 
> test cases.
> 1) For a provide on root level
> 2) For a provide on feature level
> 3) For a provide with a List
> All test cases have three levels: root/feature/application and the 
> application has a bundle with require.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1421) SimpleFilter attribute extraction can not handle version ranges

[John Ross (JIRA)]

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

John Ross updated ARIES-1421:
-
Fix Version/s: subsystem-2.0.4

> SimpleFilter attribute extraction can not handle version ranges
> ---
>
> Key: ARIES-1421
> URL: https://issues.apache.org/jira/browse/ARIES-1421
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.3
>Reporter: Wouter Bancken
> Fix For: subsystem-2.0.4
>
> Attachments: Screen Shot 2015-09-25 at 17.32.34.png, Screen Shot 
> 2015-09-25 at 17.34.48.png
>
>
> The SimpleFilter attributes(SimpleFilter filter, Map 
> attributes) method currently makes the wrong assumption that all attributes 
> are specified by a simple equality.
> This is true for attributes like the 'osgi.wiring.package' attribute. However 
> for version ranges, this assumption is incorrect. 
> Version ranges specify greater than and not relations that are ignored when 
> extracting attributes. 
> For example, 
> (&(osgi.wiring.package=org.osgi.framework)(&(version>=1.7.0)(!(version>=2.0.0
>  will result in the attributes:
> - osgi.wiring.package: org.osgi.framework
> - version: 2.0.0
> Do note that the bug is not in parsing the filter. It is in the extraction of 
> the attributes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1394) Provide more efficient implementations of the local and content repositories.

[John Ross (JIRA)]

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

John Ross updated ARIES-1394:
-
Fix Version/s: subsystem-2.0.4

> Provide more efficient implementations of the local and content repositories.
> -
>
> Key: ARIES-1394
> URL: https://issues.apache.org/jira/browse/ARIES-1394
> Project: Aries
>  Issue Type: Improvement
>  Components: Subsystem
>Affects Versions: subsystem-2.0.2
>Reporter: John Ross
>Assignee: John Ross
>  Labels: performance
> Fix For: subsystem-2.0.4
>
> Attachments: AbstractPerformanceTest.java, 
> BasicSubsystemCacheRegion-after.cpu, BasicSubsystemCacheRegion-before.cpu, 
> BigApplicationTest.java, LocalRepositoryUsesCapabilitySet-after.cpu, 
> Screenshot-Java Monitor - BasicSubsystemCacheRegion.png, Screenshot-Java 
> Monitor - LocalRepositoryUsesCapabilitySet.png, Screenshot-Java Monitor - 
> UseCapabilitySetWithContentRepository.png, Screenshot-Java Monitor - 
> UseExistingSubsystemResourceContentSetsRatherThanContentHeaderToIdentifyContent.png,
>  UseCapabilitySetWithContentRepository-after.cpu, 
> UseExistingSubsystemResourceContentSetsRatherThanContentHeaderToIdentifyContent-after.cpu
>
>
> These measurements use a new test scenario to help flush out bottlenecks in 
> the local and content repositories. The time it took to install 1 application 
> was measured. The application consisted of 200 bundles. Half of the bundles 
> each exported 50 packages. Half of the bundles each imported 50 packages. 
> This gives a total of 5000 requirements and 5000 capabilities.
> Before
> Average time across 1 trials: 13915.0 ms
> Average time across 1 trials: 14628.0 ms
> Average time across 1 trials: 14196.0 ms
> Average time across 1 trials: 13905.0 ms
> Average time across 1 trials: 14021.0 ms
> 14133
> After
> Average time across 1 trials: 7781.0 ms
> Average time across 1 trials: 7782.0 ms
> Average time across 1 trials: 8085.0 ms
> Average time across 1 trials: 7850.0 ms
> Average time across 1 trials: 7971.0 ms
> 7893.8
> A 44.2% overall improvement.
> Before, obtaining the subsystem region took 2254 ms, or 14.4%. After caching 
> the region context bundle and using it to perform the region lookup, the 
> effort no longer registered on a profiler with a 50 ms sampling period.
> Before, finding providers from the local repository took 2260 ms, or 15.3%. 
> After adding the capability set, it took 747 ms, or 5.9%.
> Before, asking whether or not a resource was content took 2152 ms, or 16.9%. 
> After answering by using existing content resource sets rather than the 
> content header, the effort no longer registered on a profiler with a 50 ms 
> sampling period.
> Before, finding providers from the content repository took 4510 ms, or 28.8%. 
> After adding the capability set, it took 49 ms, or 0.4%.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1388) Compute requirement filters only once.

[John Ross (JIRA)]

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

John Ross updated ARIES-1388:
-
Fix Version/s: subsystem-2.0.4

> Compute requirement filters only once.
> --
>
> Key: ARIES-1388
> URL: https://issues.apache.org/jira/browse/ARIES-1388
> Project: Aries
>  Issue Type: Improvement
>  Components: Subsystem
>Affects Versions: subsystem-2.0.2
>Reporter: John Ross
>Assignee: John Ross
>  Labels: performance
> Fix For: subsystem-2.0.4
>
> Attachments: 1440774382251.cpu, 1440774693330.cpu, 
> ManyFeaturesWithSharedBundlesTest.java, Screenshot-Java Monitor.png
>
>
> ResourceHelper.matches(Requirement, Capability) is an often used method 
> during resolution. Currently, it recomputes the requirement filter with each 
> call.
> The measurements used the same test scenario being developed as part of 
> ARIES-1357. The time it took to install 50 features was measured. Each 
> feature consists of 10 bundles plus one application. All features share the 
> same 10 bundles. Each bundle exports 5 unique packages. Each application 
> consists of 10 unique bundles. The bundles import packages offered by the 
> containing feature.
> The baseline average time for installing all 50 features was 67.9 seconds.
> AbstractRequirement will now lazily compute the requirement filter when asked 
> for the first time. Subsequent calls will return the already computed value.
> ResourceHelper now asks whether or not the Requirement is an instance of 
> AbstractRequirement. If so, it asks for the filter directly. If not, the 
> filter is computed as before.
> After these modifications, the average time for installing all 50 features 
> was 46.6 seconds, a 31.3% improvement.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1392) Provide a more efficient implementation of a system repository.

[John Ross (JIRA)]

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

John Ross updated ARIES-1392:
-
Fix Version/s: subsystem-2.0.4

> Provide a more efficient implementation of a system repository.
> ---
>
> Key: ARIES-1392
> URL: https://issues.apache.org/jira/browse/ARIES-1392
> Project: Aries
>  Issue Type: Improvement
>  Components: Subsystem
>Affects Versions: subsystem-2.0.2
>Reporter: John Ross
>Assignee: John Ross
>  Labels: performance
> Fix For: subsystem-2.0.4
>
> Attachments: ManyFeaturesWithSharedBundlesTest.java
>
>
> While running the same test case developed as part of ARIES-1357, profiling 
> continually showed a bottleneck surrounding the system repository. A more 
> efficient implementation has been provided using code copied over from the 
> Apache Felix (http://felix.apache.org/) project.
> http://svn.apache.org/viewvc/felix/trunk/framework/src/main/java/org/apache/felix/framework/capabilityset/CapabilitySet.java?view=log
> http://svn.apache.org/viewvc/felix/trunk/framework/src/main/java/org/apache/felix/framework/capabilityset/SimpleFilter.java?view=log
> http://svn.apache.org/viewvc/felix/trunk/framework/src/main/java/org/apache/felix/framework/util/SecureAction.java?view=log
> http://svn.apache.org/viewvc/felix/trunk/framework/src/main/java/org/apache/felix/framework/util/StringComparator.java?view=log
> These classes were copied to the 
> org.apache.aries.subsystem.core.capabilityset package with some 
> modifications. A new repository implementation called CapabilitySetRepository 
> was created using these classes from the Felix project. This repository will 
> index the standard namespaces along with their associated namespace 
> attributes. It will also create additional capability sets as necessary when 
> encountering custom namespaces.
> The system repository now delegates to CapabilitySetRepository. In addition, 
> the system repository now tracks both bundles and subsystem services. 
> Capabilities are added to the repository as they appear and removed when they 
> go away. Bundle revisions are wrapped with BundleRevisionResource in order to 
> account for service capabilities.
> Other changes resulting from this optimization are listed below. They were 
> necessary and appropriate because either (a) BundleRevisionResource became 
> part of the normal flow when delivered from the system repository, or (b) 
> computing service capabilities for the system repository requires searching 
> for blueprint.xml files in the bundle which causes the framework to attempt a 
> resolution.
> (1) BundleResourceInstaller must now check for BundleRevisionResource in 
> addition to BundleRevision when installing a bundle.
> (2) BundleRevisionResource now provides access to the wrapped BundleRevision.
> (3) ResolveContext must now check for BundleRevisionResource in addition to 
> BundleResource when identifying the region of an already installed resource.
> (4) SubsystemResolverHook will now prevent bundles not referenced by any 
> subsystems from resolving. A non-referenced bundle is one that is being 
> installed as part of a subsystem installation before it has been added as a 
> reference.
> (5) Utils now includes BundleRevisionResource, in addition to BasicSubsystem 
> and BundleRevision, as a shared resource, which is essentially any resource 
> that has already been installed and being referenced by a new subsystem.
> (6) RootSubsystemTest was modified to allow for the RESOLVED state when 
> ensuring the bundle has not been started. Frameworks are allowed to attempt 
> to resolve bundles as needed, and subsystems no longer prevent resolution 
> after entering the installed state, which is the case in this test.
> As part of future work, some of the other internal repository 
> implementations, such as ContentRepository, LocalRepository, and 
> PreferredProviderRepository, should be modified to use 
> CapabilitySetRepository as well.
> The measurements used the same test scenario being developed as part of 
> ARIES-1357. The time it took to install 50 features was measured. Each 
> feature consists of 10 bundles plus one application. All features share the 
> same 10 bundles. Each bundle exports 5 unique packages. Each application 
> consists of 10 unique bundles. The bundles import packages offered by the 
> containing feature.
> Baseline
> Average time across 1 trials: 25843.0 ms
> Average time across 1 trials: 25824.0 ms
> Average time across 1 trials: 25767.0 ms
> Average time across 1 trials: 26043.0 ms
> Average time across 1 trials: 25819.0 ms
> 25859.2
> New System Repository
> Average time across 1 trials: 12260.0 ms
> Average time across 1 trials: 11658.0 ms
> Average time across 1 trials: 11602.0 ms
> 

[jira] [Updated] (ARIES-1389) Compute service requirements and capabilities once in BundleRevisionResource.

[John Ross (JIRA)]

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

John Ross updated ARIES-1389:
-
Fix Version/s: subsystem-2.0.4

> Compute service requirements and capabilities once in BundleRevisionResource.
> -
>
> Key: ARIES-1389
> URL: https://issues.apache.org/jira/browse/ARIES-1389
> Project: Aries
>  Issue Type: Improvement
>  Components: Subsystem
>Affects Versions: subsystem-2.0.2
>Reporter: John Ross
>Assignee: John Ross
>  Labels: performance
> Fix For: subsystem-2.0.4
>
> Attachments: ManyFeaturesWithSharedBundlesTest.java, Screenshot-Java 
> Monitor.png, after.cpu, before.cpu
>
>
> BundleRevisionResource computes the service capabilities with each call to 
> getCapabilities. Testing has shown that this is having an unacceptable 
> performance impact.
> Profiling showed that BundleRevisionResource.getCapabilities was taking up 
> 16.9%, or 7368 ms, of the total time. After the optimization, this was 
> reduced to 0.1%, or 50 ms.
> The measurements used the same test scenario being developed as part of 
> ARIES-1357. The time it took to install 50 features was measured. Each 
> feature consists of 10 bundles plus one application. All features share the 
> same 10 bundles. Each bundle exports 5 unique packages. Each application 
> consists of 10 unique bundles. The bundles import packages offered by the 
> containing feature.
> Baseline
> Average time across 1 trials: 42352.0 ms
> Average time across 1 trials: 43709.0 ms
> Average time across 1 trials: 43309.0 ms
> Average time across 1 trials: 43234.0 ms
> Average time across 1 trials: 41946.0 ms
> Total Average: 42910
> BundleRevisionResource Optimization
> Average time across 1 trials: 32743.0 ms
> Average time across 1 trials: 33094.0 ms
> Average time across 1 trials: 32905.0 ms
> Average time across 1 trials: 32015.0 ms
> Average time across 1 trials: 32226.0 ms
> Total Average: 32596.6
> A 24% overall improvement. The solution was to compute the service 
> capabilities once at object construction time. The same strategy was also 
> employed for service requirements in anticipation that the same performance 
> bottleneck would exist there, although that was not tested here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1387) Make equals and hashCode comparisons within the header, clause, and parameter hierarchies based on equivalency rather than string equals.

[John Ross (JIRA)]

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

John Ross updated ARIES-1387:
-
Fix Version/s: subsystem-2.0.4

> Make equals and hashCode comparisons within the header, clause, and parameter 
> hierarchies based on equivalency rather than string equals.
> -
>
> Key: ARIES-1387
> URL: https://issues.apache.org/jira/browse/ARIES-1387
> Project: Aries
>  Issue Type: Improvement
>  Components: Subsystem
>Reporter: Cristiano Gavião
>Assignee: John Ross
> Fix For: subsystem-2.0.4
>
>
> Currently the org.apache.aries.subsystem.core.archive.SubsystemContentHeader 
> class (line 210) and other headers classes uses a HashSet in order to hold 
> its clauses.
> HashSet doesn't ensure the order of its items and then its impossible to have 
> a reproducible build of any manifest file. As the SubsystemManifest class 
> doesn't provide a equals() method, we can't compare a generated manifest file 
> with any template in a test, it will fail.
> The propose it to change the used HashSet for the LinkedHashSet class.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1352) Do not overwrite existing configuration when installing a subsystem

[John Ross (JIRA)]

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

John Ross updated ARIES-1352:
-
Fix Version/s: (was: subsystem-2.0.3)
   subsystem-2.0.4

> Do not overwrite existing configuration when installing a subsystem
> ---
>
> Key: ARIES-1352
> URL: https://issues.apache.org/jira/browse/ARIES-1352
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.1
> Environment: Felix 5.0.1 / Aries Subsystems 2.0.2
>Reporter: Alexandre Roman
>Assignee: David Bosschaert
>  Labels: easyfix
> Fix For: subsystem-2.0.4
>
> Attachments: aries-1352.patch
>
>
> I have a subsystem which embeds a configuration file (using 
> "embedded-resource" and type="osgi.config.properties" in the manifest file).
> When this subsystem is started, the configuration is applied, as expected.
> However, if a configuration file with the same PID is created, while the 
> subsystem is still not started, the configuration is overwritten by the 
> subsystem resource on start.
> I think that ConfigAdminContentHandler should check if the configuration 
> entries exist before updating it from the subsystem resource.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1328) Application subsystem does not import service capabilities

[John Ross (JIRA)]

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

John Ross updated ARIES-1328:
-
Fix Version/s: subsystem-2.0.4

> Application subsystem does not import service capabilities
> --
>
> Key: ARIES-1328
> URL: https://issues.apache.org/jira/browse/ARIES-1328
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-core-1.2.0
>Reporter: David Bosschaert
>Assignee: John Ross
> Fix For: subsystem-2.0.4
>
> Attachments: api-bundle-1.0.0-SNAPSHOT.jar, 
> application-subsystem-nosvc-1.0.0-SNAPSHOT.esa, 
> application-subsystem-nosvc-rc.esa, application-subsystem-nosvc-ubrc.esa, 
> svc-bundle2-1.0.0-SNAPSHOT.jar, use-bundle-1.0.0-SNAPSHOT.jar
>
>
> I have an application Subsystem that has a bundle that looks for a service 
> via a service tracker.
> This service and its API is provided by pre-existing bundles (api-bundle, 
> svc-bundle2) in the parent subsystem. 
> The OSGi enterprise R5 spec states in 134.16.1 (Application Subsystems):
> "Any required capabilities that are not satisfied by the application's 
> constituents are automatically shared in (imported) from the parent 
> Subsystem."
> However when I install and start the application subsystem 
> (application-subsystem-nosvc), it does not find the services provided in the 
> parent.
> I'm attaching the bundles and subsystem to reproduce. The full source code 
> can be found here: https://github.com/coderthoughts/subsystem-examples



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1348) subsystems that are dependencies are not auto started

[John Ross (JIRA)]

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

John Ross updated ARIES-1348:
-
Fix Version/s: subsystem-2.0.4

> subsystems that are dependencies are not auto started
> -
>
> Key: ARIES-1348
> URL: https://issues.apache.org/jira/browse/ARIES-1348
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.2
> Environment: all
>Reporter: Samuel Bratton
>Assignee: Thomas Watson
> Fix For: subsystem-2.0.4
>
> Attachments: ARIES-1348.patch
>
>
> Auto start does not work in the following scenario:
> - bundle a in Feature a (Fa) imports package x
> - composite b (Cb) exports package x from content bundle b
> 
> 1) install Cb, install Fa, start Fa 
>  start fails with framework resolution error on bundle importing x
> but
> 2) install Cb, start Cb, install Fa, start Fa
>   the start works. 
> In case 1) Cb should have it active count incremented and be started 
> automatically per OSGI.cmpn-6.0.0 134.12.2 Active Use Count.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1377) Subsystems 2.0.4 Release

[John Ross (JIRA)]

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

John Ross updated ARIES-1377:
-
Fix Version/s: subsystem-2.0.4

> Subsystems 2.0.4 Release
> 
>
> Key: ARIES-1377
> URL: https://issues.apache.org/jira/browse/ARIES-1377
> Project: Aries
>  Issue Type: Task
>  Components: Subsystem
>Reporter: John Ross
>Assignee: John Ross
> Fix For: subsystem-2.0.4, subsystem-obr-1.0.4
>
> Attachments: TEST-org.osgi.test.cases.subsystem-6.0.0.html, 
> TEST-org.osgi.test.cases.subsystem.secure-6.0.0.html
>
>
> This will track the 2.0.4 release of the following subsystems modules.
> subsystem-core
>   previous release 2.0.2
>   svn diff -r 1688374
>   
> http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem.core-2.0.2/
>   ARIES-1348: subsystems that are dependencies are not auto started
>   ARIES-1368: Fragment resources receive the osgi.identity capability 
> type of osgi.bundle but should receive osgi.fragment. Also, osgi.wiring.host 
> capabilities and requirements are not computed for bundle or fragment 
> resources.
>   ARIES-1371: Move subsystems to Aries Util 1.1.1
> ARIES-1381: java.lang.ClassCastException: 
> org.apache.aries.subsystem.core.archive.GenericDirective cannot be cast to 
> org.apache.aries.subsystem.core.archive.VersionRangeAttribute
> ARIES-1352: Do not overwrite existing configuration when installing a 
> subsystem
> ARIES-1388: Compute requirement filters only once.
> ARIES-1356: getInstance method on the core Activator shows up on 
> jvisualvm sampling during performance analysis
> ARIES-1359: Performance improvement on the findProviders method in 
> the SystemRepository class
> ARIES-1389: Compute service requirements and capabilities once in 
> BundleRevisionResource.
> ARIES-1390: BasicCapability should take advantage of the effective 
> immutability of capabilities.
> ARIES-1392: Provide a more efficient implementation of a system 
> repository.
> ARIES-1394: Provide more efficient implementations of the local and 
> content repositories.
> ARIES-1396: Use capability set when calculating subsystem 
> dependencies.
> ARIES-1397: Use capability set with preferred provider repository.
> ARIES-1399: Trunk fails OSGi R6 CT
> ARIES-1387: Make equals and hashCode comparisons within the header, 
> clause, and parameter hierarchies based on equivalency rather than string 
> equals.
> ARIES-1084: Subsystem : Failure on restart after framework crash
> ARIES-1408: The RequireCapabilityHeader currently only supports 
> requirements defined by the Aries implementation
> ARIES-1404: Restart of the osgi container does not restart subsystem 
> core because of an error related to missing resource 
> org.apache.aries.subsystem.resource.synthesized
> ARIES-1416: BundleException "bundle is already installed" when the 
> Preferred-Provider subsystem header points to a bundle.
> ARIES-1357: BasicSubsystem can be used by the subsystem install 
> process a factor 6 times faster
> ARIES-1419: Provide-Capability header parser does not support typed 
> attributes.
> ARIES-1235: Installation of a Subsystem containing Subsystems 
> extremely slow
> ARIES-1328: Application subsystem does not import service capabilities
> ARIES-1421: SimpleFilter attribute extraction can not handle version 
> ranges
> ARIES-1419: Provide-Capability header parser does not support typed 
> attributes.
> ARIES-1423: IllegalArgumentException when GenericHeader has no clauses
> subsystem-api
>   previous release 2.0.2
>   svn diff -r 1688370
>   
> http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem.api-2.0.2/
>   ARIES-1371: Move subsystems to Aries Util 1.1.1
> subsystem-bundle
>   previous release 2.0.2
>   svn diff -r 1688378
>   
> http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem-2.0.2/
>   ARIES-1371: Move subsystems to Aries Util 1.1.1
> subsystem-obr
> previous release 1.0.1
> svn diff -r 1668058
> 
> http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.subsystem.obr-1.0.1/
> ARIES-1410: The FelixResourceAdapter does not return all capabilities 
> when given a null namespace.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1377) Subsystems 2.0.4 Release

[John Ross (JIRA)]

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

John Ross updated ARIES-1377:
-
Fix Version/s: (was: subsystem-obr-1.0.4)

> Subsystems 2.0.4 Release
> 
>
> Key: ARIES-1377
> URL: https://issues.apache.org/jira/browse/ARIES-1377
> Project: Aries
>  Issue Type: Task
>  Components: Subsystem
>Reporter: John Ross
>Assignee: John Ross
> Fix For: subsystem-2.0.4
>
> Attachments: TEST-org.osgi.test.cases.subsystem-6.0.0.html, 
> TEST-org.osgi.test.cases.subsystem.secure-6.0.0.html
>
>
> This will track the 2.0.4 release of the following subsystems modules.
> subsystem-core
>   previous release 2.0.2
>   svn diff -r 1688374
>   
> http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem.core-2.0.2/
>   ARIES-1348: subsystems that are dependencies are not auto started
>   ARIES-1368: Fragment resources receive the osgi.identity capability 
> type of osgi.bundle but should receive osgi.fragment. Also, osgi.wiring.host 
> capabilities and requirements are not computed for bundle or fragment 
> resources.
>   ARIES-1371: Move subsystems to Aries Util 1.1.1
> ARIES-1381: java.lang.ClassCastException: 
> org.apache.aries.subsystem.core.archive.GenericDirective cannot be cast to 
> org.apache.aries.subsystem.core.archive.VersionRangeAttribute
> ARIES-1352: Do not overwrite existing configuration when installing a 
> subsystem
> ARIES-1388: Compute requirement filters only once.
> ARIES-1356: getInstance method on the core Activator shows up on 
> jvisualvm sampling during performance analysis
> ARIES-1359: Performance improvement on the findProviders method in 
> the SystemRepository class
> ARIES-1389: Compute service requirements and capabilities once in 
> BundleRevisionResource.
> ARIES-1390: BasicCapability should take advantage of the effective 
> immutability of capabilities.
> ARIES-1392: Provide a more efficient implementation of a system 
> repository.
> ARIES-1394: Provide more efficient implementations of the local and 
> content repositories.
> ARIES-1396: Use capability set when calculating subsystem 
> dependencies.
> ARIES-1397: Use capability set with preferred provider repository.
> ARIES-1399: Trunk fails OSGi R6 CT
> ARIES-1387: Make equals and hashCode comparisons within the header, 
> clause, and parameter hierarchies based on equivalency rather than string 
> equals.
> ARIES-1084: Subsystem : Failure on restart after framework crash
> ARIES-1408: The RequireCapabilityHeader currently only supports 
> requirements defined by the Aries implementation
> ARIES-1404: Restart of the osgi container does not restart subsystem 
> core because of an error related to missing resource 
> org.apache.aries.subsystem.resource.synthesized
> ARIES-1416: BundleException "bundle is already installed" when the 
> Preferred-Provider subsystem header points to a bundle.
> ARIES-1357: BasicSubsystem can be used by the subsystem install 
> process a factor 6 times faster
> ARIES-1419: Provide-Capability header parser does not support typed 
> attributes.
> ARIES-1235: Installation of a Subsystem containing Subsystems 
> extremely slow
> ARIES-1328: Application subsystem does not import service capabilities
> ARIES-1421: SimpleFilter attribute extraction can not handle version 
> ranges
> ARIES-1419: Provide-Capability header parser does not support typed 
> attributes.
> ARIES-1423: IllegalArgumentException when GenericHeader has no clauses
> subsystem-api
>   previous release 2.0.2
>   svn diff -r 1688370
>   
> http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem.api-2.0.2/
>   ARIES-1371: Move subsystems to Aries Util 1.1.1
> subsystem-bundle
>   previous release 2.0.2
>   svn diff -r 1688378
>   
> http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem-2.0.2/
>   ARIES-1371: Move subsystems to Aries Util 1.1.1
> subsystem-obr
> previous release 1.0.1
> svn diff -r 1668058
> 
> http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.subsystem.obr-1.0.1/
> ARIES-1410: The FelixResourceAdapter does not return all capabilities 
> when given a null namespace.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1397) Use capability set with preferred provider repository.

[John Ross (JIRA)]

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

John Ross updated ARIES-1397:
-
Fix Version/s: subsystem-2.0.4

> Use capability set with preferred provider repository.
> --
>
> Key: ARIES-1397
> URL: https://issues.apache.org/jira/browse/ARIES-1397
> Project: Aries
>  Issue Type: Improvement
>  Components: Subsystem
>Affects Versions: subsystem-2.0.2
>Reporter: John Ross
>Assignee: John Ross
>  Labels: performance
> Fix For: subsystem-2.0.4
>
> Attachments: AbstractPerformanceTest.java, BigApplicationTest.java, 
> PreferredProviderRepository-after.cpu, 
> PreferredProviderRepository-before.cpu, Screenshot-Java Monitor - 
> PreferredProviderRepository.png
>
>
> These measurements use the same test as in ARIES-1396. The time it took to 
> install 1 application was measured. The application consisted of 300 bundles. 
> 200 of the bundles each exported 50 packages. 100 of the bundles each 
> imported 50 packages. This gives a total of 5000 requirements and 10,000 
> capabilities. 100 of the exporting bundles serve as preferred providers.
> Before, finding providers from the preferred provider repository took 3305 
> ms, or 25.0%. After making use of the capability set, it took 948 ms, or 8.6%.
> Baseline
> Average time across 1 trials: 12974.0 ms
> Average time across 1 trials: 12597.0 ms
> Average time across 1 trials: 12760.0 ms
> Average time across 1 trials: 12573.0 ms
> Average time across 1 trials: 12339.0 ms
> 12648.6
> Preferred Provider Repository Using Capability Set
> Average time across 1 trials: 10917.0 ms
> Average time across 1 trials: 10562.0 ms
> Average time across 1 trials: 10743.0 ms
> Average time across 1 trials: 10718.0 ms
> Average time across 1 trials: 10471.0 ms
> 10682.2
> A 15.6% improvement.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1371) Move subsystems to Aries Util 1.1.1

[John Ross (JIRA)]

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

John Ross updated ARIES-1371:
-
Fix Version/s: subsystem-2.0.4

> Move subsystems to Aries Util 1.1.1
> ---
>
> Key: ARIES-1371
> URL: https://issues.apache.org/jira/browse/ARIES-1371
> Project: Aries
>  Issue Type: Task
>  Components: Subsystem
>Affects Versions: subsystem-2.0.2
>Reporter: John Ross
>Assignee: John Ross
> Fix For: subsystem-2.0.4
>
>
> A request has been received to update the next subsystems release to point to 
> Aries Util 1.1.1.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1359) Performance improvement on the findProviders method in the SystemRepository class

[John Ross (JIRA)]

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

John Ross updated ARIES-1359:
-
Fix Version/s: subsystem-2.0.4

> Performance improvement on the findProviders method in the SystemRepository 
> class
> -
>
> Key: ARIES-1359
> URL: https://issues.apache.org/jira/browse/ARIES-1359
> Project: Aries
>  Issue Type: Improvement
>  Components: Subsystem
>Affects Versions: subsystem-core-1.2.0, subsystem-2.0.1
> Environment: linux windows java
>Reporter: Bas
>Assignee: John Ross
>Priority: Minor
>  Labels: patch, performance
> Fix For: subsystem-2.0.4
>
> Attachments: aries-1359.patch, subsystem-systemrepository-patch.txt
>
>
> Two improvements in the patch
> 1) Application subsystems are not processed by the method because application 
> subsystems do not share capabilities. (I think it works like that but maybe 
> I'm wrongly interpreting the specification)
> 2) All processed constituents are stored in a set and not processed again 
> when encountered in a different subsystem when they are being shared across 
> features. When using 60 features a shared bundle used to be processed 60 
> times.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1356) getInstance method on the core Activator shows up on jvisualvm sampling during performance analysis

[John Ross (JIRA)]

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

John Ross updated ARIES-1356:
-
Fix Version/s: subsystem-2.0.4

> getInstance method on the core Activator shows up on jvisualvm sampling 
> during performance analysis
> ---
>
> Key: ARIES-1356
> URL: https://issues.apache.org/jira/browse/ARIES-1356
> Project: Aries
>  Issue Type: Improvement
>  Components: Subsystem
>Affects Versions: subsystem-core-1.2.0, subsystem-2.0.1
> Environment: Java windows linux
>Reporter: Bas
>Assignee: John Ross
>Priority: Minor
>  Labels: patch, performance
> Fix For: subsystem-2.0.4
>
> Attachments: aries-1356.patch, subsystem-activator-patch.txt
>
>
> The 'getInstance' method on the core Activator shows up on jvisualvm sampling 
> during performance analysis.
> While doing performance analyses because of poor subsystem install 
> performance while running 200 subsystems we encountered the 'getInstance' 
> method in jvisualvm statistics. It is called so much that it actually cost 4 
> seconds on the total process of installing two subsystems when 200 subsystems 
> have been deployed already.
> While using the patch below we didn't notice it anymore in jvisualvm sampling.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1390) BasicCapability should take advantage of the effective immutability of capabilities.

[John Ross (JIRA)]

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

John Ross updated ARIES-1390:
-
Fix Version/s: subsystem-2.0.4

> BasicCapability should take advantage of the effective immutability of 
> capabilities.
> 
>
> Key: ARIES-1390
> URL: https://issues.apache.org/jira/browse/ARIES-1390
> Project: Aries
>  Issue Type: Improvement
>  Components: Subsystem
>Affects Versions: subsystem-2.0.2
>Reporter: John Ross
>Assignee: John Ross
>Priority: Minor
>  Labels: perfomance
> Fix For: subsystem-2.0.4
>
> Attachments: BasicCapability-Screenshot-Java Monitor.png, 
> BasicCapability-after.cpu, BasicCapability-before.cpu, 
> ManyFeaturesWithSharedBundlesTest.java
>
>
> Currently, when given an already existing Capability at construction, 
> BasicCapability will make a copy of the attributes and directives. This is 
> not really necessary since a properly implemented Capability will be 
> effectively immutable as required by the OSGi API.
> Profiling showed that BasicCapability(Capability, Resource) was taking up 
> 4.6%, or 1550 ms, of the total time. After the optimization, this no longer 
> registered with a sampling time of 50 ms.
> BasicCapability(Capability, Resource) will now simply reuse the already 
> existing, and effectively immutable, attribute and directive maps of the 
> provided capability.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1399) Trunk fails OSGi R6 CT

[John Ross (JIRA)]

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

John Ross updated ARIES-1399:
-
Component/s: Subsystem

> Trunk fails OSGi R6 CT
> --
>
> Key: ARIES-1399
> URL: https://issues.apache.org/jira/browse/ARIES-1399
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Reporter: John Ross
>Assignee: John Ross
> Fix For: subsystem-2.0.4
>
> Attachments: TEST-org.osgi.test.cases.subsystem-6.0.0.html, 
> TEST-org.osgi.test.cases.subsystem-6.0.0.html
>
>
> The Subsystems implementation is currently failing three tests in the R6 CT 
> as a result of some of the recent performance tunings:
> org.osgi.test.cases.subsystem.junit.SharingPolicySubsystemTests.test3A1a_BundleIsolationApplication
> org.osgi.test.cases.subsystem.junit.SharingPolicySubsystemTests.test3A1b_BundleIsolationFeatures
> org.osgi.test.cases.subsystem.junit.SharingPolicySubsystemTests.test3A1a_BundleIsolationComposite
> It fails all three for the same reason. The tests explicitly install a bundle 
> using the region bundle context of the root subsystem. The bundle is 
> subsequently started. Using a synchronous bundle listener, the tests 
> reasonably expect to see INSTALLED, RESOLVED, STARTING, and ACTIVE bundle 
> events. However, the RESOLVED event is missing. It is missing because:
> (1) The Bundle Event Hook, registered with a service ranking of 
> Integer.MAX_VALUE, correctly identifies the event as pertaining to an 
> explicitly installed bundle and acts accordingly.
> (2) As normal, the bundle is wrapped by a Bundle Revision Resource in order 
> to compute the service capabilities and requirements if the Application 
> Modeller service is present. Previously, the capabilities and requirements 
> were not cached but (lazily) computed with each request. Today, they are 
> computed once and cached at instantiation.
> (3) Computing the service capabilities and requirements requires searching 
> for Blueprint XML files through Bundle.findEntries which results in the 
> framework attempting to resolve the bundle.
> (4) Region Digraph, through its own bundle event hook, receives the RESOLVED 
> event before the INSTALLED event. Because this is an unknown bundle, the 
> event is filtered and not delivered to any listeners, synchronous or 
> otherwise.
> There are at least a few possible solutions to the problem.
> (1) Have the Bundle Event Hook explicitly add the bundle to the region using 
> Region.addBundle(Bundle) as part of handling the INSTALLED event. This would 
> (+) solve the immediate issue but (-) promote out of order event delivery to 
> other hooks and listeners.
> (2) Prevent bundles under these circumstances from resolving altogether. This 
> would (+) solve the immediate issue and (+) prevent out of order event 
> delivery, but (-) eliminate the possibility of searching fragment bundles for 
> Blueprint XML files. 
> (3) Lazily compute service dependencies and requirements in Bundle Revision 
> Resource as before but still cache them. This would (+) solve the immediate 
> issue, (+) resemble how things already were before performance tuning, (+) 
> not contribute to out of order event delivery, and (+) leave open the 
> possibility of searching fragments for Blueprint XML files.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1377) Subsystems 2.0.4 Release

[John Ross (JIRA)]

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

John Ross updated ARIES-1377:
-
Fix Version/s: subsystem-obr-1.0.4

> Subsystems 2.0.4 Release
> 
>
> Key: ARIES-1377
> URL: https://issues.apache.org/jira/browse/ARIES-1377
> Project: Aries
>  Issue Type: Task
>  Components: Subsystem
>Reporter: John Ross
>Assignee: John Ross
> Fix For: subsystem-2.0.4, subsystem-obr-1.0.4
>
> Attachments: TEST-org.osgi.test.cases.subsystem-6.0.0.html, 
> TEST-org.osgi.test.cases.subsystem.secure-6.0.0.html
>
>
> This will track the 2.0.4 release of the following subsystems modules.
> subsystem-core
>   previous release 2.0.2
>   svn diff -r 1688374
>   
> http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem.core-2.0.2/
>   ARIES-1348: subsystems that are dependencies are not auto started
>   ARIES-1368: Fragment resources receive the osgi.identity capability 
> type of osgi.bundle but should receive osgi.fragment. Also, osgi.wiring.host 
> capabilities and requirements are not computed for bundle or fragment 
> resources.
>   ARIES-1371: Move subsystems to Aries Util 1.1.1
> ARIES-1381: java.lang.ClassCastException: 
> org.apache.aries.subsystem.core.archive.GenericDirective cannot be cast to 
> org.apache.aries.subsystem.core.archive.VersionRangeAttribute
> ARIES-1352: Do not overwrite existing configuration when installing a 
> subsystem
> ARIES-1388: Compute requirement filters only once.
> ARIES-1356: getInstance method on the core Activator shows up on 
> jvisualvm sampling during performance analysis
> ARIES-1359: Performance improvement on the findProviders method in 
> the SystemRepository class
> ARIES-1389: Compute service requirements and capabilities once in 
> BundleRevisionResource.
> ARIES-1390: BasicCapability should take advantage of the effective 
> immutability of capabilities.
> ARIES-1392: Provide a more efficient implementation of a system 
> repository.
> ARIES-1394: Provide more efficient implementations of the local and 
> content repositories.
> ARIES-1396: Use capability set when calculating subsystem 
> dependencies.
> ARIES-1397: Use capability set with preferred provider repository.
> ARIES-1399: Trunk fails OSGi R6 CT
> ARIES-1387: Make equals and hashCode comparisons within the header, 
> clause, and parameter hierarchies based on equivalency rather than string 
> equals.
> ARIES-1084: Subsystem : Failure on restart after framework crash
> ARIES-1408: The RequireCapabilityHeader currently only supports 
> requirements defined by the Aries implementation
> ARIES-1404: Restart of the osgi container does not restart subsystem 
> core because of an error related to missing resource 
> org.apache.aries.subsystem.resource.synthesized
> ARIES-1416: BundleException "bundle is already installed" when the 
> Preferred-Provider subsystem header points to a bundle.
> ARIES-1357: BasicSubsystem can be used by the subsystem install 
> process a factor 6 times faster
> ARIES-1419: Provide-Capability header parser does not support typed 
> attributes.
> ARIES-1235: Installation of a Subsystem containing Subsystems 
> extremely slow
> ARIES-1328: Application subsystem does not import service capabilities
> ARIES-1421: SimpleFilter attribute extraction can not handle version 
> ranges
> ARIES-1419: Provide-Capability header parser does not support typed 
> attributes.
> ARIES-1423: IllegalArgumentException when GenericHeader has no clauses
> subsystem-api
>   previous release 2.0.2
>   svn diff -r 1688370
>   
> http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem.api-2.0.2/
>   ARIES-1371: Move subsystems to Aries Util 1.1.1
> subsystem-bundle
>   previous release 2.0.2
>   svn diff -r 1688378
>   
> http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem-2.0.2/
>   ARIES-1371: Move subsystems to Aries Util 1.1.1
> subsystem-obr
> previous release 1.0.1
> svn diff -r 1668058
> 
> http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.subsystem.obr-1.0.1/
> ARIES-1410: The FelixResourceAdapter does not return all capabilities 
> when given a null namespace.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIES-1377) Subsystems 2.0.4 Release

[John Ross (JIRA)]

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

John Ross updated ARIES-1377:
-
Fix Version/s: subsystem-obr-1.0.4

> Subsystems 2.0.4 Release
> 
>
> Key: ARIES-1377
> URL: https://issues.apache.org/jira/browse/ARIES-1377
> Project: Aries
>  Issue Type: Task
>  Components: Subsystem
>Reporter: John Ross
>Assignee: John Ross
> Fix For: subsystem-2.0.4, subsystem-obr-1.0.4
>
> Attachments: TEST-org.osgi.test.cases.subsystem-6.0.0.html, 
> TEST-org.osgi.test.cases.subsystem.secure-6.0.0.html
>
>
> This will track the 2.0.4 release of the following subsystems modules.
> subsystem-core
>   previous release 2.0.2
>   svn diff -r 1688374
>   
> http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem.core-2.0.2/
>   ARIES-1348: subsystems that are dependencies are not auto started
>   ARIES-1368: Fragment resources receive the osgi.identity capability 
> type of osgi.bundle but should receive osgi.fragment. Also, osgi.wiring.host 
> capabilities and requirements are not computed for bundle or fragment 
> resources.
>   ARIES-1371: Move subsystems to Aries Util 1.1.1
> ARIES-1381: java.lang.ClassCastException: 
> org.apache.aries.subsystem.core.archive.GenericDirective cannot be cast to 
> org.apache.aries.subsystem.core.archive.VersionRangeAttribute
> ARIES-1352: Do not overwrite existing configuration when installing a 
> subsystem
> ARIES-1388: Compute requirement filters only once.
> ARIES-1356: getInstance method on the core Activator shows up on 
> jvisualvm sampling during performance analysis
> ARIES-1359: Performance improvement on the findProviders method in 
> the SystemRepository class
> ARIES-1389: Compute service requirements and capabilities once in 
> BundleRevisionResource.
> ARIES-1390: BasicCapability should take advantage of the effective 
> immutability of capabilities.
> ARIES-1392: Provide a more efficient implementation of a system 
> repository.
> ARIES-1394: Provide more efficient implementations of the local and 
> content repositories.
> ARIES-1396: Use capability set when calculating subsystem 
> dependencies.
> ARIES-1397: Use capability set with preferred provider repository.
> ARIES-1399: Trunk fails OSGi R6 CT
> ARIES-1387: Make equals and hashCode comparisons within the header, 
> clause, and parameter hierarchies based on equivalency rather than string 
> equals.
> ARIES-1084: Subsystem : Failure on restart after framework crash
> ARIES-1408: The RequireCapabilityHeader currently only supports 
> requirements defined by the Aries implementation
> ARIES-1404: Restart of the osgi container does not restart subsystem 
> core because of an error related to missing resource 
> org.apache.aries.subsystem.resource.synthesized
> ARIES-1416: BundleException "bundle is already installed" when the 
> Preferred-Provider subsystem header points to a bundle.
> ARIES-1357: BasicSubsystem can be used by the subsystem install 
> process a factor 6 times faster
> ARIES-1419: Provide-Capability header parser does not support typed 
> attributes.
> ARIES-1235: Installation of a Subsystem containing Subsystems 
> extremely slow
> ARIES-1328: Application subsystem does not import service capabilities
> ARIES-1421: SimpleFilter attribute extraction can not handle version 
> ranges
> ARIES-1419: Provide-Capability header parser does not support typed 
> attributes.
> ARIES-1423: IllegalArgumentException when GenericHeader has no clauses
> subsystem-api
>   previous release 2.0.2
>   svn diff -r 1688370
>   
> http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem.api-2.0.2/
>   ARIES-1371: Move subsystems to Aries Util 1.1.1
> subsystem-bundle
>   previous release 2.0.2
>   svn diff -r 1688378
>   
> http://svn.apache.org/viewvc/aries/tags/org.apache.aries.subsystem-2.0.2/
>   ARIES-1371: Move subsystems to Aries Util 1.1.1
> subsystem-obr
> previous release 1.0.1
> svn diff -r 1668058
> 
> http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.subsystem.obr-1.0.1/
> ARIES-1410: The FelixResourceAdapter does not return all capabilities 
> when given a null namespace.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARIES-1398) Aries Subsystem implementation is start-order dependent

[David Bosschaert (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARIES-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14943530#comment-14943530
 ] 

David Bosschaert commented on ARIES-1398:
-

Hi [~jwr...@us.ibm.com], you can see in FELIX-5049 that the framework behaviour 
is actually correct because the framework exports the resolver package in 
version 1.0.0 whereas the cmpn bundle exports it in 1.0.1. I guess the real 
solution is to not use the cmpn bundle as it is really not aimed at runtime 
use. We could potentially discuss whether the Subsystems implementation should 
look for Resolver services that are in a different class-space (via 
getAllServices()) and use them through reflection. Normally service consumers 
don't do this, but it might be something to consider...

> Aries Subsystem implementation is start-order dependent
> ---
>
> Key: ARIES-1398
> URL: https://issues.apache.org/jira/browse/ARIES-1398
> Project: Aries
>  Issue Type: Bug
>  Components: Subsystem
>Affects Versions: subsystem-2.0.2
>Reporter: David Bosschaert
> Attachments: nowork.txt, services.txt, works.txt
>
>
> From an email thread by Paul F Frazer: 
> https://mail-archives.apache.org/mod_mbox/aries-user/201509.mbox/browser
> When the Aries Subsystem implementation is started in a certain order the 
> synthesized {{org.osgi.service.subsystem.region.context.0}} bundle is not 
> created.
> While the original bug was reported on the Raspberry Pi, this can also be 
> reproduced on an ordinary laptop. For example by starting the bundles in the 
> following order:
> {code}START LEVEL 1
>ID|State  |Level|Name
> 0|Active |0|System Bundle (5.2.0)
> 1|Active |1|Apache Felix Bundle Repository (2.0.4)
> 2|Active |1|Apache Felix Gogo Command (0.14.0)
> 3|Active |1|Apache Felix Gogo Runtime (0.16.2)
> 4|Active |1|Apache Felix Gogo Shell (0.10.0)
> 5|Active |1|Apache Felix Configuration Admin Service (1.8.6)
> 6|Active |1|Apache Felix Coordinator Service (1.0.0)
> 7|Active |1|osgi.cmpn (5.0.0.201305092017)
> 8|Active |1|slf4j-api (1.7.12)
> 9|Active |1|Region Digraph (1.1.0.v20120522-1841)
>10|Active |1|Apache Aries Subsystem Core (2.0.2)
>11|Resolved   |1|slf4j-simple (1.7.12)
>12|Active |1|Apache Aries Util (1.1.1)
>13|Active |1|Apache Aries Subsystem API (2.0.2)
> {code}
> As you can see the synthesized bundle does not appear.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)