Community
Participate
Working Groups
In the plug-in registry view, it would be nice to show information about OSGi services being published and consumed.
+1
Simon, well isn't that a given ;)
It'd be great if registry was flexible enough to plug into this services. For example: -for HTTP service - show what servlets are registered -for Log service - notify on log event arrival -for UserAdmin service - allow browsing users -for Preferences service - browse preferences -etc. etc. for some other std. services That would help service consumers test their solutions. This way service implementer could see if he correctly consumes service. It doesn't have happen in this bug, but would be good to consider this.
As a follow up to Jacek's comment 3, I would like to see the Configuration for a ManagedService, and the Configurations for a ManagedServiceFactory to be displayed too. Clearly it would be useful to be able to see the properties for each Configuration. But maybe this behavior needs to be in a view specific to ConfigurationAdmin... Back in the days of SMF there was a ConfigurationAdmin servlet that let you remotely manage Configurations. The servlet would generate a page that allowed you to add a Configuration based on properties defined by the bundle's OSGi Metadata.xml. I know that Dave Lavin wrote his own servlet that does much the same thing. He wrote this when we moved from SMF to Equinox. I mention this since we were talking recently of the possibility of this being supported by an Eclipse view and maybe finding a new home for the servlet outside of the Eclipse Technology/OHF project.
Created attachment 89012 [details] first shot first shot at services. Lists services registered by bundles. We'd need some icons to represent a "Services" folder and a single "Service". Now I'll be investigating certain services that could get first support. Dave, I'd be nice too see your servlet :)
Created attachment 89013 [details] mylyn/context/zip
Created attachment 89014 [details] screenshot
Cool stuff Jacek, let's just keep this bug open to show service information... nothing specific or fancy. Other bugs should be open to show more specific information about particular services, like the http service.
In addition to "registered services" (which in the screenshot are displayed as "Services"), it would be useful to see "services in use". Some thought needs to go into how to describe these services. In the distant past OSGi referred to these as "Exported Services" and "Imported Services", but these terms are no longer used. Other possible terms might be "Registered Services" and "Acquired Services". The OSGi APIs will lead you to "Services In Use", which is good, if a little wordy. In my SAT tooling I have four icons that are used to decorate a bundle that: - Acquires a service. - Registers a service. - Acquires and registers a service. - Neither acquires a service nor register a service.
Created attachment 89037 [details] Icons
(In reply to comment #10) wow icons! Simon, The code so far shows all service references using: bundleContext.getAllServiceReferences(null, null) grouped by bundles which have registered them. I'm not sure why some items are displayed multiple times and whether it's good to keep as is, or should I make them display only once. I see there's also ServiceReference#getUsingBundles(), which would probably do what you want. btw, what's SAT, can we really use these icons?
SAT is an OSGi toolkit that is part of the Eclipse Technology OHF project. SAT started life at OTI back in 2001... it was built as an enabling framework to make it quick and easy to build OSGi service-oriented applications composed of many fine-grained bundles. I am the sole committer for the code, but it really is the result of the experience of many people attempting to build real-world applications, mostly in the embedded space. Those icons are actually part of SAT's tooling, and while they were created by me, they are based on some old SMF icons. At the time of their creation SAT was not part of Eclipse, but it is now. SMF, of course, is what became Equinox, minus the SMF tooling. Nevertheless, I don't think the icons fit so well with the other artwork of the view... you should probably stick with the "plug-in" theme, but add some decorators to show that the bundle exports/imports a service. My intention was for the icons to be food-for-thought. For more on SAT, see the web-hosted doc: http://www.vanderleiindustries.com/sat/help/topic/org.eclipse.soda.sat.plugin.doc/books/book.html Downloads are available from Eclipse.org's OHF page, or from the SAT blog, http://eclipse-sat.blogspot.com/.
>The code so far shows all service references using: > >bundleContext.getAllServiceReferences(null, null) You should compare the results of this API with that of getServiceReferences(String, String). The getAllServiceReferences is a more general query that handles some special cases, which you might not care about, so please read the javadoc and compare the results. >grouped by bundles which have registered them. I'm not sure why some >items are displayed multiple times and whether it's good to keep as >is, or should I make them display only once. I would imagine that pruning duplicates would be the right thing to do, especially if they really are the same ServiceReference. By "same", I mean "identical", of course. >I see there's also ServiceReference#getUsingBundles(), which would >probably do what you want. Yes, that's the API you want to use. You might find it helpful to compare what you see in the view with what the console's "bundle <id>" command shows you... this will word-wrap horribly, but you get the idea. osgi> bundle 0 System Bundle [0] Id=0, Status=ACTIVE Registered Services {org.eclipse.osgi.service.runnable.StartupMonitor}={service.ranking=-2147483648, service.id=1} {org.osgi.service.packageadmin.PackageAdmin}={service.ranking=2147483647, service.pid=0.org.eclipse.osgi.framework.internal.core.PackageAdminImpl, service.vendor=Eclipse.org, service.id=2} {org.osgi.service.startlevel.StartLevel}={service.ranking=2147483647, service.pid=0.org.eclipse.osgi.framework.internal.core.StartLevelManager, service.vendor=Eclipse.org, service.id=3} {org.eclipse.osgi.framework.log.FrameworkLog}={service.ranking=2147483647, service.pid=0.org.eclipse.core.runtime.adaptor.EclipseLog, service.vendor=Eclipse.org, service.id=4} {org.eclipse.osgi.framework.log.FrameworkLog}={service.ranking=-2147483648, performance=true, service.pid=46org.eclipse.core.runtime.adaptor.EclipseLog, service.vendor=Eclipse.org, service.id=5} {javax.xml.parsers.SAXParserFactory}={service.id=6} {javax.xml.parsers.DocumentBuilderFactory}={service.id=7} {org.eclipse.osgi.service.datalocation.Location}={type=osgi.user.area, service.id=8} {org.eclipse.osgi.service.datalocation.Location}={type=osgi.instance.area, service.id=9} {org.eclipse.osgi.service.datalocation.Location}={type=osgi.configuration.area, service.id=10} {org.eclipse.osgi.service.datalocation.Location}={type=osgi.install.area, service.id=11} {org.eclipse.osgi.service.urlconversion.URLConverter}={protocol=[bundleentry,bundleresource], service.id=12} {org.eclipse.osgi.service.environment.EnvironmentInfo}={service.ranking=2147483647, service.pid=0.org.eclipse.core.runtime.internal.adaptor.EclipseEnvironmentInfo, service.vendor=Eclipse.org, service.id=13} {org.eclipse.osgi.service.resolver.PlatformAdmin}={service.ranking=2147483647, service.pid=0.org.eclipse.osgi.internal.baseadaptor.StateManager, service.vendor=Eclipse.org, service.id=14} {org.eclipse.osgi.service.pluginconversion.PluginConverter}={service.ranking=2147483647, service.pid=0.org.eclipse.core.runtime.internal.adaptor.PluginConverterImpl, service.vendor=Eclipse.org, service.id=15} {org.eclipse.osgi.framework.console.CommandProvider}={service.ranking=2147483647, service.pid=0.org.eclipse.core.runtime.internal.adaptor.EclipseCommandProvider, service.vendor=Eclipse.org, service.id=16} {org.eclipse.osgi.service.localization.BundleLocalization}={service.ranking=2147483647, service.pid=0.org.eclipse.core.runtime.internal.adaptor.BundleLocalizationImpl, service.vendor=Eclipse.org, service.id=17} {org.eclipse.osgi.internal.provisional.verifier.CertificateVerifierFactory}={service.id=18} {org.eclipse.osgi.internal.provisional.verifier.CertificateTrustAuthority}={service.ranking=-2147483648, osgi.certificate.trust.authority=org.eclipse.osgi, service.id=19} {org.eclipse.osgi.framework.console.CommandProvider}={service.ranking=2147483647, service.id=20} Services in use: {org.eclipse.osgi.framework.console.CommandProvider}={service.ranking=2147483647, service.pid=0.org.eclipse.core.runtime.internal.adaptor.EclipseCommandProvider, service.vendor=Eclipse.org, service.id=16} {org.eclipse.osgi.framework.console.CommandProvider}={service.ranking=2147483647, service.id=20} {org.osgi.service.startlevel.StartLevel}={service.ranking=2147483647, service.pid=0.org.eclipse.osgi.framework.internal.core.StartLevelManager, service.vendor=Eclipse.org, service.id=3} {org.osgi.service.packageadmin.PackageAdmin}={service.ranking=2147483647, service.pid=0.org.eclipse.osgi.framework.internal.core.PackageAdminImpl, service.vendor=Eclipse.org, service.id=2}
Created attachment 89093 [details] patch v2 Simon, thanks for all the hints! I've checked the getAllServiceReferences(String,String) vs. getServiceReferences(String,String) and getAllServiceReferences(String,String) is better here, because it doesn't do any filtering whereas the other method filters all services that are not assignable to bundle (in this case PDERuntime bundle). I have also split services into registered and those in use. If a service is both registered and used by bundle it appears on both lists with special icon. I've used three of your icons (imported, exported, imported-exported) to identify services that are used by bundle, registered by bundle, or both. The thing that needs some work now is ServiceListener to update viewer contents on dynamic changes. Patch assumes, icons from zip are in icons/ directory.
Created attachment 89094 [details] mylyn/context/zip
Created attachment 89282 [details] patch v3 patch updated to support dynamically adding/removing services on base of framework.ServiceListener. It's ready for review. As soon as it's commited, I'll create new bugs to address additional functionality discussed above.
Created attachment 89284 [details] dynamic.joe here's a simple view to simulate dynamic services. Has two buttons "Register service" and "Unregister servce". Good for testing :)
Created attachment 89579 [details] org.eclipse.pde.runtime.patch Here is an updated patch with some cleanup.
Things TODO: - Is this really the best way to present services? Basically by bundle and whether it uses or registers them? Simon? - We should have an option to 'Show Service Content Only' similar to what we do with Extension Content - I don't like how we circumvented RegistryBrowserContentProvider.createAdapter(Object, int) ie., is there a way we can do this similar to how we create the other adapters? - I think we need better icons, but I can take care of that with a gfx request
Created attachment 89580 [details] updated screenshot Here is how it looks right now. Any comments Simon and other OSGi enthusiasts?
cc'ng Tom as I hear he has an opinion on OSGi services ;)
>> Is this really the best way to present services? Basically by bundle >> and whether it uses or registers them? Yes, I think this is at least one way that people want to see them. Another way is to simply list all the services, and then under each one list the bundles that register/uses them. Remember, a single service can be registered by multiple bundles. The bundles-service relationship can be looked at either way, and I think being able to observe a running system from both points of view is valuable. Looking at the latest screen shot I find the icons to be confusing. Assuming the following icons: [p] = plugin [e] = exported service [i] = imported service [b] = both, exported and imported service I see... [p] org.eclipse.equinox.registry [e] Registered Services [b] org.eclipse.core.runtime.IExtensionRegistry [e] org.ecllipse.osgi.framework.console.CommandProvider [i] Used Services [b] org.eclipse.core.runtime.IExtensionRegistry [i] org.eclipse.osgi.service.datalocation.Location [i] org.osgi.service.packageadmin.PackageAdmin I think the use o the [b] icon is too confusing. I think what it's saying in this example is that the bundle org.eclipse.equinox.registry BOTH exports and imports the org.eclipse.core.runtime.IExtensionRegistry service. To have the icons [e] and [i] against the services makes no sense to me, since services don't export or import anything, rather they are exported or imported by bundles. So, if you're going to have [e] and [i] icons they should be used to decorate bundles, not services. I agree that the icons are not ideal. I attached them as food-for-thought until better icons could be acquired. The view currently has a "plugin" theme, so maybe the new icons should continue in that direction. It looks like we're going to need a "service" icon; I think I remember the SMF tooling had a "hand" icon to indicate a service. The orange blob/circle icon represented a bundle.
thanks Chris, adding id to label is really good idea. (In reply to comment #19) > Things TODO: > > - Is this really the best way to present services? Basically by bundle and > whether it uses or registers them? Simon? > - We should have an option to 'Show Service Content Only' similar to what we do > with Extension Content yes, then "Show Service Content Only" could work as Simon described. > - I don't like how we circumvented > RegistryBrowserContentProvider.createAdapter(Object, int) ie., is there a way > we can do this similar to how we create the other adapters? It'd be possible to calculate the type inside adapter, but would require more information: the containing bundle and type of folder (Exported/Imported). And if we're going to have only one icon for all services, then we can remove type at all. I'll revise this when I'll be implementing "Show Service Content Only". (In reply to comment #22) > I think the use o the [b] icon is too confusing. I think what it's saying in > this example is that the bundle org.eclipse.equinox.registry BOTH exports and > imports the org.eclipse.core.runtime.IExtensionRegistry service. > > To have the icons [e] and [i] against the services makes no sense to me, since > services don't export or import anything, rather they are exported or imported > by bundles. So, if you're going to have [e] and [i] icons they should be used > to decorate bundles, not services. my intent was to distinct services that are self-consumed (ImportedAndExported) from those only imported/exported. The other way is to make all services have the same icon.
I agree with simon about the icons comments The blob/circle is used to denote a bundle and probably should not be used for a service icon. Peter Kriens likes to use a simple triangle to represent a service. This is supposed to be a triangle, but looks more like a house :) /-| --------->/ |<-------- registers \ | binds/uses \-| ^ | | Disconvers Could we have |> represent using a service and <| represent registering a service?
(In reply to comment #24) > This is supposed to be a triangle, but looks more like a house :) Tom, you're talented ascii-artist :) to round corners you can use chars like: `'., :) ,-. --------->/ |<-------- registers \ | binds/uses `-' ^ | | Disconvers
Ok, I will file a graphics request and see what the guys come up with. For now, ignore the gfx and just worry about the other issues :)
Created attachment 90585 [details] patch I updated patch to use one icon for all services and improved dynamic service changes handling. Unfortunately to my knowledge there's no way to be notified by Framework about bundles that dynamically register to services (=register a ServiceListener). So "Used services" folder is not refreshed. I removed imported-exported gif. Instead I'll attach a temporary service.gif.
Created attachment 90586 [details] service-icon temporary icon representing a single service.
(In reply to comment #23) > I'll revise this when I'll be implementing "Show Service Content Only". I created a separate bug 220110 (nice number) to track this, as it adds a couple new issues with handling dynamic changes.
Created attachment 90588 [details] updated dynamic services test view view allows: register service, unregister service - pressing these buttons you should see services appearing and disappearing under dynamic.joe bundle node in registry view. "listen to service" (listens to first service registered by view), "unget service" - after pressing these bttns nothing happens, you still have to refresh. for testing open "dynamic.joe" view.
(In reply to comment #27) > Created an attachment (id=90585) > patch this patch is dying for your love Chris :)
It will go into M6, but will have to wait until I get back from vacation.
can I get an updated patch Jacek?
Created attachment 92746 [details] updated patch sure, patch updated against HEAD. it requires "service.gif" icon in icons/obj16, or you'll see red boxes.
too risky for M6 atm with the p2 work going on... will make it one of the first things I do in M7. Hopefully by then the icons should appear.
*ping zx* Not much time left in M7 for this, if it's a risky change can it be put off until 3.5?
(In reply to comment #36) Jacek wants it in 3.4!
What Jacek desires is what Jacek gets ;) > 20080424 I did some UI polish on the contribution and reused some icons from SAT. I use the typical Java interface icon for the actual service which should suffice. Jacek, do you have time for bug 220110? As this would make the feature more useful.
btw Jacek, context help will be needed for this and I will attack you when M7 ships... actually attack everyone to update the help, joy :) Thanks again for the contribution!
oh my! :) yes, I'll do context help.
