Hi John, We did not consider this to be a bug. We were mostly wondering if the Aries community agreed that this improvement could be part of the Aries framework.
We created a JIRA: https://issues.apache.org/jira/browse/ARIES-1491 Thanks! Wouter 2016-02-01 17:28 GMT+01:00 John Ross <[email protected]>: > 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 >>>> >>> >>> >> >
