You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by "Alasdair Nottingham (JIRA)" <ji...@apache.org> on 2011/02/24 14:38:38 UTC

[jira] Updated: (ARIES-586) Isolation based runtime doesn't work when resolving maven generated blueprint bundles

     [ https://issues.apache.org/jira/browse/ARIES-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alasdair Nottingham updated ARIES-586:
--------------------------------------

    Description: 
The Isolation based runtime for the application module does not work correctly if a bundle has a dependency on org.osgi.service.blueprint. It has two failure modes. 

If the OBR provisioner uses the local repository it provisions against these and then attempts to install blueprint, and dependencies, into the shared bundle framework. These are already outside the shared bundle framework and available via the shared bundle framework configuration. In this situation installation of an application fails when it tries, and fails, to locate blueprint for installation. If it worked we would hit a different problem whereby we have two blueprint runtimes running trying to process application bundles blueprint.

If the OBR provisioner uses the local repository it fails to provision the application as it cannot find a provider for org.osgi.service.blueprint.

Solution
----------------
I will update the application code so the isolation runtime can provide additional "fake" bundles to the resolution that represents the exports provided by the shared bundle framework. This will allow the application to resolve. These fake bundles will be removed from the result so they do not appear in the deployment manifest for the application. This is similar to what we do today for the application import and export services. I will also force the resolver to not use the local repository.


  was:
The Isolation based runtime for the application module does not work correctly if a bundle has a dependency on org.osgi.service.blueprint. It has two failure modes. 

If the OBR provisioner uses the local repository it provisions against these and then attempts to install blueprint, and dependencies, into the shared bundle framework. These are already outside the shared bundle framework and available via the shared bundle framework configuration. In this situation installation of an application fails when it tries, and fails, to locate blueprint for installation. If it worked we would hit a different problem whereby we have two blueprint runtimes running trying to process application bundles blueprint.

If the OBR provisioner uses the local repository it fails to provision the application as it cannot find a provider for org.osgi.service.blueprint.

Solution
----------------
I will update the application code so the isolation runtime can provide additional "fake" bundles to the resolution that represents the exports provided by the shared bundle framework. This will allow the application to resolve. These fake bundles will be removed from the result so they do not appear in the deployment manifest for the application. This is similar to what we do today for the application import and export services.



> Isolation based runtime doesn't work when resolving maven generated blueprint bundles
> -------------------------------------------------------------------------------------
>
>                 Key: ARIES-586
>                 URL: https://issues.apache.org/jira/browse/ARIES-586
>             Project: Aries
>          Issue Type: Bug
>          Components: Application
>            Reporter: Alasdair Nottingham
>            Assignee: Alasdair Nottingham
>             Fix For: 0.4
>
>
> The Isolation based runtime for the application module does not work correctly if a bundle has a dependency on org.osgi.service.blueprint. It has two failure modes. 
> If the OBR provisioner uses the local repository it provisions against these and then attempts to install blueprint, and dependencies, into the shared bundle framework. These are already outside the shared bundle framework and available via the shared bundle framework configuration. In this situation installation of an application fails when it tries, and fails, to locate blueprint for installation. If it worked we would hit a different problem whereby we have two blueprint runtimes running trying to process application bundles blueprint.
> If the OBR provisioner uses the local repository it fails to provision the application as it cannot find a provider for org.osgi.service.blueprint.
> Solution
> ----------------
> I will update the application code so the isolation runtime can provide additional "fake" bundles to the resolution that represents the exports provided by the shared bundle framework. This will allow the application to resolve. These fake bundles will be removed from the result so they do not appear in the deployment manifest for the application. This is similar to what we do today for the application import and export services. I will also force the resolver to not use the local repository.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira