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 >> > >
