On Wed, 2006-06-14 at 04:11 -0400, Richard S. Hall wrote: > 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. Thought about this, but wouldn't the bundle be registering 2 PIDs - my component's and one from the configurationHandler?
>From the configAdmin spec: "PIDs must be unique for each service. A bundle must not register multiple configuration target services with the same PID." > > 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. The handler approach was what I had in mind. Thanks to Clement's recent email describing how to do it I think I will rewrite my bundle using a handler to see how that simplifies things. John
