Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re[2]: [equinox-dev] Bundle and Registry

JM> - what is the "type/class" of the service?  My understanding of services
JM> is that the first arg for BundleContext.getServiceReference() is the name 
JM> of the class the service should implement.  Should this be the unique-id 
JM> of the bundle? Your example has the first/only arg as a filter string.
Sorry, it is the Bundle object:

       getServiceReferences( Bundle.class.getName(),
       "(...complicated filter...)");

JM> - The idea of having all the manifest info available for filtering is 
JM> appealing.  Do you see a way around the scalability issues?  With 5000+ 
JM> bundles in the system we really don't want to have all the manifest data 
JM> in memory.  It could be stored on disk but there may be a significant 
JM> performance hit for service lookup.  Implementing a fancy lookup with 
JM> caching etc is possible but may be complex.  Trimming down the list of 
JM> headers may work.
If you have 5000 bundles in the installed state, I am not sure if the
headers will make any significant difference ... But there should be
clever solutions to optimize this search. We intend to make the search
extendable in R4 (registry adapters were discussed in Boca Raton last
month). Limiting the headers is however the most simple solution but
with the new things we are discussing I think there should be an
optimized solution that is feasible.

JM>  Do you think there would be a way of allowing the 
JM> framework implementation to determine which manifest headers it puts in 
JM> the registry?  What happens when someone specs a filter key that does not 
JM> exist?  Is that a match or a failure?
If you use a property name in a filter and it does not exist then it
is a failure. Fortunately there exists the or expression
(!(...)(...)(...)...) that allows you to take care of that case
elegantly. I think the implementation could get the header
lazily when it sees a reference to a header.

JM> - Introducing synthetic headers should be very powerful.  I like it.  How 
JM> does this interact with existing API (e.g., 
JM> PackageAdmin.getExportedPackages)?  Is that an issue?
I think this could be implemented with the registry adapter. The
PackageAdmin implementation could add a registry adaptor and provide
the current package status.

JM> - The permissions issue is intriguing.  In today's usecases for accessing 
JM> bundles by unique-id it is not widespread but it is not uncommon. 
JM> Generally speaking the accessor does not know what bundles it is needing. 
JM> It wants all bundles it can see or it is given a list/id by someone else 
JM> and is attempting to build some structure from it by accessing the 
JM> identified bundles.  Is it possible/reasonable to give these bundles 
JM> blanket ServicePermissions for all the bundles?
We have been very careful with allowing bundles to "see" information
from other bundles due to security reasons. So a blanket
ServicePermission[Bundle,GET] feels very liberal. However, Java security
for me is still like safe sex, we know we should do it but
AllPermission is so convenient ;-)

I am, however, curious to the use cases where a bundle needs to
manipulate other bundles (except for the management agent which needs
liberal permissions anyway)?

JM> - I'm not clear about the "owner" concept.
Every service in the registry has an "owner", i.e. the bundle that
registered it. If the Framework registers the Bundle service object,
it should register it coming from bundle 0, the system bundle.
However, registering it as registered by the bundle has some
interesting qualities ... but also feels like a hack. I have to think
more about it (though I am 100% sure BJ will immediately kill that
idea ;-)

JM> - having namespaces (whatever we define those to be) identified as longs 
JM> may have the same issues we have today with bundles being identified by 
JM> longs.  There is no way to talk about namespaces other than in a 
JM> particular install at a particular point in time.
OK, as I said I realize we need something like it. My current
intuition is that it should be assigned by the Framework which makes
it a run time entity. However, I haven't had enough discussion about
this subject to clear the haze in my head about this.



JM> Jeff






JM> Peter Kriens <Peter.Kriens@xxxxxxxx>
JM> Sent by: equinox-dev-admin@xxxxxxxxxxx
JM> 10/09/2003 03:36 AM
JM> Please respond to pkriens

 
JM>         To:     Pascal Rapicault/Ottawa/IBM@IBMCA
JM>         cc:     equinox-dev@xxxxxxxxxxx
JM>         Subject:        Re: [equinox-dev] Bundle and Registry



JM> Proposal to register bundles in the service registry
JM> ====================================================

JM> When a bundle is installed, the Framework must register the Bundle
JM> object in the Framework registry (BundleContext.registerService()). The
JM> properties of this service are all the main manifest headers, the
JM> state of the service (service.state String), the bundle location, and
JM> the namespace identifiers (service.namespaces long[]). The owner
JM> of the service (which is a Bundle object) must be the Framework.

JM> When the Bundle changes state, the state property must be updated and a
JM> ServiceEvent.MODIFIED must be emitted. When the bundle is un-installed,
JM> the Bundle service object is removed from the service registry, after
JM> all other services are un-registered.

JM> It is now possible to:

JM> - Find bundles depending on any criteria that is a assertion on the
JM>   headers (name, uniqueid, version, module, ...), state or namespace.
 
 
JM> context.getServiceReferences("(|(bundle-uniqueid=12345678)(bundle-version=1.23.*))";)
 
JM> context.getServiceReferences("(|(bundle-module=Xerces)(bundle-version=2.*))";)

JM> - Listen to bundles that come and go, on specific criteria. Notice
JM>   that you can specify a filter on the service tracker. This allows
JM>   service trackers to be used for following a bundle's lifecycle.

JM> - Use debuggers that enumerate the registry and allow the user to
JM>   inspect it. Single mechanism, used for many purposes.

JM> - Use ServicePermission(Bundle,GET) to control access to this
JM>   information.

JM> - Easy to extend with new service properties when the need arises.
JM>   These kind of changes are 100% backward compatible and easy to adapt
JM>   to.

JM> Issues
JM> ======
JM> - The visibility rules of services have not been defined yet and they
JM>   make it necessary to specify the owner

JM> - service.namespaces: This is the scope/namespace we will need to separate 
JM> bundles
JM>   that are running incompatible versions. This is probably a numeric 
JM> identifier
JM>   that is assigned by the framework. This is not discussed yet and I may
JM>   be off track here ...)

JM> - We might want to limit the headers that are visible in the registry.
JM>   On the other hand, we might add more synthetic properties like
JM>   exported packages, imported packages, etc.

JM> - We might need a synthetic property that verifies if a bundle has a
JM>   compatible namespace. This implies there needs to be a default: or
JM>   searches are by default restricted and a full search requires to
JM>   use this synthetic property. Or vice versa.

JM> - The "owner" of the bundle could be either of:

JM>   - The bundle itself.
JM>   - The framework

JM>   The framework as owner is more natural, however, we then have the
JM>   visibility issue when multiple versions are around. We have not yet
JM>   addressed this issue, except for some minor discussions. The requirement
JM>   is that a bundle can only see services that are compatible in
JM>   version (i.e. share a same namespace/scope). Registering a Bundle
JM>   service with the Bundle itself as owner would automatically give you
JM>   this protection but it feels a bit like a hack. I also think that
JM>   the management bundles should see ALL services and should have a way
JM>   to get the ones that are compatible.

JM> - Security issues may arise because the properties are visible to all
JM>   bundles having ServicePermission[Bundle]. However, imho this kind of
JM>   access is privileged to management agents and they need sufficient
JM>   access anyway. Are there (good) use cases where some bundles need
JM>   access to the Bundle objects but are not allowed to see all the
JM>   headers? (There is still always the Bundle methods on
JM>   BundleContext).

JM> =================

JM> Hope this helps, kind regards,

JM>      Peter Kriens

 

PR>> Peter, 

PR>> Could you please provide more details on how this mechanism of 
JM> registry 
PR>> would work?
PR>> The way I understand it, it seems to be quite similar to the plugin 
PR>> registry that eclipse have and that returns the plugin object.

PR>> Thanks

PR>>   PaScaL




PR>> Peter Kriens <Peter.Kriens@xxxxxxxx>
PR>> Sent by: equinox-dev-admin@xxxxxxxxxxx
PR>> 10/08/2003 02:26 AM
PR>> Please respond to pkriens
 
PR>>         To:     equinox-dev@xxxxxxxxxxx
PR>>         cc: 
PR>>         Subject:        Re[2]: [equinox-dev] BundleContext and getName


PR>> OK, I propose -again- to register the bundle objects as a service with 
JM> all 
PR>> the
PR>> attributes from the manifest (and more). This service should be 
JM> registered 
PR>> with the
PR>> bundle itself as owner. This would allow full searching and it 
PR>> automatically
PR>> handles the visibility issue because you are only allowed to see
PR>> the service of bundles that you are compatible with.

PR>> I also see that we need a "namespace" id on services to handle the
PR>> issue of different namespaces in registry.

PR>> Kind regards,

PR>>      Peter Kriens







BR>>> I guess my big disagreement is with the idea that for something to be 

BR>>> clear and concrete you must reflect it in the API as a method. You 
JM> can 

BR>>> have a clear spec and concrete exposure by defining a constant that 
PR>> you 
BR>>> can use in a filter. That is what we do for sid and pid in the 
JM> example 

BR>>> of service properties. We could have added getSID() and getPID() 
PR>> methods 
BR>>> to ServiceReference. By changing the API you cast in stone something 
BR>>> that you may want to change further down the road.

BR>>> Further, whatever you come up with you will need the option to see 
JM> all 

BR>>> the bundles, otherwise you will break management type bundles. (I 
JM> tend 

BR>>> to agree that you shouldn't change the semantics of getBundles()...)

BR>>> Your example using filters would be:

BR>>> Filter foo = new Filter("("+Constants.BUNDLE_UNIQUEID+"=Foo)");
BR>>> Bundle bundles[] = context.getBundles(foo);

BR>>> By doing this you could do things like bypass version filtering 
PR>> (getting 
BR>>> around the problem of not seeing all bundles):
BR>>> Filter foo = new 
BR>>> 
PR>> 
JM> Filter("&("+Constants.BUNDLE_UNIQUEID+"=Foo)("+Constants.BUNDLE_VERSION+"=*)"); 


BR>>> // Gets all versions
BR>>> or
BR>>> Filter foo = new 
BR>>> 
PR>> 
JM> Filter("&("+Constants.BUNDLE_UNIQUEID+"=Foo)("+Constants.BUNDLE_VERSION+"=2.*)"); 


BR>>> // Gets all 2.X versions

BR>>> my 3 cents
BR>>> ben

BR>>> ps - I REALLY hate naming discussions and I won't participate in 
BR>>> discussions on naming topics, but uniqueID is a really BAD name! 
JM> There 

BR>>> are already two unique ids: Bundle ID and Bundle location. Calling 
BR>>> another identifier the unique id is very confusing!


BR>>> 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 
PR>> than
>>>> > proliferating methods I would encourage using Bundle.getHeaders() to 

PR>> 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 

PR>> of
>>>> > the header fields. That way when you find out that you want to look 
PR>> up a
>>>> > bundle by another manifest property (potentially Eclipse specific) 
PR>> 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 
JM> 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 
JM> 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 
PR>> 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
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>>









-- 
Peter Kriens                              Mob. +46705950899
34 Place René Nelli                       Tel. +33467871853
34670 Baillargues, France                 AOL: pkriens



Back to the top