[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] BundleContext and getName

I would like to attract our attention that moving to have multiple versions of a bundle
is a major change from the OSGi philosophy and that we need to move cautiously
about API changes. Starting to show versions will not only impact BundleContext
but also how service lookup and registration.

What is our current position regarding service registering/lookup when considering multiple
versions of a bundle?

Eclipse took the easy way out, if a plugin has extensions or extension points, can't be loaded
concurrently. Maybe we should consider taking the same easy way out here.
Multiple bundle versions could be only for libraries, not for bundles with services, extensions,
or extension points.

Any idea?

Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center

Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
Sent by: equinox-dev-admin@xxxxxxxxxxx

10/06/2003 11:56 AM

        To:        equinox-dev@xxxxxxxxxxx
        Subject:        Re: [equinox-dev] BundleContext and getName

d'oh goofy mailer did not reply to the list...

----- Forwarded by Jeff McAffer/Ottawa/IBM on 10/06/2003 11:53 AM -----
Jeff McAffer

10/06/2003 10:06 AM

       To:        Rafael Chaves/Ottawa/IBM@IBMCA


       From:        Jeff McAffer/Ottawa/IBM@IBMCA

       Subject:        Re: [equinox-dev] BundleContext and getName

I have another variation.

BundleContext knows what bundle it is for.  In the case of multiple versions, a given bundle (and thus its BundleContext) can only see one (according to its scope or whatever model we define).  As such, a method like

       Bundle getBundle(String uniqueId)
should be sufficient.

In some management/admin scenarios it is possible that someone would need to get all versions of a bundle.  I suggest that we defer this to the discussion of states etc.  For example, given some implementation of a State object which represents the bundles installed/resolved in the system, one could navigate the State, find the desired BundleDescription(s) and use BundleContext.getBundle(long) to get the bundle.

My thinking here is that BundleContext is better off if it represents the world from its associated Bundle's point of view.   The few people who need a different view can use the alternate path described.


Rafael Chaves/Ottawa/IBM@IBMCA
Sent by: equinox-dev-admin@xxxxxxxxxxx

10/06/2003 09:44 AM

       To:        equinox-dev@xxxxxxxxxxx


       Subject:        Re: [equinox-dev] BundleContext and getName

I agree as well. I have just two concerns with the proposed APIs:

1 - The method that returns multiple bundles should be called "getBundles" (plural).

2 - I would also suggest that a method that returns a single bundle with no version specified could still be provided (see org.eclipse.core.runtime.IPluginRegistry.getPluginDescriptor(String)):

    * Returns a Bundle with the specified Bundle-UniqueId
     * or null if none exist. If more than one bundle with
     * the specified Bundle-UniqueId exist, one of them will
     * be arbitrarily chosen.
   public Bundle getBundle(String uniqueId, String version);

This is pretty useful when you don't care about versions, because it doesn't force you to do this:

Bundle[] allBundles = context.getBundles(id);

Bundle interestingBundle = (allBundles == null) ? null : allBundles[0];

When all you need is:

Bundle interestingBundle = context.getBundle(id);

Thomas Watson <tjwatson@xxxxxxxxxx>
Sent by: equinox-dev-admin@xxxxxxxxxxx

06/10/2003 09:17 AM

      To:        equinox-dev@xxxxxxxxxxx


      Subject:        Re: [equinox-dev] BundleContext and getName

I think you are refering to the BundleContext.getBundle(String name)
method.  The BundleContext interface has a new method
BundleContext.getBundle(String name) which was intended to take a
Bundle-Name and look in the framework to find a single bundle with a
matching name.  This method definition has a flaw in the fact that it
assumes that Bundle-Names are unique in the framework.  I agree that the
new BundleContext.getBundle(String name) method should be changed.  I have
the following two proposals.

interface BundleContext {

    * Returns all Bundles with the specified Bundle-UniqueId or null
    * if none exist.
   public Bundle[] getBundle(String uniqueId);
    * Returns the Bundle with the specified Bundle-UniqueId and
    * or null if none exist.
   public Bundle getBundle(String uniqueId, String version);


Since the framework can have multiple versions of a bundle with the same
uniqueId installed then the BundleContext.getBundle(String uniqueId) should
return a list of all the bundles with the specified uniqueId.  If you want
a specific version of a bundle then use the BundleContext.getBundle(String
uniqueId, String version) method.  We can get by with only the
BundleContext.getBundle(String unqueId) method.  This just means the
callers would have to look for specific versions if they needed to in the
list returned.

Any comments?

Thomas Watson
Pervasive Development
Phone: 512-838-4533 Tie: 678-4533

                   Pascal Rapicault                                                                                                        
                   <Pascal_Rapicault@        To:       equinox-dev@xxxxxxxxxxx                                                              
                   ca.ibm.com>               cc:                                                                                            
                   Sent by:                  Subject:  [equinox-dev] BundleContext and getName                                              
                   10/06/2003 07:35                                                                                                        


Currently BundleContext.getName(String) uses the Bundle-name entry to do
the lookup.
Now that we have Bundle-uniqueId, it seems to me that it would be more
appropriate to do the lookup on this value.
Any comments?


equinox-dev mailing list