felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven E. Harris (JIRA)" <j...@apache.org>
Subject [jira] Created: (FELIX-280) OBR should be able to confirm satisfaction of a filter, including availability of local resources
Date Mon, 07 May 2007 21:57:15 GMT
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/dev@felix.apache.org/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.


Mime
View raw message