Java Reference
In-Depth Information
Metadata
Null
metadata
NonNull
metadata
Props
metadata
Map
entry
Value
metadata
IdRef
metadata
Component
metadata
Collection
metadata
Map
metadata
ServiceRef.
metadata
Ref
metadata
Bean
metadata
Service
metadata
Target
Reference
listener
RefList
metadata
Reference
metadata
Bean
property
Bean
argument
Registration
listener
Figure 12.3
The Blueprint metadata interface hierarchy
To a c c e s s t h e m e t a d a t a m o d e l , t h e B l u e p r i n t s p e c i f i c a t i o n p r o v i d e s t h e
Blueprint-
Container
interface, which serves a purpose similar to the
ComponentContext
in
Declarative Services. It has the following signature:
public interface BlueprintContainer {
void Set getComponentIds();
Object getComponentInstance(String id);
ComponentMetadata getComponentMetadata(String id)
Collection getMetadata(Class type);
}
This concludes our look at the
OSG
i Blueprint Container specification. We'll now turn
our attention to the last component framework on our list: i
POJO
, from the Apache
Felix project.
12.2
Apache Felix iPOJO
Outside of the
OSG
i Alliance, a number of different component models have been
built for or ported to the
OSG
i environment:
Google Guice peaberry (
http://code.google.com/p/peaberry/
)
■
ScalaModules (
http://wiki.github.com/weiglewilczek/scalamodules/
)
■
■
In this section, we'll focus on i
POJO
due to its novel features and because we (the
authors) are all involved in the Apache Felix project. One of the main goals of i
POJO
is to simplify creating dynamic, service-oriented applications in
OSG
i. The biggest dif-
ference between i
POJO
and Declarative Services or Blueprint is its approach, which
includes the following:
