Return-Path: X-Original-To: apmail-aries-dev-archive@www.apache.org Delivered-To: apmail-aries-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id AFD8210AA1 for ; Wed, 9 Sep 2015 20:10:48 +0000 (UTC) Received: (qmail 67769 invoked by uid 500); 9 Sep 2015 20:10:46 -0000 Delivered-To: apmail-aries-dev-archive@aries.apache.org Received: (qmail 67723 invoked by uid 500); 9 Sep 2015 20:10:46 -0000 Mailing-List: contact dev-help@aries.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@aries.apache.org Delivered-To: mailing list dev@aries.apache.org Received: (qmail 67655 invoked by uid 99); 9 Sep 2015 20:10:46 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Sep 2015 20:10:46 +0000 Date: Wed, 9 Sep 2015 20:10:45 +0000 (UTC) From: "John Ross (JIRA)" To: dev@aries.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Resolved] (ARIES-1399) Trunk fails OSGi R6 CT MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/ARIES-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ross resolved ARIES-1399. ------------------------------ Resolution: Fixed http://svn.apache.org/r1702099 The third solution was chosen. > 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 > Attachments: 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)