You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@aries.apache.org by Wouter Bancken <wo...@aca-it.be> on 2016/02/01 10:40:34 UTC
Fragment-host in other subsystem than fragment
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
Re: Fragment-host in other subsystem than fragment
Posted by Wouter Bancken <wo...@aca-it.be>.
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 <jw...@gmail.com>:
> 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 <wo...@aca-it.be>
> 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] wouter.bancken@aca-it.be
>> [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 <jw...@gmail.com>:
>>
>>> 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 <wouter.bancken@aca-it.be
>>> > 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
>>>>
>>>
>>>
>>
>
Re: Fragment-host in other subsystem than fragment
Posted by John Ross <jw...@gmail.com>.
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 <wo...@aca-it.be>
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] wouter.bancken@aca-it.be
> [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 <jw...@gmail.com>:
>
>> 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 <wo...@aca-it.be>
>> 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
>>>
>>
>>
>
Re: Fragment-host in other subsystem than fragment
Posted by Wouter Bancken <wo...@aca-it.be>.
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] wouter.bancken@aca-it.be
[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 <jw...@gmail.com>:
> 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 <wo...@aca-it.be>
> 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
>>
>
>
Re: Fragment-host in other subsystem than fragment
Posted by John Ross <jw...@gmail.com>.
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 <wo...@aca-it.be>
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
>