Advanced component frameworks - OSGi in Action - page 410

Before closing out this chapter, we'll let you in on a little secret about OSG i compo-
nent frameworks: you don't have to choose just one. They can all work together via
the OSG i service layer. To a large degree, you can use any combination of these com-
ponent frameworks in your application. To show this in action, let's convert the paint
application to use the following components:
■ Paint frame from Declarative Services
■ Shape API from standard OSG i
■ Circle from Declarative Services
■ Square from Blueprint
■ Tr i a n g l e f r o m i POJO
■ Window listener from i POJO
To a c h i e v e t h i s g o a l , y o u n e e d t o m a k e a h a n d f u l o f m i n o r c h a n g e s t o y o u r c o m p o -
nents so they'll play well together. We hear you asking, “Wait! Why do we need to
change the components? I thought you said they can work together.” Technically, they
can; but there are some issues due to disparate feature sets. You need to smooth over
one or two discontinuities among the various component models; table 12.5 summa-
rizes these issues.

Table 12.5 Component model discontinuities

ID Difference Discussion

1 Declarative Services'

simple service properties

In Declarative Service components, you use simple string service
properties with class loading to load icons. This approach causes
issues with Blueprint due to issue 2.

2 Blueprint's use of proxy

objects

Because Blueprint injects proxies into the callback methods, you
can't use the service object to load a resource (i.e., service.
getClass().getResource() would search the proxy's class
loader, not the service object's).

3 Blueprint's requirement of

only interfaces as services

For Blueprint, you needed to create an interface to represent the
java.awt.Window API. All components need to agree on the
interfaces they'll expose.

Practically, you need to make the following changes:

In the SimpleShape interface, add an Icon getIcon() method and remove the
ICON_PROPERTY constant that's no longer used. Doing so bridges the gap
between Declarative Services capabilities and Blueprint capabilities with respect
to service attributes.

■

As a consequence, each SimpleShape implementation now loads its own Image-
Icon . Also, the DefaultShape class delegates the getIcon() call to the Simple-
Shape implementation where possible and handles the loading of the under-
construction icon when the service is no longer available.

■

The PaintFrame class uses the getIcon() method on SimpleShape to load the
icon versus handling this itself.

■