John E. Conlon wrote:
I just converted a bundle that implemented ManagedService and preformed
an action when a configuration Admin property changed (ie when the
updated method was called) from servicebinder to iPOJO. Thought it would
be a piece of cake to let iPOJO manage the configuration with
ConfigurableProperty(s) but then I discovered that there was no easy way
to detect WHEN properties change with iPOJO.
Instead I had to basically fall back to handling the configurationAdmin
myself and create something like:
<component className="com.verticon.react2.emulator.Emulator1">
<Provides interface="org.osgi.service.cm.ManagedService">
<StaticProperty type="java.lang.String"
name="service.pid"
value="com.verticon.react2.emulator"/>
<DynamicProperty field="eventTopic"
value="com/verticon/rfid/MOVEMENT"/>
<DynamicProperty field="delaySeconds" value="10"/>
<DynamicProperty field="periodSeconds" value="10"/>
</Provides>
...
</component>
When the properties change in the ManageService I just update the
DynamicProperties myself.
Would have been nice to have states (like PROPETIES_UPDATING and
PROPERTIES_UPDATED ?) that could be bound to callbacks in the component
to indicate properties were changed by configAdmin.
WDYT?
Well, one of the main points of iPOJO is to work with POJOs.
Implementing callbacks does not really fit into that approach. However,
I agree that there are certain occasions where callbacks are necessary,
but why create a new callback mechanism when ConfigAdmin already gives
you the update() callback. It seems like your current approach is not
unreasonable. Either way your object cannot be a POJO.
It seems that you could define a managed service to get the callback as
well as define the properties as configurable so that iPOJO will
configure them automatically. Then you get your call back and your
properties updated, just like you want. There is potentially an ordering
issue, but its impact depends on what action you want to perform and
since you get the values in your callback, you should be able to remedy
it anyway.
In the end, I guess this could be simplified by having the config
handler implement yet another callback mechanism, but we would like
avoid such things if possible to remain POJO.
Another approach is to write your own property change callback handler
that gives your component events when properties are changed.
Why isn't the inter-communication between handlers enough to avoid this
dependency?
Up until know, there as now inter-communication among handlers. We were
trying to keep things as simple as possible. What we have done now is
created one handler that manages all properties and handlers that are
interested in properties communicate with that.
I see an unfortunate typo, the above line should have said:
"Up until now, there was no inter-communication among handlers."
-> richard
