Now, I'm trying to understand how to arrange for iPOJO to provide a
ManagedServiceFactory on my behalf. The "How to use iPOJO factories"
document¹ says:
How to use the ManagedServiceFactory to create instances
The principle of the ManagedServiceFactory is the same as the iPOJO
Factory Service. To have further information on it, read the OSGi R4
Compendium - Configuration Admin chapter.
I know, it is a little short ;-)
There's earlier discussion of the "factory" attribute on the iPOJO
"component" element. If I have a class "Foo" that I want to be exposed
as the component type for a factory to create, is the following
sufficient?
<?xml version="1.0" encoding="UTF-8"?>
<iPOJO>
<component className="Foo" factory="foo.factory"/>
</iPOJO>
Yes, it is but it does nothing. iPOJO will publish an
ManagedServiceFacotry service with foo.factory as service.pid. You can
create component instances via this service. Else, you can create
instances dynamically with another service :
org.apache.felix.ipojo.Factory. This service does not have exactly the
same semantic as ManagedServiceFactory.
Also, I noticed that the iPOJO plugin creates directives by inspecting
class "Foo" above, and mentioning its various member variables and
their types. If I don't want these fields to be manipulated by iPOJO,
can I do anything to disable this behavior. Actually, I'm not really
sure what iPOJO is going to do with that member-related information;
I'm just fearing the worst.
No, this behavior cannot be disable, it is the base of iPOJO.
All your fields will be manipulated to allow iPOJO management. However,
if the container does not use these fields, it does nothing.
iPOJO write manipulation data in the manifest in order to check
component type metadata against your class (for example, it checks that
a dependency field exists in your class ...). Moreover, it allows
decreasing the number of information to write in your metadata. For
example, if you have an aggregate dependency, you don't have to write
something like "multiple="true"" because the manipulation metadata allow
to know that it is an array. I don't use reflection for performance purpose.
Clement
--
Clement Escoffier
Grenoble University
LSR - Bat. C
220, Rue de la Chimie
BP 53
38041 GRENOBLE CEDEX 9
04.76.51.40.24
http://clement.plop-plop.net
