On Mon, 2006-06-12 at 04:32 -0400, Richard S. Hall wrote: > John E. Conlon wrote: > > (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.) > > > > Good point! > > > 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 agree that "property decoration" should be supported. > > Rather than make it too complicated, I think we can just propagate all > configuration properties to the service registration if present. Sounds good. > Thinking about it a little more. I think we should eliminate the > distinction between static/dynamic service properties and just make them > all have dynamic behavior, especially since propagating all config > properties will have the same effect anyway. Did not see a real need for Static property but how will this change effect the ConfigurationProperty versus the DynamicProperty?
> The somewhat ugly aspect of this is that it creates a dependency between > our configuration handler and our provided service handler, but we > expected that they could not remain mutually independent forever. Why isn't the inter-communication between handlers enough to avoid this dependency? > > We will think about an approach to limit the impact of this, perhaps by > creating a separate component property handler that separates property > handling from everything else, then other handlers that require access > to properties can just depend on that...such an approach might be > cleaner and should be transparent to the component. 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. An example would be beneficial. John
