On Fri, 2006-06-09 at 05:40 -0400, Richard S. Hall wrote: > Clement Escoffier wrote: > > and thank you for the feedback. > > Definitely, thanks for taking the time to play with this. It is nice to > get feedback from outsiders, since they tend to find issues that we do > not, since we are too close to the work. Thanks to Clement and you for doing the initial work. I agree with the goals of the effort and anticipate it saving people (like me) from doing a lot of error prone work. In other words - I consider it a privilege to help. > > Let us know if the latest changes resolve your remaining issues with > Config Admin support See below. > and I will try to get the source into Felix' svn > repo ASAP. > > -> richard > > > > >> > >> <iPOJO> > >> <component > >> className="com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler" > >> > >> name="com.verticon.experiment.ipojo.configuration" architecture="true"> > >> <Provides interface="org.osgi.service.event.EventHandler"> > >> <DynamicProperty name="event.topics" > >> field="topics" > >> value="com/verticon/rfid/MOVEMENT"/> > >> </Provides> > >> <ConfigurableProperty field="topics" > >> name="event.topics" /> > >> <callback final="VALID" initial="INVALID" > >> method="starting"/> > >> <callback final="INVALID" initial="VALID" > >> method="stopping"/> > >> </component> > >> </iPOJO> > >> > > These metadata mean that only the field "topics" is configurable. Then > > all other field's name are rejected. Nevertheless, your field is a > > dynamic property too, so it should propagate your value to the service > > registration. The version that you used does not handle property's > > name but only property's field. I change this to support property name > > too (if no name, I use the property field). So with the new deployed > > version (always 2.6), your metadata should be correct. Yes the name="event.topics" is now recognized as valid configuration property and is passed. My iPOJO component is successfully updating its dynamic property name="event.topics" through the ConfigurableProperty name="event.topics" accessible through the field topics. Great work! (This was an essential fix as one could never use a field with an embedded period in a Java class and OSGi uses a lot of properties with periods in their names.) > > > >> 1. The first issue (problem?) that I see is that the iPOJO container > >> (org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler) > >> registers, unregisters, and registers a second time as a ManagedService > >> with the framework. Note the ConfiguationAdmin > >> (org.apache.configuration.impl) implementation uses a separate thread > >> for callbacks to invoke the updated method on the service. > > It was a small bugs when the handler start and when the component > > state changes. So I correct it. I test it and it seems to work. > > (reinstall the 2.6 version, at the same location). Yes it works - the service only registers once now. > >> > >> 2. The second issue I have seen is that the container > >> (ConfigurationHandler) is rejecting all configuration properties. > >> (Would have expected at least that the event.topics would be accepted > >> and propagated as it is specified in the metadata. Or did I setup the > >> metadata wrong?) > >> > >> Don't think the container can be so picky with the configs. As specified > >> in the OSGi Compendium Spec R4 p 70-432 All Configuration Properties > >> should be accepted and propagated to the service registration by the > >> ManagedService (in this case the iPOJO container). Here is a log output: > >> > > > > The new pushed values are propagated to the service registration if > > the provided services contains a dynamic property with the same field > > name than the configurable property. > > My configuration handler does not do anything with all other > > configuration, Property propagation - I know that you have designed the container not to pass any pushed Configuration Dictionary property that were not specified in the metadata as both a DynamicProperty and a ConfigurableProperty, but this closes off the iPOJO component from runtime 'property decoration' by management agents using the Configuration Plugin services. In other words I as a iPOJO component developer may not know what attributes my services may be given when I create them, by management agents at runtime.
Have you given any thought to opening up the metadata spec (maybe with includes and/or excludes elements) to allow properties to pass through to the service registration. (See 104.4.3.) > I changed the log level of the message form SEVERE to > > WARNING. It means that you push a non consistent configuration to the > > component (there is no configurable property with this name). Yes, I now see the Warning messages for my other properties. thanks again, John
