Am 23.06.14 22:13, schrieb Thomas Watson:
Section 134.14.1 step 7 defines this behavior:
Determine the Subsystem dependencies. See /Determining Dependencies
/on page 573 for details on
determining the Subsystem's dependencies. If the dependencies cannot
be determined successfully
then an installation failure occurs and a Subsystem Exception is
thrown. Otherwise continue
to the next step.
Given that language in the specification, I don't see any way to do
what you want without a Repository service that can provide the
necesary resources in order to provision a resolvable feature A.
Thanks for this hint. I do have an idea now, how to solve the problem.
However, I still think this is in conflict with the behaviour of other
resources (e.g. bundles). It should be considered to specify a
consistent behaviour across different types resources and layers.
Thanks and best regards,
Martin
Inactive hide details for Martin Petzold ---06/23/2014 01:14:33
PM---Hi Tom, Am 23.06.14 19:59, schrieb Thomas Watson:Martin Petzold
---06/23/2014 01:14:33 PM---Hi Tom, Am 23.06.14 19:59, schrieb Thomas
Watson:
From: Martin Petzold <[email protected]>
To: OSGi Developer Mail List <[email protected]>
Date: 06/23/2014 01:14 PM
Subject: Re: [osgi-dev] Resolution and Subsystem Exception with two
Feature Subsystems
Sent by: [email protected]
------------------------------------------------------------------------
Hi Tom,
Am 23.06.14 19:59, schrieb Thomas Watson:
The subsystems implementation is required to auto-provision any
dependencies that a subsystem requires at subsystem installation
time. If it cannot find any resources to provision to satisfy all
the required (non-optional) dependencies then the installation of
the subsystem is required to fail. I assume if you install
feature B first then feature A is allowed to install?
thanks for your reply, the other way should work of course. However, I
do not find anything about this behaviour in the OSGi Subsystems spec.
From my point of view it does not make sense to have different
resolving behaviour of resources (bundles vs. subsystems). A Subsystem
is a resource and should resolve once its requirements are fulfilled
and nothing more. How the requirements are fulfilled should be another
story.
So, how could I solve this problem? I would actually like to see a
solution without OSGi repository implementation...
a) Install subsystem A and let others be resolved (and installed?) via
a repository implementation? Don't feel well with this...
b) Is it possible to define content requirements for the root
subsystem? In this case I could add all subsystems as content
requirements of the root subsystem and then let them install (or
resolve through some OSGi repository implementation) - by the way,
this would be the usual behaviour for bundles within a subsystem and
would actually be the same as my original approach.
c) ???
Best regards,
Martin
Inactive hide details for Martin Petzold ---06/23/2014 11:46:48
AM---Dear OSGi developers, I ran into some problem with the
ApaMartin Petzold ---06/23/2014 11:46:48 AM---Dear OSGi
developers, I ran into some problem with the Apache Aries
Subsystem Implementation.
From: Martin Petzold _<[email protected]>_ <mailto:[email protected]>
To: OSGi Mail List _<[email protected]>_
<mailto:[email protected]>
Date: 06/23/2014 11:46 AM
Subject: [osgi-dev] Resolution and Subsystem Exception with two
Feature Subsystems
Sent by: [email protected]_
<mailto:[email protected]>
------------------------------------------------------------------------
Dear OSGi developers,
I ran into some problem with the Apache Aries Subsystem
Implementation.
The scenario is rather easy: lets take two subsystems A and B (type
feature). A has a requirement on a resource provided by B. All
resources
are deployed as wrapped content resources within the esa. We do
not use
any OSGi repository implementation. This is very similar to Davids
example on his blog [1], however, only one of the subsystems would
contain the shared bundle.
Why does the subsystem implementation throw a Resolution + Subsystem
Exception when I install A. Shouldn't it install A and just wait
until
it is resolved at some point in time? This would be the corresponding
behaviour for a bundle within an OSGi framework.
Background: I would like to split up the target platform into
separate
feature subsystems, e.g. core and test.
[1] _http://coderthoughts.blogspot.de/2013/04/osgi-subsystems.html_
Thanks and best regards,
Martin
_______________________________________________
OSGi Developer Mail List_
[email protected]_ <mailto:[email protected]>_
__https://mail.osgi.org/mailman/listinfo/osgi-dev_
_______________________________________________
OSGi Developer Mail List
[email protected]_ <mailto:[email protected]>
_https://mail.osgi.org/mailman/listinfo/osgi-dev_
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
