OBR should be able to confirm satisfaction of a filter, including availability
of local resources
-------------------------------------------------------------------------------------------------
Key: FELIX-280
URL: https://issues.apache.org/jira/browse/FELIX-280
Project: Felix
Issue Type: Improvement
Components: Bundle Repository (OBR)
Affects Versions: 1.0.0
Environment: NA
Reporter: Steven E. Harris
This discussion started on the felix-dev list in the thread entitled
Should OBR RepositoryAdmin.discoverResources() include local repository?
http://www.mail-archive.com/[email protected]/msg00071.html
The root problem involves considering the filter supplied to
RepositoryAdmin.discoverResources() as a goal, and wanting OBR to help in
achieving that goal, including the possibility that no additional steps are
required to satisfy the goal. That is, the current state of the local
repository may satisfy the goal, even though no remote repository can offer
anything. A client attempting to meet such a goal should still be able to
discern that its goal has been met.
At present, the OBR workflow starts with a client calling
RepositoryAdmin.discoverResources(), locating Resources available in remote
repositories matching the supplied filter. These Resources are then fed into a
Resolver, which figures out what additional Resources may be needed to satisfy
the root Resources' requirements. Some of these Requirements may be satisfied
by resources already available locally, as represented in the local repository.
If a client seeks to ensure that, say, bundle "foo.bar" of version "1.0" is
available for use, he can supply a filter like
(&(symbolicname=foo.bar)(version=1.0))
to RepositoryAdmin.discoverResources() and see which Resources can fulfil this
goal. However, if this bundle is not available in any remote repositories, but
is already available locally, OBR still signals failure, or at least defeat.
The client cannot tell that its goal is already fulfilled.
My first suggestion was to have RepositoryAdmin.discoverResources() take the
local repository into account as a source for Resources. However, this isn't
quite what the problem demands.
Really, we want a way to turn a filter into a set of Requirements to be added
to a Resolver. Alternately, we'd like to be able to feed a filter directly into
a Resolver to add match criteria, much like Resolver.add() allows one to add a
Resource as both a goal and a source of Requirements.
We should be able to skip the RepositoryAdmin.discoverResources() step entirely
and instead call an overload of Resolver.add() that either takes a Filter or a
String representing a filter to be parsed.
The current workflow oscillates somewhat strangely between identification of
matching Resources and adding more Resources to satisfy additional discovered
Requirements. Why even bother exposing the first set of Resources matched,
forcing the client to push them into the Resolver? As
RepositoryAdmin.discoverResources() is the only way that a client can cause a
Resource to be emitted (Resources not being constructible by a client), their
only path flows between RepositoryAdmin.discoverResources() and Resolver.add().
We could just close that gap and allow Resolver to process a filter internally,
with full access to the local repository as well.
With changes like these in place, my scenario involving a resource available
locally but not remotely would be accommodated: If, after adding my filter to a
Resolver, Resolver.resolve() returns true, I know my goal can be satisfied.
Calling Resolver.deploy() in that case would be a no-op, but should succeed
without error nonetheless.
One problem I see implementing such a solution is the Filter class itself.
Filters as defined in OSGi are opaque and one-way: one can only ask if a filter
matches a Dictionary, not "ask" a filter what it demands. Hence, a Filter can't
be converted to a set of Requirement instances. It can only act like a set of
Requirements in its matching behavior.
Note that the whole filter could be bypassed if we had some public Requirement
factory functions, such as:
public static Requirement requireBundle(String symbolicName);
public static Requirement requireBundle(String symbolicName, String
versionConstraint);
public static Requirement requirePackage(String packageName);
public static Requirement requirePackage(String packageName, String
versionConstraint);
Then, add a method to Resolver:
add(Requirement req);
I'd appreciate some discussion of the viability of these suggestions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
