The Felix framework will not allow fragments to attach to an already resolved host. The described scenario fails because you resolved the host bundle by starting the containing subsystem. The scenario would work on Equinox *as long as* the fragment has only non-payload requirements (i.e. osgi.ee and osgi.wiring.host). I suggest the best approach would be to ensure that all subsystems are installed before starting any, if possible. If not, you'll need to refresh the bundles whenever you install a fragment requiring an already resolved host.
I certainly would not consider this a bug. We could discuss it as a potential improvement if you feel strongly enough and would like to open a JIRA. On Mon, Feb 1, 2016 at 9:31 AM, Wouter Bancken <[email protected]> wrote: > Hi John, > > Thanks for the quick response! > > We are using feature subsystems. The collection of feature subsystems is > our application. Your rewording of our deployment scenario is correct. The > fragment-host header is indeed only present in the fragment's bundle > manifest and therefore only in the subsystem that does not contain the > fragment-host. > > Actually, we made a small mistake when describing our deployment scenario. > The situation where the issue occurs is the following: > 1) Install the fragment-host subsystem > 2) Start the fragment-host subsystem > 3) Install the fragment subsystem > 4) Start the fragment subsystem -> Error when resolving fragment. > > If both subsystems are installed before starting the fragment-host > subsystem, the error does not occur (steps: 1-3-2-4). > If a refresh is triggered after installing the fragment subsystem is > installed, the error does not occur either (steps: 1-2-3-refresh-4) > > Subsystems are started synchronously. > With 'refresh' I indeed mean an FrameworkWiring.refreshBundles triggered > from the GoGo shell with a felix:update and felix:refresh. > > Best regards, > Wouter > > > > Interested in joining our team? Have a look at our *NEW* jobs here > www.aca-it.be/jobs > > [image: Wouter Bancken] > [image: email] [email protected] > [image: Phone] +32 (0) 11 26 50 10 <003211265010> > [image: GSM] +32 (0) 494 25 63 84 <0032494256384> > [image: Logo ACA IT-Solutions] <http://www.aca-it.be> > > *ACA IT-Solutions NV* > *HQ:* Ilgatlaan 5C | 3500 Hasselt > T +32(0)11 26 50 10 <003211265010> | F +32(0)11 26 50 11 > www.aca-it.be | Twitter <https://twitter.com/aca_it> | Facebook > <http://www.facebook.com/pages/ACA-IT-Solutions/278520212202909> | > Linkedin <http://www.linkedin.com/company/6524> > > > 2016-02-01 14:02 GMT+01:00 John Ross <[email protected]>: > >> I have a few questions regarding your scenario. First, what type of >> subsystems are these? I think you work only with applications? Second, I'm >> not sure I understand your deployment description. Please tell me if the >> following rewording is accurate. >> >> 1. We install the application containing the host bundle. (Note that the >> Fragment-Host header would appear in the fragment bundle's manifest, not >> the host bundle's.) >> 2. We install one of the applications containing a fragment bundle with a >> Fragment-Host header in the bundle manifest that references the host bundle >> from step one. >> 3. We start the application containing the host bundle first, followed by >> the one containing the fragment bundle. >> >> Third, as the reworded third step implies, are you starting the >> subsystems in the correct order? Do you start them asynchronously? Fourth, >> what's the relationship between the subsystem containing the host bundle >> and the ones containing the fragments? Are the latter children of the >> former? Finally, what do you mean by "refresh"? Do you mean you're calling >> FrameworkWiring.refreshBundles? >> >> On Mon, Feb 1, 2016 at 3:40 AM, Wouter Bancken <[email protected]> >> wrote: >> >>> Hi, >>> >>> We are currently deploying multiple subsystems in our application that >>> all provide a part of the UI of our application. The bundles responsible >>> for serving the html/js/css files are all fragments to the same >>> fragment-host which is in one of our subsystems. This setup is causing >>> issues when deploying our application. >>> >>> *Deployment:* >>> 1. We install the subsystem containing the fragment-host. >>> 2. We install one of the subsystems containing a fragment to this host. >>> 3. We start both subsystems but we are unable to resolve the fragment. >>> >>> This is fixed if we refresh the fragment-host right before starting the >>> subsystems (after step 2, before step 3). >>> >>> This refresh will be part of our deployment setup but we were wondering >>> if this should have been part of the Aries subsystems framework. Should >>> Aries automatically refresh the fragment-host when installing a new >>> fragment? >>> >>> Best regards, >>> Wouter >>> >> >> >
