Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Toast/Equinox and OSGi"
| Line 1: | Line 1: | ||
Of course, all of Toast is an example of using Equinox and OSGi. Services, Declarative service, extension points, applications, HTTP service and a wide range of other Equinox and OSGi bits are used in various parts of Toast. This page provides a few pointers to interesting places to see these bits in action and some instructions for running Toast to demonstrate the bits. | Of course, all of Toast is an example of using Equinox and OSGi. Services, Declarative service, extension points, applications, HTTP service and a wide range of other Equinox and OSGi bits are used in various parts of Toast. This page provides a few pointers to interesting places to see these bits in action and some instructions for running Toast to demonstrate the bits. | ||
| − | = Applications | + | = Applications = |
| − | Toast uses the Equinox Application facilities, an implementation of the OSGi Application Admin spec, in the Client. See org.eclipse.examples.toast.crust.display | + | Toast uses the Equinox Application facilities, an implementation of the OSGi Application Admin spec, in the Client. See |
| + | * org.eclipse.examples.toast.crust.display -- Key aspects to look at are the implementation of IApplication, the application extension provided in the plugin.xml. Note the specific work needed around threading to ensure that the application runs on the main thread. This is a requirement for running with SWT on the Mac. | ||
| + | * client.product -- Look at the settings on the Overview page. | ||
| − | = Config Admin | + | = Config Admin = |
| + | The OSGi config admin service allows you to set and change parameters used by various services. This facility is integrated into the Declarative Services mechanism so that when the parameters for a service are changed, the service is correctly updated. See | ||
| + | * org.eclipse.examples.toast.client.tracking.config -- There Toast provides a very simple web UI for affecting the frequency with which a client reports its position to the back end. The change is managed using Config Admin. | ||
| − | = Declarative Services | + | = Declarative Services = |
| + | Declarative services are used throughout the base Toast system. This powerful mechanism allows you to write your code independent of OSGi and simply have the required functional units (services) injected as needed. This inversion of control pattern keeps you focused on your problem and OSGi out of the way. The buld of the base Toast system does not reference a single OSGi class--a benefit brought to us by DS. You can look in pretty much any Toast bundle for an example of the usage patterns. In particular, look at the following for some of the more interesting uses of DS. | ||
| + | * org.eclipse.examples.toast.backend.portal -- use of the whiteboard pattern and DS to discover IPortalActions. | ||
| + | * org.eclipse.examples.toast.client.tracking -- use of DS with Config Admin via the "modified" component attribute. | ||
= Whiteboard Pattern = | = Whiteboard Pattern = | ||
| + | The OSGi whiteboard pattern flips the registration/discovery pattern to accommodate SPI or provider patterns. Commonly there is some infrastructure that does an operation, say process events or interface to a device. That is, there are many implementation providers somehow related to the central entity. Rather than have all the providers discover this central processor, the white board pattern has the providers register themselves as services that the central processor can discover and use. This can be powerful but also has some impacts on laziness and the dependency injection supported by DS. See | ||
| + | * org.eclipse.examples.toast.backend.portal -- An example of the whiteboard pattern for discovering IPortalActions and a mechanism for insulating the domain logic from OSGi even when using the whiteboard pattern. | ||
Latest revision as of 22:03, 13 October 2009
Of course, all of Toast is an example of using Equinox and OSGi. Services, Declarative service, extension points, applications, HTTP service and a wide range of other Equinox and OSGi bits are used in various parts of Toast. This page provides a few pointers to interesting places to see these bits in action and some instructions for running Toast to demonstrate the bits.
Applications
Toast uses the Equinox Application facilities, an implementation of the OSGi Application Admin spec, in the Client. See
- org.eclipse.examples.toast.crust.display -- Key aspects to look at are the implementation of IApplication, the application extension provided in the plugin.xml. Note the specific work needed around threading to ensure that the application runs on the main thread. This is a requirement for running with SWT on the Mac.
- client.product -- Look at the settings on the Overview page.
Config Admin
The OSGi config admin service allows you to set and change parameters used by various services. This facility is integrated into the Declarative Services mechanism so that when the parameters for a service are changed, the service is correctly updated. See
- org.eclipse.examples.toast.client.tracking.config -- There Toast provides a very simple web UI for affecting the frequency with which a client reports its position to the back end. The change is managed using Config Admin.
Declarative Services
Declarative services are used throughout the base Toast system. This powerful mechanism allows you to write your code independent of OSGi and simply have the required functional units (services) injected as needed. This inversion of control pattern keeps you focused on your problem and OSGi out of the way. The buld of the base Toast system does not reference a single OSGi class--a benefit brought to us by DS. You can look in pretty much any Toast bundle for an example of the usage patterns. In particular, look at the following for some of the more interesting uses of DS.
- org.eclipse.examples.toast.backend.portal -- use of the whiteboard pattern and DS to discover IPortalActions.
- org.eclipse.examples.toast.client.tracking -- use of DS with Config Admin via the "modified" component attribute.
Whiteboard Pattern
The OSGi whiteboard pattern flips the registration/discovery pattern to accommodate SPI or provider patterns. Commonly there is some infrastructure that does an operation, say process events or interface to a device. That is, there are many implementation providers somehow related to the central entity. Rather than have all the providers discover this central processor, the white board pattern has the providers register themselves as services that the central processor can discover and use. This can be powerful but also has some impacts on laziness and the dependency injection supported by DS. See
- org.eclipse.examples.toast.backend.portal -- An example of the whiteboard pattern for discovering IPortalActions and a mechanism for insulating the domain logic from OSGi even when using the whiteboard pattern.