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.
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.
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.
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.
-> richard
