On Tue, 2006-06-13 at 03:45 -0400, Richard S. Hall wrote:
> John E. Conlon wrote:
> > Did not see a real need for Static property but how will this
> > change effect the ConfigurationProperty versus the DynamicProperty?
Guess I spoke too soon on the Static property not being needed - see
below.
>
> We are still figuring out the best approach. The current thinking is
> that we just have "properties" that you specify as being propagated or
> not (i.e., true/false flag). If they are propagated, then the will
> propagate to the service registration when they are modified. The
> default will be to propagate. Any unknown config admin properties will
> be added with the default to propagate, all known properties will follow
> the semantics of their specified behavior. At least that is our thinking
> for now.
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>
N' N'
Bono!
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?
> > 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.
>
> > Have read the documentation so I know a bit about handlers, but I do not
> > know why I would want to create one myself. Also I don't understand how
> > I would add one if I did create one.
> >
>
> For example, we have people interested in creating a handler that will
> transparently expose provided services as web services.
It seems the only way to add handlers is to edit the IPojoConfiguration
class and compile them in.
Is there a way for a iPOJO bundle to submit a custom handler to the
componentManager at runtime?
John
