Agreed on the naming. We needed something and when the time ran out
that is what we had...
With the code example below
Filter foo = new Filter("("+Constants.BUNDLE_UNIQUEID+"=Foo)");
Bundle bundles[] = context.getBundles(foo);
are you proposing to add a new BundleContext.getBundles(Filter)
method? I'm a little unclear on how that method knows to only look at
the bundles which the context can "see". What I mean is, if it can
scope down and expose only those the framework has selected for Bar to
see then how does the filter with * expose all the bundles? Is there
a default/implicit version filter which matches the ones the bundle
can see but callers can override this?
While it is harder to implement, call and optimize, it does what is
needed so would be fine.
Jeff
p.s. We really appreciate your (and other OSGi community member's)
feedback. We clearly do not have all the context for what has been
proposed in the past, what is likely to be accepted in the future and
the various usecases for OSGi. This kind of feedback is very
valuable, especially early in the game. Please continue to push where
you see fit.
*Benjamin Reed <breed@xxxxxxxxxxxxxxx>*
10/07/2003 04:47 PM
To: Jeff McAffer/Ottawa/IBM@IBMCA
cc: equinox-dev@xxxxxxxxxxx, BJ Hargrave
<hargrave@xxxxxxxxxx>, Pascal Rapicault/Ottawa/IBM@IBMCA, pkriens
<Peter.Kriens@xxxxxxxx>
Subject: Re: [equinox-dev] BundleContext and getName
I guess my big disagreement is with the idea that for something to be
clear and concrete you must reflect it in the API as a method. You can
have a clear spec and concrete exposure by defining a constant that you
can use in a filter. That is what we do for sid and pid in the example
of service properties. We could have added getSID() and getPID() methods
to ServiceReference. By changing the API you cast in stone something
that you may want to change further down the road.
Further, whatever you come up with you will need the option to see all
the bundles, otherwise you will break management type bundles. (I tend
to agree that you shouldn't change the semantics of getBundles()...)
Your example using filters would be:
Filter foo = new Filter("("+Constants.BUNDLE_UNIQUEID+"=Foo)");
Bundle bundles[] = context.getBundles(foo);
By doing this you could do things like bypass version filtering (getting
around the problem of not seeing all bundles):
Filter foo = new
Filter("&("+Constants.BUNDLE_UNIQUEID+"=Foo)("+Constants.BUNDLE_VERSION+"=*)");
// Gets all versions
or
Filter foo = new
Filter("&("+Constants.BUNDLE_UNIQUEID+"=Foo)("+Constants.BUNDLE_VERSION+"=2.*)");
// Gets all 2.X versions
my 3 cents
ben
ps - I REALLY hate naming discussions and I won't participate in
discussions on naming topics, but uniqueID is a really BAD name! There
are already two unique ids: Bundle ID and Bundle location. Calling
another identifier the unique id is very confusing!
Jeff McAffer wrote:
>
> yes and no. Yes, the unique id of a bundle is in the manifest for
> that bundle. There may be several bundles with the same unique id but
> different version numbers. Each of these would have manifests with
> the the header
> Bundle-UniqueId: Foo (or some such)
> but
> Bundle-Version:
> headers with different values
>
> For some bundle Bar which can "see" a bundle Foo, the system will
> determine a particular version of Foo to present to Bar. It is this
> Foo which Bar.getBundleContext().getBundle("Foo") should return.
>
> So, to implement this using just getHeaders() you have to do something
> like
> Bundle[] bundles = Bar.getBundles()
> for each b in bundles
> String id= b.getHeaders().get("Bundle-UniqueId")
> if (id.equals("Foo"))
> return b
> return null
>
> Note that this only works if Bar.getBundles() returns only those
> bundles which Bar can see (as determined by the system). Some have
> argued that this is an unacceptable semantic change. That is, people
> expect getBundles() to return all installed bundles. If it did that,
> then the list would include several Foo bundles and we would not know
> which one to pick. Note that either way you cut it, the code above is
> slow.
>
> Ultimately what is being discussed is the introduction of a
> semantically meaningful/powerful symbolic identifier for bundles that
> is independent of origin (location) and install circumstances (i.e.,
> when it was installed). This is in support of bundles as modules and
> other work where one bundle needs to refer to another bundle. The
> argument is that this particular header is not "just another header"
> and it warrants concrete exposure on the API of Bundle/BundleContext.
> Doing so allows for a clearer specification as well as easier, more
> efficient code.
>
> Jeff
>
>
>
>
>
> *Benjamin Reed <breed@xxxxxxxxxxxxxxx>*
>
> 10/07/2003 02:03 PM
>
>
> To: Jeff McAffer/Ottawa/IBM@IBMCA
> cc: equinox-dev@xxxxxxxxxxx, BJ Hargrave
> <hargrave@xxxxxxxxxx>, Pascal Rapicault/Ottawa/IBM@IBMCA, pkriens
> <Peter.Kriens@xxxxxxxx>
> Subject: Re: [equinox-dev] BundleContext and getName
>
>
>
>
> If the framework reconciles the view of each bundle, you still don't
> have a problem searching headers. We have the same thing with
> permissions and service registry -- the framework makes sure you only
> see services that you are allowed to get.
>
> If I understand correctly, everything you are trying to search on is
> contained in the manifest. Right?
>
> ben
>
> Jeff McAffer wrote:
>
> >
> > I too am in favour of keeping the interfaces simple but there is a
> > subtle point about function in question. In the context of possible
> > multiple version support, there may be several bundles with the same
> > uniqueId but different version numbers. One idea was that the
> > framework would reconcile the view point of each bundle such that it
> > "sees" at most one version of the bundles with any given unique-id.
> > Header lookup is not equivalent in this case.
> >
> > Jeff
> >
> >
> >
> >
> > *Benjamin Reed <breed@xxxxxxxxxxxxxxx>*
> > Sent by: equinox-dev-admin@xxxxxxxxxxx
> >
> > 10/06/2003 06:15 PM
> >
> >
> > To: pkriens <Peter.Kriens@xxxxxxxx>
> > cc: Pascal Rapicault/Ottawa/IBM@IBMCA,
> > equinox-dev@xxxxxxxxxxx, BJ Hargrave <hargrave@xxxxxxxxxx>
> > Subject: Re: [equinox-dev] BundleContext and getName
> >
> >
> >
> >
> > Actually Peter, the discussion was about getting a bundle from the
> > location, not the name. They slipped another identifier in. Rather
than
> > proliferating methods I would encourage using Bundle.getHeaders()
to get
> > information about a specific bundle. If you want to add something to
> > BundleContext, it would seem much better to do
> > BundleContext.getBundles(Filter filter), where you can search on
any of
> > the header fields. That way when you find out that you want to
look up a
> > bundle by another manifest property (potentially Eclipse specific) you
> > don't have to add another method.
> >
> > ben
> >
> > Peter Kriens wrote:
> >
> > >I saw the discussion regarding the extra method in BundleContext to
> > >get a bundle from its name.
> > >
> > >We had this discussion in the past year in the OSGi and decided
> -not- to
> > >extend the BundleContext interface to keep it as simple as possible.
> > >There was quite a bit discussion about this.
> > >
> > >One thing that I proposed, which would more or less fit with the
> > >existing standard, is to register the bundle objects in the registry
> > >with properties for name, id, module, version, etc. This will allow
> > >you search for bundles with an OSGi filter. This may be a cleaner
> > >method than adding methods to BundleContext
> > >
> > >Kind regards,
> > >
> > > Peter Kriens
> > >
> > >PR> Hi,
> > >
> > >PR> Currently BundleContext.getName(String) uses the Bundle-name
> > entry to do
> > >PR> the lookup.
> > >PR> Now that we have Bundle-uniqueId, it seems to me that it would be
> > more
> > >PR> appropriate to do the lookup on this value.
> > >PR> Any comments?
> > >
> > >PR> PaScaL
> > >
> > >
> > >
> > >
> >
> >
> > _______________________________________________
> > equinox-dev mailing list
> > equinox-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/equinox-dev
> >
> >
>
>
>
>
