John E. Conlon wrote:
Did not see a real need for Static property but how will this
change effect the ConfigurationProperty versus the DynamicProperty?
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.
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.
An example would be beneficial.
No doubt. We are working on it.
-> richard
