You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "John E. Conlon" <jc...@verticon.com> on 2006/06/09 00:09:35 UTC
iPOJO and Configuration Admin Service
Hi Clement,
Have been testing the Configuration Admin functionality of a simple
iPOJO component that implements an EventAdmin EventHandler service and
updates the event.topics property associated with the service in
response to Configuration Admin change. In other words it's an
eventHandler that consumes different events from different publishers
based on configuration changes received from Configuration Admin.
Here is the metadata of the iPOJO component:
<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>
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.
The following is log output of the start of a bundle containing the
above iPOJO component. You can see the multiple binds and the unbinds
the underlying servicebinder is making on the ConfigurationAdminFactory.
-> start 23
INFO [Felix Shell TUI]
org.apache.configuration.impl.ConfigurationAdminFactory.setManagedService(ConfigurationAdminFactory.java:141) - Binding to ManagedService org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler@b7b3f9 (com.verticon.experiment.ipojo.configuration) from file:bundle/ipojo.configuration-1.0-SNAPSHOT.jar
DEBUG [Felix Shell TUI]
com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler.<init>(ConfiguribleEventHandler.java:17) - Constructed
DEBUG [Felix Shell TUI]
com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler.starting(ConfiguribleEventHandler.java:21) - Starting
INFO [Felix Shell TUI]
org.apache.configuration.impl.ConfigurationAdminFactory.unsetManagedService(ConfigurationAdminFactory.java:157) - Unbinding from ManagedService org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler@b7b3f9 (com.verticon.experiment.ipojo.configuration) from file:bundle/ipojo.configuration-1.0-SNAPSHOT.jar
ERROR [Update Consumer]
org.apache.configuration.impl.UpdateConsumer.handleEvent
(UpdateConsumer.java:155) - Failed to handle a ServiceRegistration
event.
java.io.IOException: Could not find a bundle from the serviceReference
[org.osgi.service.cm.ManagedService]
at
org.apache.configuration.impl.UpdateConsumer.addLocationToPidsAndCheck
(UpdateConsumer.java:480)
at org.apache.configuration.impl.UpdateConsumer.handleEvent
(UpdateConsumer.java:130)
at org.apache.configuration.impl.UpdateConsumer.run
(UpdateConsumer.java:97)
at java.lang.Thread.run(Thread.java:595)
INFO [Felix Shell TUI]
org.apache.configuration.impl.ConfigurationAdminFactory.setManagedService(ConfigurationAdminFactory.java:141) - Binding to ManagedService org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler@b7b3f9 (com.verticon.experiment.ipojo.configuration) from file:bundle/ipojo.configuration-1.0-SNAPSHOT.jar
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:
INFO [Update Consumer]
org.apache.configuration.impl.UpdateConsumer.updateManagedService
(UpdateConsumer.java:245) - Invoking updated on
managedService=org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler@1961581, with configuration=org.apache.configuration.impl.ConfigurationDictionary [ event.topics=com/verticon/rfid, service.pid=com.verticon.experiment.ipojo.configuration, objectclass=[react2Server, apacheServiceConfiguration, top], cn=ipojo ]
Jun 8, 2006 3:39:02 PM
org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler
updated
SEVERE:
[com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler]
The configuration is not valid, the field event.topics is not a
configurable property
Jun 8, 2006 3:39:02 PM
org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler
updated
SEVERE:
[com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler]
The configuration is not valid, the field service.pid is not a
configurable property
Jun 8, 2006 3:39:02 PM
org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler
updated
SEVERE:
[com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler]
The configuration is not valid, the field objectclass is not a
configurable property
Jun 8, 2006 3:39:02 PM
org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler
updated
SEVERE:
[com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler]
The configuration is not valid, the field cn is not a configurable
property
kind regards,
John
Re: iPOJO and Configuration Admin Service
Posted by "John E. Conlon" <jc...@verticon.com>.
Hi,
> In fact, at packaging, iPOJO look for the used namespace of your
> component an import the corresponding packages. Then, at runtime, iPOJO
> creates an new instance of the needed handler. This handler is managed
> like the others handlers.
Beautiful!
So one may declare multiple handlers in the metadata with each having
it's own namespace.
I'll have to think about how I can utilize this with my components.
> I am writing a more completed documentation about this new feature (the
> actual documentation refers to the 2.5 version).
Please explain in the documentation that one can specify multiple components within
the parent iPOJO metadata element. Couldn't figure it out from the original documentation
but my experiments confirmed it to be so.
cheers,
John
On Wed, 2006-06-14 at 08:57 +0200, Clement Escoffier wrote:
> Hello,
>
> > It seems the only way to add handlers is to edit the IPojoConfiguration
> > class and compile them in.
> >
> > Is there a way for a iPOJO bundle to submit a custom handler to the
> > componentManager at runtime?
> >
> In fact, this was true for the 2.5 version. But in the 2.6, handlers can
> be deployed without changing the iPOJO core runtime.
> An handler is a class implementing the Handler interface like the
> following one (who is a very simple handler) :
>
> package fr.imag.adele.escoffier.handler.log;
>
> import org.apache.felix.ipojo.ComponentManager;
> import org.apache.felix.ipojo.Handler;
> import org.apache.felix.ipojo.metadata.Element;
>
> public class LogHandler implements Handler {
>
> public static final String NAMESPACE = "fr.imag.adele.escoffier.handler.log.LogHandler";
> private ComponentManager m_manager;
>
> public void configure(ComponentManager arg0, Element arg1) {
> m_manager = arg0;
> Element log = arg1.getElements("log", NAMESPACE)[0];
> if(log.getAttribute("enable", NAMESPACE).equals("true")) {arg0.register(this);}
> }
> public Object getterCallback(String arg0, Object arg1) { return arg1; }
> public boolean isValid() { return true; }
> public void setterCallback(String arg0, Object arg1) { }
> public void start() { System.out.println("[LogHandler] Start the LogHandler on " + m_manager.getComponentMetatada().getClassName()); }
> public void stateChanged(int arg0) {
> String state;
> if (arg0 == ComponentManager.INVALID) { state = "INVALID"; }
> else { state = "VALID"; }
> System.out.println("[LogHandler] State Changes to " + state + " of the component " + m_manager.getComponentMetatada().getClassName());
> }
> public void stop() { System.out.println("[LogHandler] Stop the LogHandler on " + m_manager.getComponentMetatada().getClassName()); }
>
> }
>
> Note that the configure method looks for element of a special namespace.
> This namespace is the class name of your handler.
> This class is packaged in a bundle exporting the package containing this
> class.
>
> Then when a component want use your new handler, the component's
> description should be something like :
>
> <iPOJO xmlns:log="fr.imag.adele.escoffier.handler.log.LogHandler">
> <component className="fr.imag.adele.escoffier.hello.impl.HelloServiceImpl" architecture="true">
> <provides/>
> <log:log log:enable="true"/>
> </component>
> </iPOJO>
>
>
> This description declares a namespace (log) pointing on the namespace of
> your handler (i.e. the handler's class name). Then, the description can
> contains the log element of the log namespace.
>
> In fact, at packaging, iPOJO look for the used namespace of your
> component an import the corresponding packages. Then, at runtime, iPOJO
> creates an new instance of the needed handler. This handler is managed
> like the others handlers.
>
> By using this method, you don't need to change the iPOJOConfiguration
> class, declaring only "core" handler.
>
> I am writing a more completed documentation about this new feature (the
> actual documentation refers to the 2.5 version).
>
> Clement
>
>
Re: iPOJO and Configuration Admin Service
Posted by Clement Escoffier <cl...@gmail.com>.
Hello,
> It seems the only way to add handlers is to edit the IPojoConfiguration
> class and compile them in.
>
> Is there a way for a iPOJO bundle to submit a custom handler to the
> componentManager at runtime?
>
In fact, this was true for the 2.5 version. But in the 2.6, handlers can
be deployed without changing the iPOJO core runtime.
An handler is a class implementing the Handler interface like the
following one (who is a very simple handler) :
package fr.imag.adele.escoffier.handler.log;
import org.apache.felix.ipojo.ComponentManager;
import org.apache.felix.ipojo.Handler;
import org.apache.felix.ipojo.metadata.Element;
public class LogHandler implements Handler {
public static final String NAMESPACE = "fr.imag.adele.escoffier.handler.log.LogHandler";
private ComponentManager m_manager;
public void configure(ComponentManager arg0, Element arg1) {
m_manager = arg0;
Element log = arg1.getElements("log", NAMESPACE)[0];
if(log.getAttribute("enable", NAMESPACE).equals("true")) {arg0.register(this);}
}
public Object getterCallback(String arg0, Object arg1) { return arg1; }
public boolean isValid() { return true; }
public void setterCallback(String arg0, Object arg1) { }
public void start() { System.out.println("[LogHandler] Start the LogHandler on " + m_manager.getComponentMetatada().getClassName()); }
public void stateChanged(int arg0) {
String state;
if (arg0 == ComponentManager.INVALID) { state = "INVALID"; }
else { state = "VALID"; }
System.out.println("[LogHandler] State Changes to " + state + " of the component " + m_manager.getComponentMetatada().getClassName());
}
public void stop() { System.out.println("[LogHandler] Stop the LogHandler on " + m_manager.getComponentMetatada().getClassName()); }
}
Note that the configure method looks for element of a special namespace.
This namespace is the class name of your handler.
This class is packaged in a bundle exporting the package containing this
class.
Then when a component want use your new handler, the component's
description should be something like :
<iPOJO xmlns:log="fr.imag.adele.escoffier.handler.log.LogHandler">
<component className="fr.imag.adele.escoffier.hello.impl.HelloServiceImpl" architecture="true">
<provides/>
<log:log log:enable="true"/>
</component>
</iPOJO>
This description declares a namespace (log) pointing on the namespace of
your handler (i.e. the handler's class name). Then, the description can
contains the log element of the log namespace.
In fact, at packaging, iPOJO look for the used namespace of your
component an import the corresponding packages. Then, at runtime, iPOJO
creates an new instance of the needed handler. This handler is managed
like the others handlers.
By using this method, you don't need to change the iPOJOConfiguration
class, declaring only "core" handler.
I am writing a more completed documentation about this new feature (the
actual documentation refers to the 2.5 version).
Clement
Re: iPOJO and Configuration Admin Service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
John E. Conlon wrote:
> 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."
>
Yes, you are probably correct.
> 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.
Great. Let us know how it goes.
-> richard
Re: iPOJO and Configuration Admin Service
Posted by "John E. Conlon" <jc...@verticon.com>.
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
Re: iPOJO and Configuration Admin Service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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.
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.
>>> 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.
>>
I see an unfortunate typo, the above line should have said:
"Up until now, there was no inter-communication among handlers."
-> richard
Re: iPOJO and Configuration Admin Service
Posted by "John E. Conlon" <jc...@verticon.com>.
On Tue, 2006-06-13 at 03:45 -0400, Richard S. Hall wrote:
> John E. Conlon wrote:
> > Did not see a real need for Static property but how will this
> > change effect the ConfigurationProperty versus the DynamicProperty?
Guess I spoke too soon on the Static property not being needed - see
below.
>
> 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.
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> �
N' N'
Bono!
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?
> > 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.
It seems the only way to add handlers is to edit the IPojoConfiguration
class and compile them in.
Is there a way for a iPOJO bundle to submit a custom handler to the
componentManager at runtime?
John
Re: iPOJO and Configuration Admin Service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
Re: iPOJO and Configuration Admin Service
Posted by "John E. Conlon" <jc...@verticon.com>.
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
Re: iPOJO and Configuration Admin Service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
Re: iPOJO and Configuration Admin Service
Posted by "John E. Conlon" <jc...@verticon.com>.
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
Re: iPOJO and Configuration Admin Service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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.
Let us know if the latest changes resolve your remaining issues with
Config Admin support 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.
>
>> 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).
>
>>
>> 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, 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).
>
>
> Clement
>
>
Re: iPOJO and Configuration Admin Service
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
and thank you for the feedback.
>
> <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.
> 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).
>
> 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, 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).
Clement