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/03 03:21:41 UTC
ServiceBinder and configuration management
Have been using ServiceBinder to wrap components while experimenting
with the Configuration Admin service implementation that is in the
ApacheDS sandbox. ServiceBinder is cool but I am having problems
integrating its behavior with that of Configuration Admin.
When the configurations change in a backing store, the Configuration
Admin service will send those configuration changes to implementations
of ManagedService and ManagedServiceFactory.
My ServiceBinder component implements ManagedService so it receives
updates through the
updated(Dictionary configurationAdminProperties) method.
Thought that I could just update the ServiceBinders InstanceReference
properties to propagate these changes to the serviceRegistry, but
changing the InstanceReference properties has no effect on the
properties associated with my registered service. (With a handle to
ServiceRegistration I could set them there.)
How can I propagate these properties to the service registry from within
a serviceBinder component?
Does the Declarative Services already do this kind of integration with
Configuration Admin out of the box?
thanks any ideas,
John
Re: ServiceBinder and configuration management
Posted by "Richard S. Hall" <he...@ungoverned.org>.
John E. Conlon wrote:
> BTW - when will iPOJO show up in the felix svn trunk?
>
Hopefully, within the next day or so.
-> richard
> cheers,
> John
>
>
>
> On Wed, 2006-06-07 at 11:18 +0200, Clement Escoffier wrote:
>
>> Hello,
>>
>> The problem comes from the fact that iPOJO and your configuration admin
>> does not use the same org.osgi.service.cm.* classes.
>> IPOJO has its own og.osgi.service.cm package (packaged inside the iPOJO
>> bundle) and your config admin has an other package. I solve the problem
>> by adding an import and an export clause on iPOJO on
>> org.osgi.service.cm. The config admin and iPOJO need to use the same
>> classes to work.
>>
>> I deploy on my maven repository
>> (http://www-adele.imag.fr/~escoffie/repository/) the new version of
>> iPOJO (2.6) solving these problems.
>> Try to use it this new version (install the new iPOJO bundle with the
>> command :
>> install
>> http://www-adele.imag.fr/~escoffie/repository/org/apache/felix/ipojo/org.apache.felix.ipojo/2.6.0/org.apache.felix.ipojo-2.6.0.jar
>>
>> You can install the arch command too, to check the state of your
>> components :
>> install
>> http://www-adele.imag.fr/~escoffie/repository/org/apache/felix/ipojo/org.apache.felix.arch/2.6.0/org.apache.felix.arch-2.6.0.jar
>>
>> I hope this new version will solve your problem.
>>
>> Regards,
>>
>> Clement
>>
>>
>>
>> John E. Conlon a écrit :
>>
>>> Interesting to note the headers and the services of my experimental
>>> iPOJO EventHandler bundle. Look at the generated Import-Package it is
>>> missing the org.osgi.service.cm package yet:
>>> 1. services: shows that it offers org.osgi.service.cm.ManagedService
>>> 2. felix does not throw an error about missing a ManagedService
>>> 3. ApacheDS's ConfigurationAdmin implementations underlying
>>> ServiceBinder never sees the iPOJO's ManageService register with the
>>> framework???
>>>
>>> -> headers 23
>>>
>>> Fiona Experiment (23)
>>> ---------------------
>>> Archiver-Version = Plexus Archiver
>>> Build-Jdk = 1.5.0_06
>>> Built-By = jconlon
>>> Bundle-Activator = org.apache.felix.ipojo.Activator
>>> Bundle-Classpath = .,.
>>> Bundle-Description = Experiment to test ipojo and configuration admin.
>>> Bundle-Name = Fiona Experiment
>>> Bundle-Version = 1.0.SNAPSHOT
>>> Created-By = Apache Maven
>>> Extension-Name = ipojo.configuration
>>> Implementation-Title = ipojo.configuration
>>> Implementation-Version = 1.0-SNAPSHOT
>>> Import-Package = org.apache.felix.ipojo, org.osgi.service.event,
>>> org.slf4j
>>> iPOJO-Components = component { $architecture=true
>>> $name=com.verticon.experiment.ipojo.configuration
>>> $classname=com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler provides { $interface=org.osgi.service.event.EventHandler dynamicproperty { $name=event.topics $value=com/verticon/rfid/MOVEMENT $field=topics }}configurableproperty { $name=event.topics $field=topics }callback { $initial=INVALID $final=VALID $method=starting }callback { $initial=VALID $final=INVALID $method=stopping }manipulation { interface { $name=org.osgi.service.event.EventHandler }field { $name=topics $type=java.lang.String }}}
>>> iPOJO-Metadata = metadata.xml
>>> Manifest-Version = 1.0
>>> -> services 23
>>>
>>> Fiona Experiment (23) provides:
>>> -------------------------------
>>> Component Implementation Class =
>>> com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler
>>> objectClass = org.apache.felix.ipojo.architecture.Architecture
>>> service.id = 33
>>> ----
>>> event.topics = com/verticon/rfid/MOVEMENT
>>> objectClass = org.osgi.service.event.EventHandler
>>> service.id = 34
>>> ----
>>> objectClass = org.osgi.service.cm.ManagedService
>>> service.id = 35
>>> service.pid = com.verticon.experiment.ipojo.configuration
>>>
>>>
>>>
>>>
>>>
>>> And if I generate the importPackage myself like:
>>> <importPackage>org.osgi.framework,org.apache.felix.ipojo,org.osgi.service.event,org.slf4j,org.osgi.service.cm</importPackage>
>>> in the configuraiton of the org.apache.felix.ipojo.plugin. I then get
>>> the following exception thrown by the ConfigurationAdmin's
>>> ServiceBinder:
>>>
>>>
>>> ### DependencyManager : exception while invoking
>>> setManagedService :java.lang.IllegalArgumentException: argument type
>>> mismatch
>>> java.lang.IllegalArgumentException: argument type mismatch
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke
>>> (NativeMethodAccessorImpl.java:39)
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke
>>> (DelegatingMethodAccessorImpl.java:25)
>>> at java.lang.reflect.Method.invoke(Method.java:585)
>>> at org.apache.felix.servicebinder.InstanceManager
>>> $DependencyManager.callBindMethod(InstanceManager.java:1116)
>>> at org.apache.felix.servicebinder.InstanceManager
>>> $DependencyManager.serviceChanged(InstanceManager.java:980)
>>> at
>>> org.apache.felix.framework.util.ServiceListenerWrapper.serviceChanged
>>> (ServiceListenerWrapper.java:108)
>>> at org.apache.felix.framework.Felix$8.dispatch(Felix.java:3326)
>>> at org.apache.felix.framework.util.FelixDispatchQueue.dispatch
>>> (FelixDispatchQueue.java:76)
>>> at org.apache.felix.framework.Felix.fireServiceEvent
>>> (Felix.java:3338)
>>> at org.apache.felix.framework.Felix.access$100(Felix.java:33)
>>> at org.apache.felix.framework.Felix$1.serviceChanged
>>> (Felix.java:240)
>>> at org.apache.felix.framework.ServiceRegistry.fireServiceChanged
>>> (ServiceRegistry.java:408)
>>> at org.apache.felix.framework.ServiceRegistry.registerService
>>> (ServiceRegistry.java:69)
>>> at org.apache.felix.framework.Felix.registerService
>>> (Felix.java:2241)
>>> at org.apache.felix.framework.BundleContextImpl.registerService
>>> (BundleContextImpl.java:173)
>>> at org.apache.felix.framework.BundleContextImpl.registerService
>>> (BundleContextImpl.java:165)
>>> at
>>> org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.start
>>> (ConfigurationHandler.java:187)
>>> at org.apache.felix.ipojo.ComponentManager.start
>>> (ComponentManager.java:180)
>>> at org.apache.felix.ipojo.ComponentManagerFactory.start
>>> (ComponentManagerFactory.java:111)
>>> at org.apache.felix.ipojo.Activator.start(Activator.java:241)
>>> at org.apache.felix.ipojo.Activator.start(Activator.java:187)
>>> at org.apache.felix.framework.Felix._startBundle
>>> (Felix.java:1362)
>>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1296)
>>> at org.apache.felix.framework.Felix.setFrameworkStartLevel
>>> (Felix.java:737)
>>> at org.apache.felix.framework.StartLevelImpl.run
>>> (StartLevelImpl.java:179)
>>> at java.lang.Thread.run(Thread.java:595)
>>> DEBUG [FelixStartLevel]
>>> com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler.<init>(ConfiguribleEventHandler.java:17) - Constructed
>>> DEBUG [FelixStartLevel]
>>> com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler.starting(ConfiguribleEventHandler.java:21) - Starting
>>> ### DependencyManager : exception while invoking
>>> setManagedService :java.lang.IllegalArgumentException: argument type
>>> mismatch
>>> java.lang.IllegalArgumentException: argument type mismatch
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke
>>> (NativeMethodAccessorImpl.java:39)
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke
>>> (DelegatingMethodAccessorImpl.java:25)
>>> at java.lang.reflect.Method.invoke(Method.java:585)
>>> at org.apache.felix.servicebinder.InstanceManager
>>> $DependencyManager.callBindMethod(InstanceManager.java:1116)
>>> at org.apache.felix.servicebinder.InstanceManager
>>> $DependencyManager.serviceChanged(InstanceManager.java:980)
>>> at
>>> org.apache.felix.framework.util.ServiceListenerWrapper.serviceChanged
>>> (ServiceListenerWrapper.java:108)
>>> at org.apache.felix.framework.Felix$8.dispatch(Felix.java:3326)
>>> at org.apache.felix.framework.util.FelixDispatchQueue.dispatch
>>> (FelixDispatchQueue.java:76)
>>> at org.apache.felix.framework.Felix.fireServiceEvent
>>> (Felix.java:3338)
>>> at org.apache.felix.framework.Felix.access$100(Felix.java:33)
>>> at org.apache.felix.framework.Felix$1.serviceChanged
>>> (Felix.java:240)
>>> at org.apache.felix.framework.ServiceRegistry.fireServiceChanged
>>> (ServiceRegistry.java:408)
>>> at org.apache.felix.framework.ServiceRegistry.registerService
>>> (ServiceRegistry.java:69)
>>> at org.apache.felix.framework.Felix.registerService
>>> (Felix.java:2241)
>>> at org.apache.felix.framework.BundleContextImpl.registerService
>>> (BundleContextImpl.java:173)
>>> at org.apache.felix.framework.BundleContextImpl.registerService
>>> (BundleContextImpl.java:165)
>>> at
>>> org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.start
>>> (ConfigurationHandler.java:187)
>>> at
>>> org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.stateChanged(ConfigurationHandler.java:221)
>>> at org.apache.felix.ipojo.ComponentManager.setState
>>> (ComponentManager.java:214)
>>> at org.apache.felix.ipojo.ComponentManager.check
>>> (ComponentManager.java:439)
>>> at org.apache.felix.ipojo.ComponentManager.start
>>> (ComponentManager.java:184)
>>> at org.apache.felix.ipojo.ComponentManagerFactory.start
>>> (ComponentManagerFactory.java:111)
>>> at org.apache.felix.ipojo.Activator.start(Activator.java:241)
>>> at org.apache.felix.ipojo.Activator.start(Activator.java:187)
>>> at org.apache.felix.framework.Felix._startBundle
>>> (Felix.java:1362)
>>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1296)
>>> at org.apache.felix.framework.Felix.setFrameworkStartLevel
>>> (Felix.java:737)
>>> at org.apache.felix.framework.StartLevelImpl.run
>>> (StartLevelImpl.java:179)
>>> at java.lang.Thread.run(Thread.java:595)
>>>
>>>
>>> Clement or Richard any clues?
>>>
>>> John
>>>
>>>
>>> On Tue, 2006-06-06 at 14:57 -0500, John E. Conlon wrote:
>>>
>>>
>>>> On Tue, 2006-06-06 at 09:03 -0400, Richard S. Hall wrote:
>>>>
>>>>
>>>>> Also, if you are willing to play with more experimental stuff,
>>>>> iPOJO has
>>>>> some support for Config Admin:
>>>>>
>>>>>
>>>>> http://www-adele.imag.fr/~escoffie/dev/ipojo/using_iPOJO_component_model.html
>>>>>
>>>>> Search for "Configuration" and you should find some info under the
>>>>> "Other iPOJO features" section...
>>>>>
>>>>>
>>>> Not easy to refuse a chance to experiment with volatile substances, so I
>>>> downloaded the iPOJO plugin, bundle and tried building a iPOJO that
>>>> implements org.osgi.service.event.EventHandler and where the
>>>> event.topics property can be updated Configuration Admin.
>>>>
>>>> IPOJO seems like an easy way to do things.
>>>>
>>>> So with high hopes using the apacheDS's configurationAdmin implemenation
>>>> I configured the target bundle's event.topics to receive events from
>>>> another topic. Probably a set up snafu on my side but I couldnot pass
>>>> the new configuration to iPOJO component and get the eventHandler to
>>>> listen to a new topic.
>>>>
>>>>
>>>> Here is my metadata.xml
>>>>
>>>> <iPOJO>
>>>> <component
>>>> className="com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler"
>>>> name="com.verticon.experiment.ipojo.configuration"
>>>> architecture="true">
>>>>
>>>> <Provides>
>>>> <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>
>>>>
>>>> Am I setting up the metadata correctly?
>>>>
>>>> cheers,
>>>> John
>>>>
>>>>
>>>
>>>
>>>
>
>
>
Re: ServiceBinder and configuration management
Posted by "John E. Conlon" <jc...@verticon.com>.
Hi Clement,
Saw the problem yesterday after I sent out the email. So I downloaded
your source and just ripped out the org.osgi.service.cm.* from the
source and added an import for them. Your new 2.6.0 version also gets me
past the problem with loading the wrong classes.
Have encountered another problem with iPOJO and configuration management
but will send another email when I clarify it.
BTW - when will iPOJO show up in the felix svn trunk?
cheers,
John
On Wed, 2006-06-07 at 11:18 +0200, Clement Escoffier wrote:
> Hello,
>
> The problem comes from the fact that iPOJO and your configuration admin
> does not use the same org.osgi.service.cm.* classes.
> IPOJO has its own og.osgi.service.cm package (packaged inside the iPOJO
> bundle) and your config admin has an other package. I solve the problem
> by adding an import and an export clause on iPOJO on
> org.osgi.service.cm. The config admin and iPOJO need to use the same
> classes to work.
>
> I deploy on my maven repository
> (http://www-adele.imag.fr/~escoffie/repository/) the new version of
> iPOJO (2.6) solving these problems.
> Try to use it this new version (install the new iPOJO bundle with the
> command :
> install
> http://www-adele.imag.fr/~escoffie/repository/org/apache/felix/ipojo/org.apache.felix.ipojo/2.6.0/org.apache.felix.ipojo-2.6.0.jar
>
> You can install the arch command too, to check the state of your
> components :
> install
> http://www-adele.imag.fr/~escoffie/repository/org/apache/felix/ipojo/org.apache.felix.arch/2.6.0/org.apache.felix.arch-2.6.0.jar
>
> I hope this new version will solve your problem.
>
> Regards,
>
> Clement
>
>
>
> John E. Conlon a écrit :
> > Interesting to note the headers and the services of my experimental
> > iPOJO EventHandler bundle. Look at the generated Import-Package it is
> > missing the org.osgi.service.cm package yet:
> > 1. services: shows that it offers org.osgi.service.cm.ManagedService
> > 2. felix does not throw an error about missing a ManagedService
> > 3. ApacheDS's ConfigurationAdmin implementations underlying
> > ServiceBinder never sees the iPOJO's ManageService register with the
> > framework???
> >
> > -> headers 23
> >
> > Fiona Experiment (23)
> > ---------------------
> > Archiver-Version = Plexus Archiver
> > Build-Jdk = 1.5.0_06
> > Built-By = jconlon
> > Bundle-Activator = org.apache.felix.ipojo.Activator
> > Bundle-Classpath = .,.
> > Bundle-Description = Experiment to test ipojo and configuration admin.
> > Bundle-Name = Fiona Experiment
> > Bundle-Version = 1.0.SNAPSHOT
> > Created-By = Apache Maven
> > Extension-Name = ipojo.configuration
> > Implementation-Title = ipojo.configuration
> > Implementation-Version = 1.0-SNAPSHOT
> > Import-Package = org.apache.felix.ipojo, org.osgi.service.event,
> > org.slf4j
> > iPOJO-Components = component { $architecture=true
> > $name=com.verticon.experiment.ipojo.configuration
> > $classname=com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler provides { $interface=org.osgi.service.event.EventHandler dynamicproperty { $name=event.topics $value=com/verticon/rfid/MOVEMENT $field=topics }}configurableproperty { $name=event.topics $field=topics }callback { $initial=INVALID $final=VALID $method=starting }callback { $initial=VALID $final=INVALID $method=stopping }manipulation { interface { $name=org.osgi.service.event.EventHandler }field { $name=topics $type=java.lang.String }}}
> > iPOJO-Metadata = metadata.xml
> > Manifest-Version = 1.0
> > -> services 23
> >
> > Fiona Experiment (23) provides:
> > -------------------------------
> > Component Implementation Class =
> > com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler
> > objectClass = org.apache.felix.ipojo.architecture.Architecture
> > service.id = 33
> > ----
> > event.topics = com/verticon/rfid/MOVEMENT
> > objectClass = org.osgi.service.event.EventHandler
> > service.id = 34
> > ----
> > objectClass = org.osgi.service.cm.ManagedService
> > service.id = 35
> > service.pid = com.verticon.experiment.ipojo.configuration
> >
> >
> >
> >
> >
> > And if I generate the importPackage myself like:
> > <importPackage>org.osgi.framework,org.apache.felix.ipojo,org.osgi.service.event,org.slf4j,org.osgi.service.cm</importPackage>
> > in the configuraiton of the org.apache.felix.ipojo.plugin. I then get
> > the following exception thrown by the ConfigurationAdmin's
> > ServiceBinder:
> >
> >
> > ### DependencyManager : exception while invoking
> > setManagedService :java.lang.IllegalArgumentException: argument type
> > mismatch
> > java.lang.IllegalArgumentException: argument type mismatch
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at sun.reflect.NativeMethodAccessorImpl.invoke
> > (NativeMethodAccessorImpl.java:39)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke
> > (DelegatingMethodAccessorImpl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:585)
> > at org.apache.felix.servicebinder.InstanceManager
> > $DependencyManager.callBindMethod(InstanceManager.java:1116)
> > at org.apache.felix.servicebinder.InstanceManager
> > $DependencyManager.serviceChanged(InstanceManager.java:980)
> > at
> > org.apache.felix.framework.util.ServiceListenerWrapper.serviceChanged
> > (ServiceListenerWrapper.java:108)
> > at org.apache.felix.framework.Felix$8.dispatch(Felix.java:3326)
> > at org.apache.felix.framework.util.FelixDispatchQueue.dispatch
> > (FelixDispatchQueue.java:76)
> > at org.apache.felix.framework.Felix.fireServiceEvent
> > (Felix.java:3338)
> > at org.apache.felix.framework.Felix.access$100(Felix.java:33)
> > at org.apache.felix.framework.Felix$1.serviceChanged
> > (Felix.java:240)
> > at org.apache.felix.framework.ServiceRegistry.fireServiceChanged
> > (ServiceRegistry.java:408)
> > at org.apache.felix.framework.ServiceRegistry.registerService
> > (ServiceRegistry.java:69)
> > at org.apache.felix.framework.Felix.registerService
> > (Felix.java:2241)
> > at org.apache.felix.framework.BundleContextImpl.registerService
> > (BundleContextImpl.java:173)
> > at org.apache.felix.framework.BundleContextImpl.registerService
> > (BundleContextImpl.java:165)
> > at
> > org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.start
> > (ConfigurationHandler.java:187)
> > at org.apache.felix.ipojo.ComponentManager.start
> > (ComponentManager.java:180)
> > at org.apache.felix.ipojo.ComponentManagerFactory.start
> > (ComponentManagerFactory.java:111)
> > at org.apache.felix.ipojo.Activator.start(Activator.java:241)
> > at org.apache.felix.ipojo.Activator.start(Activator.java:187)
> > at org.apache.felix.framework.Felix._startBundle
> > (Felix.java:1362)
> > at org.apache.felix.framework.Felix.startBundle(Felix.java:1296)
> > at org.apache.felix.framework.Felix.setFrameworkStartLevel
> > (Felix.java:737)
> > at org.apache.felix.framework.StartLevelImpl.run
> > (StartLevelImpl.java:179)
> > at java.lang.Thread.run(Thread.java:595)
> > DEBUG [FelixStartLevel]
> > com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler.<init>(ConfiguribleEventHandler.java:17) - Constructed
> > DEBUG [FelixStartLevel]
> > com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler.starting(ConfiguribleEventHandler.java:21) - Starting
> > ### DependencyManager : exception while invoking
> > setManagedService :java.lang.IllegalArgumentException: argument type
> > mismatch
> > java.lang.IllegalArgumentException: argument type mismatch
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at sun.reflect.NativeMethodAccessorImpl.invoke
> > (NativeMethodAccessorImpl.java:39)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke
> > (DelegatingMethodAccessorImpl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:585)
> > at org.apache.felix.servicebinder.InstanceManager
> > $DependencyManager.callBindMethod(InstanceManager.java:1116)
> > at org.apache.felix.servicebinder.InstanceManager
> > $DependencyManager.serviceChanged(InstanceManager.java:980)
> > at
> > org.apache.felix.framework.util.ServiceListenerWrapper.serviceChanged
> > (ServiceListenerWrapper.java:108)
> > at org.apache.felix.framework.Felix$8.dispatch(Felix.java:3326)
> > at org.apache.felix.framework.util.FelixDispatchQueue.dispatch
> > (FelixDispatchQueue.java:76)
> > at org.apache.felix.framework.Felix.fireServiceEvent
> > (Felix.java:3338)
> > at org.apache.felix.framework.Felix.access$100(Felix.java:33)
> > at org.apache.felix.framework.Felix$1.serviceChanged
> > (Felix.java:240)
> > at org.apache.felix.framework.ServiceRegistry.fireServiceChanged
> > (ServiceRegistry.java:408)
> > at org.apache.felix.framework.ServiceRegistry.registerService
> > (ServiceRegistry.java:69)
> > at org.apache.felix.framework.Felix.registerService
> > (Felix.java:2241)
> > at org.apache.felix.framework.BundleContextImpl.registerService
> > (BundleContextImpl.java:173)
> > at org.apache.felix.framework.BundleContextImpl.registerService
> > (BundleContextImpl.java:165)
> > at
> > org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.start
> > (ConfigurationHandler.java:187)
> > at
> > org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.stateChanged(ConfigurationHandler.java:221)
> > at org.apache.felix.ipojo.ComponentManager.setState
> > (ComponentManager.java:214)
> > at org.apache.felix.ipojo.ComponentManager.check
> > (ComponentManager.java:439)
> > at org.apache.felix.ipojo.ComponentManager.start
> > (ComponentManager.java:184)
> > at org.apache.felix.ipojo.ComponentManagerFactory.start
> > (ComponentManagerFactory.java:111)
> > at org.apache.felix.ipojo.Activator.start(Activator.java:241)
> > at org.apache.felix.ipojo.Activator.start(Activator.java:187)
> > at org.apache.felix.framework.Felix._startBundle
> > (Felix.java:1362)
> > at org.apache.felix.framework.Felix.startBundle(Felix.java:1296)
> > at org.apache.felix.framework.Felix.setFrameworkStartLevel
> > (Felix.java:737)
> > at org.apache.felix.framework.StartLevelImpl.run
> > (StartLevelImpl.java:179)
> > at java.lang.Thread.run(Thread.java:595)
> >
> >
> > Clement or Richard any clues?
> >
> > John
> >
> >
> > On Tue, 2006-06-06 at 14:57 -0500, John E. Conlon wrote:
> >
> >> On Tue, 2006-06-06 at 09:03 -0400, Richard S. Hall wrote:
> >>
> >>> Also, if you are willing to play with more experimental stuff,
> >>> iPOJO has
> >>> some support for Config Admin:
> >>>
> >>>
> >>> http://www-adele.imag.fr/~escoffie/dev/ipojo/using_iPOJO_component_model.html
> >>>
> >>> Search for "Configuration" and you should find some info under the
> >>> "Other iPOJO features" section...
> >>>
> >> Not easy to refuse a chance to experiment with volatile substances, so I
> >> downloaded the iPOJO plugin, bundle and tried building a iPOJO that
> >> implements org.osgi.service.event.EventHandler and where the
> >> event.topics property can be updated Configuration Admin.
> >>
> >> IPOJO seems like an easy way to do things.
> >>
> >> So with high hopes using the apacheDS's configurationAdmin implemenation
> >> I configured the target bundle's event.topics to receive events from
> >> another topic. Probably a set up snafu on my side but I couldnot pass
> >> the new configuration to iPOJO component and get the eventHandler to
> >> listen to a new topic.
> >>
> >>
> >> Here is my metadata.xml
> >>
> >> <iPOJO>
> >> <component
> >> className="com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler"
> >> name="com.verticon.experiment.ipojo.configuration"
> >> architecture="true">
> >>
> >> <Provides>
> >> <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>
> >>
> >> Am I setting up the metadata correctly?
> >>
> >> cheers,
> >> John
> >>
> >
> >
> >
> >
>
Re: ServiceBinder and configuration management
Posted by Clement Escoffier <cl...@gmail.com>.
Hello,
The problem comes from the fact that iPOJO and your configuration admin
does not use the same org.osgi.service.cm.* classes.
IPOJO has its own og.osgi.service.cm package (packaged inside the iPOJO
bundle) and your config admin has an other package. I solve the problem
by adding an import and an export clause on iPOJO on
org.osgi.service.cm. The config admin and iPOJO need to use the same
classes to work.
I deploy on my maven repository
(http://www-adele.imag.fr/~escoffie/repository/) the new version of
iPOJO (2.6) solving these problems.
Try to use it this new version (install the new iPOJO bundle with the
command :
install
http://www-adele.imag.fr/~escoffie/repository/org/apache/felix/ipojo/org.apache.felix.ipojo/2.6.0/org.apache.felix.ipojo-2.6.0.jar
You can install the arch command too, to check the state of your
components :
install
http://www-adele.imag.fr/~escoffie/repository/org/apache/felix/ipojo/org.apache.felix.arch/2.6.0/org.apache.felix.arch-2.6.0.jar
I hope this new version will solve your problem.
Regards,
Clement
John E. Conlon a écrit :
> Interesting to note the headers and the services of my experimental
> iPOJO EventHandler bundle. Look at the generated Import-Package it is
> missing the org.osgi.service.cm package yet:
> 1. services: shows that it offers org.osgi.service.cm.ManagedService
> 2. felix does not throw an error about missing a ManagedService
> 3. ApacheDS's ConfigurationAdmin implementations underlying
> ServiceBinder never sees the iPOJO's ManageService register with the
> framework???
>
> -> headers 23
>
> Fiona Experiment (23)
> ---------------------
> Archiver-Version = Plexus Archiver
> Build-Jdk = 1.5.0_06
> Built-By = jconlon
> Bundle-Activator = org.apache.felix.ipojo.Activator
> Bundle-Classpath = .,.
> Bundle-Description = Experiment to test ipojo and configuration admin.
> Bundle-Name = Fiona Experiment
> Bundle-Version = 1.0.SNAPSHOT
> Created-By = Apache Maven
> Extension-Name = ipojo.configuration
> Implementation-Title = ipojo.configuration
> Implementation-Version = 1.0-SNAPSHOT
> Import-Package = org.apache.felix.ipojo, org.osgi.service.event,
> org.slf4j
> iPOJO-Components = component { $architecture=true
> $name=com.verticon.experiment.ipojo.configuration
> $classname=com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler provides { $interface=org.osgi.service.event.EventHandler dynamicproperty { $name=event.topics $value=com/verticon/rfid/MOVEMENT $field=topics }}configurableproperty { $name=event.topics $field=topics }callback { $initial=INVALID $final=VALID $method=starting }callback { $initial=VALID $final=INVALID $method=stopping }manipulation { interface { $name=org.osgi.service.event.EventHandler }field { $name=topics $type=java.lang.String }}}
> iPOJO-Metadata = metadata.xml
> Manifest-Version = 1.0
> -> services 23
>
> Fiona Experiment (23) provides:
> -------------------------------
> Component Implementation Class =
> com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler
> objectClass = org.apache.felix.ipojo.architecture.Architecture
> service.id = 33
> ----
> event.topics = com/verticon/rfid/MOVEMENT
> objectClass = org.osgi.service.event.EventHandler
> service.id = 34
> ----
> objectClass = org.osgi.service.cm.ManagedService
> service.id = 35
> service.pid = com.verticon.experiment.ipojo.configuration
>
>
>
>
>
> And if I generate the importPackage myself like:
> <importPackage>org.osgi.framework,org.apache.felix.ipojo,org.osgi.service.event,org.slf4j,org.osgi.service.cm</importPackage>
> in the configuraiton of the org.apache.felix.ipojo.plugin. I then get
> the following exception thrown by the ConfigurationAdmin's
> ServiceBinder:
>
>
> ### DependencyManager : exception while invoking
> setManagedService :java.lang.IllegalArgumentException: argument type
> mismatch
> java.lang.IllegalArgumentException: argument type mismatch
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.apache.felix.servicebinder.InstanceManager
> $DependencyManager.callBindMethod(InstanceManager.java:1116)
> at org.apache.felix.servicebinder.InstanceManager
> $DependencyManager.serviceChanged(InstanceManager.java:980)
> at
> org.apache.felix.framework.util.ServiceListenerWrapper.serviceChanged
> (ServiceListenerWrapper.java:108)
> at org.apache.felix.framework.Felix$8.dispatch(Felix.java:3326)
> at org.apache.felix.framework.util.FelixDispatchQueue.dispatch
> (FelixDispatchQueue.java:76)
> at org.apache.felix.framework.Felix.fireServiceEvent
> (Felix.java:3338)
> at org.apache.felix.framework.Felix.access$100(Felix.java:33)
> at org.apache.felix.framework.Felix$1.serviceChanged
> (Felix.java:240)
> at org.apache.felix.framework.ServiceRegistry.fireServiceChanged
> (ServiceRegistry.java:408)
> at org.apache.felix.framework.ServiceRegistry.registerService
> (ServiceRegistry.java:69)
> at org.apache.felix.framework.Felix.registerService
> (Felix.java:2241)
> at org.apache.felix.framework.BundleContextImpl.registerService
> (BundleContextImpl.java:173)
> at org.apache.felix.framework.BundleContextImpl.registerService
> (BundleContextImpl.java:165)
> at
> org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.start
> (ConfigurationHandler.java:187)
> at org.apache.felix.ipojo.ComponentManager.start
> (ComponentManager.java:180)
> at org.apache.felix.ipojo.ComponentManagerFactory.start
> (ComponentManagerFactory.java:111)
> at org.apache.felix.ipojo.Activator.start(Activator.java:241)
> at org.apache.felix.ipojo.Activator.start(Activator.java:187)
> at org.apache.felix.framework.Felix._startBundle
> (Felix.java:1362)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1296)
> at org.apache.felix.framework.Felix.setFrameworkStartLevel
> (Felix.java:737)
> at org.apache.felix.framework.StartLevelImpl.run
> (StartLevelImpl.java:179)
> at java.lang.Thread.run(Thread.java:595)
> DEBUG [FelixStartLevel]
> com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler.<init>(ConfiguribleEventHandler.java:17) - Constructed
> DEBUG [FelixStartLevel]
> com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler.starting(ConfiguribleEventHandler.java:21) - Starting
> ### DependencyManager : exception while invoking
> setManagedService :java.lang.IllegalArgumentException: argument type
> mismatch
> java.lang.IllegalArgumentException: argument type mismatch
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.apache.felix.servicebinder.InstanceManager
> $DependencyManager.callBindMethod(InstanceManager.java:1116)
> at org.apache.felix.servicebinder.InstanceManager
> $DependencyManager.serviceChanged(InstanceManager.java:980)
> at
> org.apache.felix.framework.util.ServiceListenerWrapper.serviceChanged
> (ServiceListenerWrapper.java:108)
> at org.apache.felix.framework.Felix$8.dispatch(Felix.java:3326)
> at org.apache.felix.framework.util.FelixDispatchQueue.dispatch
> (FelixDispatchQueue.java:76)
> at org.apache.felix.framework.Felix.fireServiceEvent
> (Felix.java:3338)
> at org.apache.felix.framework.Felix.access$100(Felix.java:33)
> at org.apache.felix.framework.Felix$1.serviceChanged
> (Felix.java:240)
> at org.apache.felix.framework.ServiceRegistry.fireServiceChanged
> (ServiceRegistry.java:408)
> at org.apache.felix.framework.ServiceRegistry.registerService
> (ServiceRegistry.java:69)
> at org.apache.felix.framework.Felix.registerService
> (Felix.java:2241)
> at org.apache.felix.framework.BundleContextImpl.registerService
> (BundleContextImpl.java:173)
> at org.apache.felix.framework.BundleContextImpl.registerService
> (BundleContextImpl.java:165)
> at
> org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.start
> (ConfigurationHandler.java:187)
> at
> org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.stateChanged(ConfigurationHandler.java:221)
> at org.apache.felix.ipojo.ComponentManager.setState
> (ComponentManager.java:214)
> at org.apache.felix.ipojo.ComponentManager.check
> (ComponentManager.java:439)
> at org.apache.felix.ipojo.ComponentManager.start
> (ComponentManager.java:184)
> at org.apache.felix.ipojo.ComponentManagerFactory.start
> (ComponentManagerFactory.java:111)
> at org.apache.felix.ipojo.Activator.start(Activator.java:241)
> at org.apache.felix.ipojo.Activator.start(Activator.java:187)
> at org.apache.felix.framework.Felix._startBundle
> (Felix.java:1362)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1296)
> at org.apache.felix.framework.Felix.setFrameworkStartLevel
> (Felix.java:737)
> at org.apache.felix.framework.StartLevelImpl.run
> (StartLevelImpl.java:179)
> at java.lang.Thread.run(Thread.java:595)
>
>
> Clement or Richard any clues?
>
> John
>
>
> On Tue, 2006-06-06 at 14:57 -0500, John E. Conlon wrote:
>
>> On Tue, 2006-06-06 at 09:03 -0400, Richard S. Hall wrote:
>>
>>> Also, if you are willing to play with more experimental stuff,
>>> iPOJO has
>>> some support for Config Admin:
>>>
>>>
>>> http://www-adele.imag.fr/~escoffie/dev/ipojo/using_iPOJO_component_model.html
>>>
>>> Search for "Configuration" and you should find some info under the
>>> "Other iPOJO features" section...
>>>
>> Not easy to refuse a chance to experiment with volatile substances, so I
>> downloaded the iPOJO plugin, bundle and tried building a iPOJO that
>> implements org.osgi.service.event.EventHandler and where the
>> event.topics property can be updated Configuration Admin.
>>
>> IPOJO seems like an easy way to do things.
>>
>> So with high hopes using the apacheDS's configurationAdmin implemenation
>> I configured the target bundle's event.topics to receive events from
>> another topic. Probably a set up snafu on my side but I couldnot pass
>> the new configuration to iPOJO component and get the eventHandler to
>> listen to a new topic.
>>
>>
>> Here is my metadata.xml
>>
>> <iPOJO>
>> <component
>> className="com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler"
>> name="com.verticon.experiment.ipojo.configuration"
>> architecture="true">
>>
>> <Provides>
>> <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>
>>
>> Am I setting up the metadata correctly?
>>
>> cheers,
>> John
>>
>
>
>
>
Re: ServiceBinder and configuration management
Posted by "John E. Conlon" <jc...@verticon.com>.
Interesting to note the headers and the services of my experimental
iPOJO EventHandler bundle. Look at the generated Import-Package it is
missing the org.osgi.service.cm package yet:
1. services: shows that it offers org.osgi.service.cm.ManagedService
2. felix does not throw an error about missing a ManagedService
3. ApacheDS's ConfigurationAdmin implementations underlying
ServiceBinder never sees the iPOJO's ManageService register with the
framework???
-> headers 23
Fiona Experiment (23)
---------------------
Archiver-Version = Plexus Archiver
Build-Jdk = 1.5.0_06
Built-By = jconlon
Bundle-Activator = org.apache.felix.ipojo.Activator
Bundle-Classpath = .,.
Bundle-Description = Experiment to test ipojo and configuration admin.
Bundle-Name = Fiona Experiment
Bundle-Version = 1.0.SNAPSHOT
Created-By = Apache Maven
Extension-Name = ipojo.configuration
Implementation-Title = ipojo.configuration
Implementation-Version = 1.0-SNAPSHOT
Import-Package = org.apache.felix.ipojo, org.osgi.service.event,
org.slf4j
iPOJO-Components = component { $architecture=true
$name=com.verticon.experiment.ipojo.configuration
$classname=com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler provides { $interface=org.osgi.service.event.EventHandler dynamicproperty { $name=event.topics $value=com/verticon/rfid/MOVEMENT $field=topics }}configurableproperty { $name=event.topics $field=topics }callback { $initial=INVALID $final=VALID $method=starting }callback { $initial=VALID $final=INVALID $method=stopping }manipulation { interface { $name=org.osgi.service.event.EventHandler }field { $name=topics $type=java.lang.String }}}
iPOJO-Metadata = metadata.xml
Manifest-Version = 1.0
-> services 23
Fiona Experiment (23) provides:
-------------------------------
Component Implementation Class =
com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler
objectClass = org.apache.felix.ipojo.architecture.Architecture
service.id = 33
----
event.topics = com/verticon/rfid/MOVEMENT
objectClass = org.osgi.service.event.EventHandler
service.id = 34
----
objectClass = org.osgi.service.cm.ManagedService
service.id = 35
service.pid = com.verticon.experiment.ipojo.configuration
And if I generate the importPackage myself like:
<importPackage>org.osgi.framework,org.apache.felix.ipojo,org.osgi.service.event,org.slf4j,org.osgi.service.cm</importPackage>
in the configuraiton of the org.apache.felix.ipojo.plugin. I then get
the following exception thrown by the ConfigurationAdmin's
ServiceBinder:
### DependencyManager : exception while invoking
setManagedService :java.lang.IllegalArgumentException: argument type
mismatch
java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.felix.servicebinder.InstanceManager
$DependencyManager.callBindMethod(InstanceManager.java:1116)
at org.apache.felix.servicebinder.InstanceManager
$DependencyManager.serviceChanged(InstanceManager.java:980)
at
org.apache.felix.framework.util.ServiceListenerWrapper.serviceChanged
(ServiceListenerWrapper.java:108)
at org.apache.felix.framework.Felix$8.dispatch(Felix.java:3326)
at org.apache.felix.framework.util.FelixDispatchQueue.dispatch
(FelixDispatchQueue.java:76)
at org.apache.felix.framework.Felix.fireServiceEvent
(Felix.java:3338)
at org.apache.felix.framework.Felix.access$100(Felix.java:33)
at org.apache.felix.framework.Felix$1.serviceChanged
(Felix.java:240)
at org.apache.felix.framework.ServiceRegistry.fireServiceChanged
(ServiceRegistry.java:408)
at org.apache.felix.framework.ServiceRegistry.registerService
(ServiceRegistry.java:69)
at org.apache.felix.framework.Felix.registerService
(Felix.java:2241)
at org.apache.felix.framework.BundleContextImpl.registerService
(BundleContextImpl.java:173)
at org.apache.felix.framework.BundleContextImpl.registerService
(BundleContextImpl.java:165)
at
org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.start
(ConfigurationHandler.java:187)
at org.apache.felix.ipojo.ComponentManager.start
(ComponentManager.java:180)
at org.apache.felix.ipojo.ComponentManagerFactory.start
(ComponentManagerFactory.java:111)
at org.apache.felix.ipojo.Activator.start(Activator.java:241)
at org.apache.felix.ipojo.Activator.start(Activator.java:187)
at org.apache.felix.framework.Felix._startBundle
(Felix.java:1362)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1296)
at org.apache.felix.framework.Felix.setFrameworkStartLevel
(Felix.java:737)
at org.apache.felix.framework.StartLevelImpl.run
(StartLevelImpl.java:179)
at java.lang.Thread.run(Thread.java:595)
DEBUG [FelixStartLevel]
com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler.<init>(ConfiguribleEventHandler.java:17) - Constructed
DEBUG [FelixStartLevel]
com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler.starting(ConfiguribleEventHandler.java:21) - Starting
### DependencyManager : exception while invoking
setManagedService :java.lang.IllegalArgumentException: argument type
mismatch
java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.felix.servicebinder.InstanceManager
$DependencyManager.callBindMethod(InstanceManager.java:1116)
at org.apache.felix.servicebinder.InstanceManager
$DependencyManager.serviceChanged(InstanceManager.java:980)
at
org.apache.felix.framework.util.ServiceListenerWrapper.serviceChanged
(ServiceListenerWrapper.java:108)
at org.apache.felix.framework.Felix$8.dispatch(Felix.java:3326)
at org.apache.felix.framework.util.FelixDispatchQueue.dispatch
(FelixDispatchQueue.java:76)
at org.apache.felix.framework.Felix.fireServiceEvent
(Felix.java:3338)
at org.apache.felix.framework.Felix.access$100(Felix.java:33)
at org.apache.felix.framework.Felix$1.serviceChanged
(Felix.java:240)
at org.apache.felix.framework.ServiceRegistry.fireServiceChanged
(ServiceRegistry.java:408)
at org.apache.felix.framework.ServiceRegistry.registerService
(ServiceRegistry.java:69)
at org.apache.felix.framework.Felix.registerService
(Felix.java:2241)
at org.apache.felix.framework.BundleContextImpl.registerService
(BundleContextImpl.java:173)
at org.apache.felix.framework.BundleContextImpl.registerService
(BundleContextImpl.java:165)
at
org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.start
(ConfigurationHandler.java:187)
at
org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler.stateChanged(ConfigurationHandler.java:221)
at org.apache.felix.ipojo.ComponentManager.setState
(ComponentManager.java:214)
at org.apache.felix.ipojo.ComponentManager.check
(ComponentManager.java:439)
at org.apache.felix.ipojo.ComponentManager.start
(ComponentManager.java:184)
at org.apache.felix.ipojo.ComponentManagerFactory.start
(ComponentManagerFactory.java:111)
at org.apache.felix.ipojo.Activator.start(Activator.java:241)
at org.apache.felix.ipojo.Activator.start(Activator.java:187)
at org.apache.felix.framework.Felix._startBundle
(Felix.java:1362)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1296)
at org.apache.felix.framework.Felix.setFrameworkStartLevel
(Felix.java:737)
at org.apache.felix.framework.StartLevelImpl.run
(StartLevelImpl.java:179)
at java.lang.Thread.run(Thread.java:595)
Clement or Richard any clues?
John
On Tue, 2006-06-06 at 14:57 -0500, John E. Conlon wrote:
> On Tue, 2006-06-06 at 09:03 -0400, Richard S. Hall wrote:
> > Also, if you are willing to play with more experimental stuff,
> > iPOJO has
> > some support for Config Admin:
> >
> >
> > http://www-adele.imag.fr/~escoffie/dev/ipojo/using_iPOJO_component_model.html
> >
> > Search for "Configuration" and you should find some info under the
> > "Other iPOJO features" section...
> Not easy to refuse a chance to experiment with volatile substances, so I
> downloaded the iPOJO plugin, bundle and tried building a iPOJO that
> implements org.osgi.service.event.EventHandler and where the
> event.topics property can be updated Configuration Admin.
>
> IPOJO seems like an easy way to do things.
>
> So with high hopes using the apacheDS's configurationAdmin implemenation
> I configured the target bundle's event.topics to receive events from
> another topic. Probably a set up snafu on my side but I couldnot pass
> the new configuration to iPOJO component and get the eventHandler to
> listen to a new topic.
>
>
> Here is my metadata.xml
>
> <iPOJO>
> <component
> className="com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler"
> name="com.verticon.experiment.ipojo.configuration"
> architecture="true">
>
> <Provides>
> <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>
>
> Am I setting up the metadata correctly?
>
> cheers,
> John
Re: ServiceBinder and configuration management
Posted by "John E. Conlon" <jc...@verticon.com>.
On Tue, 2006-06-06 at 09:03 -0400, Richard S. Hall wrote:
> Also, if you are willing to play with more experimental stuff,
> iPOJO has
> some support for Config Admin:
>
>
> http://www-adele.imag.fr/~escoffie/dev/ipojo/using_iPOJO_component_model.html
>
> Search for "Configuration" and you should find some info under the
> "Other iPOJO features" section...
Not easy to refuse a chance to experiment with volatile substances, so I
downloaded the iPOJO plugin, bundle and tried building a iPOJO that
implements org.osgi.service.event.EventHandler and where the
event.topics property can be updated Configuration Admin.
IPOJO seems like an easy way to do things.
So with high hopes using the apacheDS's configurationAdmin implemenation
I configured the target bundle's event.topics to receive events from
another topic. Probably a set up snafu on my side but I couldnot pass
the new configuration to iPOJO component and get the eventHandler to
listen to a new topic.
Here is my metadata.xml
<iPOJO>
<component
className="com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler"
name="com.verticon.experiment.ipojo.configuration"
architecture="true">
<Provides>
<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>
Am I setting up the metadata correctly?
cheers,
John
>
> -> richard
>
> John E. Conlon wrote:
> > Have been using ServiceBinder to wrap components while experimenting
> > with the Configuration Admin service implementation that is in the
> > ApacheDS sandbox. ServiceBinder is cool but I am having problems
> > integrating its behavior with that of Configuration Admin.
> >
> > When the configurations change in a backing store, the Configuration
> > Admin service will send those configuration changes to implementations
> > of ManagedService and ManagedServiceFactory.
> >
> > My ServiceBinder component implements ManagedService so it receives
> > updates through the
> > updated(Dictionary configurationAdminProperties) method.
> >
> > Thought that I could just update the ServiceBinders InstanceReference
> > properties to propagate these changes to the serviceRegistry, but
> > changing the InstanceReference properties has no effect on the
> > properties associated with my registered service. (With a handle to
> > ServiceRegistration I could set them there.)
> >
> > How can I propagate these properties to the service registry from within
> > a serviceBinder component?
> >
> > Does the Declarative Services already do this kind of integration with
> > Configuration Admin out of the box?
> >
> > thanks any ideas,
> > John
> >
> >
> >
>
Re: ServiceBinder and configuration management
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Also, if you are willing to play with more experimental stuff, iPOJO has
some support for Config Admin:
http://www-adele.imag.fr/~escoffie/dev/ipojo/using_iPOJO_component_model.html
Search for "Configuration" and you should find some info under the
"Other iPOJO features" section...
-> richard
John E. Conlon wrote:
> Have been using ServiceBinder to wrap components while experimenting
> with the Configuration Admin service implementation that is in the
> ApacheDS sandbox. ServiceBinder is cool but I am having problems
> integrating its behavior with that of Configuration Admin.
>
> When the configurations change in a backing store, the Configuration
> Admin service will send those configuration changes to implementations
> of ManagedService and ManagedServiceFactory.
>
> My ServiceBinder component implements ManagedService so it receives
> updates through the
> updated(Dictionary configurationAdminProperties) method.
>
> Thought that I could just update the ServiceBinders InstanceReference
> properties to propagate these changes to the serviceRegistry, but
> changing the InstanceReference properties has no effect on the
> properties associated with my registered service. (With a handle to
> ServiceRegistration I could set them there.)
>
> How can I propagate these properties to the service registry from within
> a serviceBinder component?
>
> Does the Declarative Services already do this kind of integration with
> Configuration Admin out of the box?
>
> thanks any ideas,
> John
>
>
>