You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Craig Phillips <lc...@praxiseng.com> on 2008/07/17 14:13:39 UTC
declarative services and configuration admin
Hi, good morning,
Maybe someone out there knows or has an idea of how configuration is
supposed to work within the context of declarative services and could
give me a one paragraph blurb and point me in the right direction...
I attempted to set up my bundle to provide the ManagedService and an
implementation of "updated(Dictionary)" thereof... My updated() method
was invoked twice with a null argument for Dictionary, even though I
provided a sample property key/value in the OSGI-INF entry;
If I use the net.luminis.cmc-0.2.1.jar and manually attempt to inject a
configuration property, I get the infamous "configuration already sent"
nag...
If I use a file based property a la the file persistence manager, I get
the same "configuration already sent" nag...
I then proceeded to obtain the ConfigurationAdmin service handle and
invoke the "update(Dictionary" method... besides hanging for quite some
time (I literally have to go to the TUI shell is issue a command like
"ps" or something to that effect to break the hang -- I have a number of
issues with TUI causing various functionality to hang, specifically
listen sockets);
I'm about to ditch declarative services and see if I can manually set
all this up... I figure that probably will work... I'm fairly certain
it's the SCR that's conflicting somehow... and, I suspect, if I get
around to reading those pages in the compendium spec, it'll probably be
my own ignorance somehow -- meaning, the SCR has somehow or another
wrapped up all the boiler plate and the end user is supposed to register
a setter method or something...
If someone out there has "felt my pain" and can steer me in the right
direction, much appreciated,
Thanks, Craig Phillips, Praxis
RE: declarative services and configuration admin
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
If you're interested in iPOJO, here is some links about the Configuration
Admin management:
The first link illustrates how an instance can expose a Managed Service
(managed by the iPOJO container), and so becomes reconfigurable:
http://felix.apache.org/site/ipojo-advanced-tutorial.html
The second link refer on the ability to create/dispose/reconfigure instances
with the configuration admin (Managed Service Factory):
http://felix.apache.org/site/combining-ipojo-and-configuration-admin.html
Regards,
Clement
-----Original Message-----
From: Karl Pauls [mailto:karlpauls@gmail.com]
Sent: jeudi 17 juillet 2008 21:39
To: dev@felix.apache.org
Subject: Re: declarative services and configuration admin
did you have a look at iPOJO already?
http://felix.apache.org/site/apache-felix-ipojo.html
and
http://felix.apache.org/site/presentations.data/ipojo-berlin-20080611.pdf
regards,
Karl
On Thu, Jul 17, 2008 at 5:53 PM, Craig Phillips
<lc...@praxiseng.com> wrote:
> Hi,
>
> After several days if fighting through this stuff, I can safely say that
> attempting to work with configuration a la declarative services is
> nothing short of a nightmare...
>
> I did get through the compendium spec, specifically the declarative
> services section, paying note to the various verbiage dealing with
> properties and configuration, all the while working with as yet
> developing exemplary code;
>
> a. In the service activation method (service, not bundle), the context
> does provide a getProperties(), for which you can consistently grab
> entries as defined in your SCR.XML instance (bundled in the dot.jar
> under OSGI-INF and referenced from the header manifest as per spec); Of
> course, what's the point of configuration items buried in the jar file,
> other than something that otherwise would have been hard wired in the
> code itself;
>
> b. In the bundle activation method (bundle, not service), or otherwise
> obtaining a service reference to ConfigurationAdmin (as in my case, via
> the SCR bind() method, invoked prior to service activation in the case
> of mandatory binding), I could use configAdmin.getConfiguration() and
> set a config item; In the service activation method, this added item
> would be present; So far, so good, albeit limited application;
>
> c. I was unable to get items a la FilePersistence service of cm.jar
> unless I replaced "configAdmin.getConfiguration()" with
> "configAdmin.createFactoryConfiguration()", at which point "b)" above
> stopped working; Not sure why "b)" and "c)" are mutually exclusive;
> Also, if I have TUI running, I must issue a command like "ps" or the
> createFactoryConfiguration() invocation will hang there indefinitely;
>
> d. As per the spec, I deem there is no way of getting configuration
> admin updates on demand... There is verbiage in the spec about
> overwrites and precedence, which seems to indicate to me rather strongly
> that I have no way to get updates other than to periodically check the
> context.getProperties() list and see if there's anything new or changed;
>
> e. If I attempt to set myself up as a ManagedService, while registered
> with SCR, all configuration admin updates are intercepted / aborted, a
> la the infamous "Configuration <my-pid> has already been delivered"
> message;
>
> If this is truly the design (of SCR), I consider it pretty unacceptable;
> In production, so far I've found nothing as prescribed to be more useful
> than the standard "System.getProperty()" vehicle; I think what is needed
> is for SCR to pass the updates through, best a la registered "setter()"
> method;
>
> Of course, that seems to be the vehicle of Spring-DM and I applaud;
>
> Again, there could be sprinkles of ignorance on my part... With that
> said, if I can get "System.getProperty()" up and running in minutes
> while I struggle through this stuff for days and days, well... I think I
> have made my point...
>
> Regards, how ever many lumps of sugar necessary... have a good day,
> respectfully, Craig
>
> -----Original Message-----
> From: Craig Phillips [mailto:lcphillips@praxiseng.com]
> Sent: Thursday, July 17, 2008 8:14 AM
> To: dev@felix.apache.org
> Subject: declarative services and configuration admin
>
> Hi, good morning,
>
> Maybe someone out there knows or has an idea of how configuration is
> supposed to work within the context of declarative services and could
> give me a one paragraph blurb and point me in the right direction...
>
> I attempted to set up my bundle to provide the ManagedService and an
> implementation of "updated(Dictionary)" thereof... My updated() method
> was invoked twice with a null argument for Dictionary, even though I
> provided a sample property key/value in the OSGI-INF entry;
>
> If I use the net.luminis.cmc-0.2.1.jar and manually attempt to inject a
> configuration property, I get the infamous "configuration already sent"
> nag...
>
> If I use a file based property a la the file persistence manager, I get
> the same "configuration already sent" nag...
>
> I then proceeded to obtain the ConfigurationAdmin service handle and
> invoke the "update(Dictionary" method... besides hanging for quite some
> time (I literally have to go to the TUI shell is issue a command like
> "ps" or something to that effect to break the hang -- I have a number of
> issues with TUI causing various functionality to hang, specifically
> listen sockets);
>
> I'm about to ditch declarative services and see if I can manually set
> all this up... I figure that probably will work... I'm fairly certain
> it's the SCR that's conflicting somehow... and, I suspect, if I get
> around to reading those pages in the compendium spec, it'll probably be
> my own ignorance somehow -- meaning, the SCR has somehow or another
> wrapped up all the boiler plate and the end user is supposed to register
> a setter method or something...
>
> If someone out there has "felt my pain" and can steer me in the right
> direction, much appreciated,
>
> Thanks, Craig Phillips, Praxis
>
>
--
Karl Pauls
karlpauls@gmail.com
Re: declarative services and configuration admin
Posted by Karl Pauls <ka...@gmail.com>.
did you have a look at iPOJO already?
http://felix.apache.org/site/apache-felix-ipojo.html
and
http://felix.apache.org/site/presentations.data/ipojo-berlin-20080611.pdf
regards,
Karl
On Thu, Jul 17, 2008 at 5:53 PM, Craig Phillips
<lc...@praxiseng.com> wrote:
> Hi,
>
> After several days if fighting through this stuff, I can safely say that
> attempting to work with configuration a la declarative services is
> nothing short of a nightmare...
>
> I did get through the compendium spec, specifically the declarative
> services section, paying note to the various verbiage dealing with
> properties and configuration, all the while working with as yet
> developing exemplary code;
>
> a. In the service activation method (service, not bundle), the context
> does provide a getProperties(), for which you can consistently grab
> entries as defined in your SCR.XML instance (bundled in the dot.jar
> under OSGI-INF and referenced from the header manifest as per spec); Of
> course, what's the point of configuration items buried in the jar file,
> other than something that otherwise would have been hard wired in the
> code itself;
>
> b. In the bundle activation method (bundle, not service), or otherwise
> obtaining a service reference to ConfigurationAdmin (as in my case, via
> the SCR bind() method, invoked prior to service activation in the case
> of mandatory binding), I could use configAdmin.getConfiguration() and
> set a config item; In the service activation method, this added item
> would be present; So far, so good, albeit limited application;
>
> c. I was unable to get items a la FilePersistence service of cm.jar
> unless I replaced "configAdmin.getConfiguration()" with
> "configAdmin.createFactoryConfiguration()", at which point "b)" above
> stopped working; Not sure why "b)" and "c)" are mutually exclusive;
> Also, if I have TUI running, I must issue a command like "ps" or the
> createFactoryConfiguration() invocation will hang there indefinitely;
>
> d. As per the spec, I deem there is no way of getting configuration
> admin updates on demand... There is verbiage in the spec about
> overwrites and precedence, which seems to indicate to me rather strongly
> that I have no way to get updates other than to periodically check the
> context.getProperties() list and see if there's anything new or changed;
>
> e. If I attempt to set myself up as a ManagedService, while registered
> with SCR, all configuration admin updates are intercepted / aborted, a
> la the infamous "Configuration <my-pid> has already been delivered"
> message;
>
> If this is truly the design (of SCR), I consider it pretty unacceptable;
> In production, so far I've found nothing as prescribed to be more useful
> than the standard "System.getProperty()" vehicle; I think what is needed
> is for SCR to pass the updates through, best a la registered "setter()"
> method;
>
> Of course, that seems to be the vehicle of Spring-DM and I applaud;
>
> Again, there could be sprinkles of ignorance on my part... With that
> said, if I can get "System.getProperty()" up and running in minutes
> while I struggle through this stuff for days and days, well... I think I
> have made my point...
>
> Regards, how ever many lumps of sugar necessary... have a good day,
> respectfully, Craig
>
> -----Original Message-----
> From: Craig Phillips [mailto:lcphillips@praxiseng.com]
> Sent: Thursday, July 17, 2008 8:14 AM
> To: dev@felix.apache.org
> Subject: declarative services and configuration admin
>
> Hi, good morning,
>
> Maybe someone out there knows or has an idea of how configuration is
> supposed to work within the context of declarative services and could
> give me a one paragraph blurb and point me in the right direction...
>
> I attempted to set up my bundle to provide the ManagedService and an
> implementation of "updated(Dictionary)" thereof... My updated() method
> was invoked twice with a null argument for Dictionary, even though I
> provided a sample property key/value in the OSGI-INF entry;
>
> If I use the net.luminis.cmc-0.2.1.jar and manually attempt to inject a
> configuration property, I get the infamous "configuration already sent"
> nag...
>
> If I use a file based property a la the file persistence manager, I get
> the same "configuration already sent" nag...
>
> I then proceeded to obtain the ConfigurationAdmin service handle and
> invoke the "update(Dictionary" method... besides hanging for quite some
> time (I literally have to go to the TUI shell is issue a command like
> "ps" or something to that effect to break the hang -- I have a number of
> issues with TUI causing various functionality to hang, specifically
> listen sockets);
>
> I'm about to ditch declarative services and see if I can manually set
> all this up... I figure that probably will work... I'm fairly certain
> it's the SCR that's conflicting somehow... and, I suspect, if I get
> around to reading those pages in the compendium spec, it'll probably be
> my own ignorance somehow -- meaning, the SCR has somehow or another
> wrapped up all the boiler plate and the end user is supposed to register
> a setter method or something...
>
> If someone out there has "felt my pain" and can steer me in the right
> direction, much appreciated,
>
> Thanks, Craig Phillips, Praxis
>
>
--
Karl Pauls
karlpauls@gmail.com
Re: declarative services and configuration admin
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Craig,
The best person to answer your questions about this topic is Felix
Meschberger, but I am fairly certain he is on vacation right now.
Perhaps you can wait until he is back in circulation...or hopefully
someone else can step up in his absence.
-> richard
Craig Phillips wrote:
> Hi,
>
> After several days if fighting through this stuff, I can safely say that
> attempting to work with configuration a la declarative services is
> nothing short of a nightmare...
>
> I did get through the compendium spec, specifically the declarative
> services section, paying note to the various verbiage dealing with
> properties and configuration, all the while working with as yet
> developing exemplary code;
>
> a. In the service activation method (service, not bundle), the context
> does provide a getProperties(), for which you can consistently grab
> entries as defined in your SCR.XML instance (bundled in the dot.jar
> under OSGI-INF and referenced from the header manifest as per spec); Of
> course, what's the point of configuration items buried in the jar file,
> other than something that otherwise would have been hard wired in the
> code itself;
>
> b. In the bundle activation method (bundle, not service), or otherwise
> obtaining a service reference to ConfigurationAdmin (as in my case, via
> the SCR bind() method, invoked prior to service activation in the case
> of mandatory binding), I could use configAdmin.getConfiguration() and
> set a config item; In the service activation method, this added item
> would be present; So far, so good, albeit limited application;
>
> c. I was unable to get items a la FilePersistence service of cm.jar
> unless I replaced "configAdmin.getConfiguration()" with
> "configAdmin.createFactoryConfiguration()", at which point "b)" above
> stopped working; Not sure why "b)" and "c)" are mutually exclusive;
> Also, if I have TUI running, I must issue a command like "ps" or the
> createFactoryConfiguration() invocation will hang there indefinitely;
>
> d. As per the spec, I deem there is no way of getting configuration
> admin updates on demand... There is verbiage in the spec about
> overwrites and precedence, which seems to indicate to me rather strongly
> that I have no way to get updates other than to periodically check the
> context.getProperties() list and see if there's anything new or changed;
>
> e. If I attempt to set myself up as a ManagedService, while registered
> with SCR, all configuration admin updates are intercepted / aborted, a
> la the infamous "Configuration <my-pid> has already been delivered"
> message;
>
> If this is truly the design (of SCR), I consider it pretty unacceptable;
> In production, so far I've found nothing as prescribed to be more useful
> than the standard "System.getProperty()" vehicle; I think what is needed
> is for SCR to pass the updates through, best a la registered "setter()"
> method;
>
> Of course, that seems to be the vehicle of Spring-DM and I applaud;
>
> Again, there could be sprinkles of ignorance on my part... With that
> said, if I can get "System.getProperty()" up and running in minutes
> while I struggle through this stuff for days and days, well... I think I
> have made my point...
>
> Regards, how ever many lumps of sugar necessary... have a good day,
> respectfully, Craig
>
> -----Original Message-----
> From: Craig Phillips [mailto:lcphillips@praxiseng.com]
> Sent: Thursday, July 17, 2008 8:14 AM
> To: dev@felix.apache.org
> Subject: declarative services and configuration admin
>
> Hi, good morning,
>
> Maybe someone out there knows or has an idea of how configuration is
> supposed to work within the context of declarative services and could
> give me a one paragraph blurb and point me in the right direction...
>
> I attempted to set up my bundle to provide the ManagedService and an
> implementation of "updated(Dictionary)" thereof... My updated() method
> was invoked twice with a null argument for Dictionary, even though I
> provided a sample property key/value in the OSGI-INF entry;
>
> If I use the net.luminis.cmc-0.2.1.jar and manually attempt to inject a
> configuration property, I get the infamous "configuration already sent"
> nag...
>
> If I use a file based property a la the file persistence manager, I get
> the same "configuration already sent" nag...
>
> I then proceeded to obtain the ConfigurationAdmin service handle and
> invoke the "update(Dictionary" method... besides hanging for quite some
> time (I literally have to go to the TUI shell is issue a command like
> "ps" or something to that effect to break the hang -- I have a number of
> issues with TUI causing various functionality to hang, specifically
> listen sockets);
>
> I'm about to ditch declarative services and see if I can manually set
> all this up... I figure that probably will work... I'm fairly certain
> it's the SCR that's conflicting somehow... and, I suspect, if I get
> around to reading those pages in the compendium spec, it'll probably be
> my own ignorance somehow -- meaning, the SCR has somehow or another
> wrapped up all the boiler plate and the end user is supposed to register
> a setter method or something...
>
> If someone out there has "felt my pain" and can steer me in the right
> direction, much appreciated,
>
> Thanks, Craig Phillips, Praxis
>
>
RE: declarative services and configuration admin
Posted by Craig Phillips <lc...@praxiseng.com>.
Hi,
After several days if fighting through this stuff, I can safely say that
attempting to work with configuration a la declarative services is
nothing short of a nightmare...
I did get through the compendium spec, specifically the declarative
services section, paying note to the various verbiage dealing with
properties and configuration, all the while working with as yet
developing exemplary code;
a. In the service activation method (service, not bundle), the context
does provide a getProperties(), for which you can consistently grab
entries as defined in your SCR.XML instance (bundled in the dot.jar
under OSGI-INF and referenced from the header manifest as per spec); Of
course, what's the point of configuration items buried in the jar file,
other than something that otherwise would have been hard wired in the
code itself;
b. In the bundle activation method (bundle, not service), or otherwise
obtaining a service reference to ConfigurationAdmin (as in my case, via
the SCR bind() method, invoked prior to service activation in the case
of mandatory binding), I could use configAdmin.getConfiguration() and
set a config item; In the service activation method, this added item
would be present; So far, so good, albeit limited application;
c. I was unable to get items a la FilePersistence service of cm.jar
unless I replaced "configAdmin.getConfiguration()" with
"configAdmin.createFactoryConfiguration()", at which point "b)" above
stopped working; Not sure why "b)" and "c)" are mutually exclusive;
Also, if I have TUI running, I must issue a command like "ps" or the
createFactoryConfiguration() invocation will hang there indefinitely;
d. As per the spec, I deem there is no way of getting configuration
admin updates on demand... There is verbiage in the spec about
overwrites and precedence, which seems to indicate to me rather strongly
that I have no way to get updates other than to periodically check the
context.getProperties() list and see if there's anything new or changed;
e. If I attempt to set myself up as a ManagedService, while registered
with SCR, all configuration admin updates are intercepted / aborted, a
la the infamous "Configuration <my-pid> has already been delivered"
message;
If this is truly the design (of SCR), I consider it pretty unacceptable;
In production, so far I've found nothing as prescribed to be more useful
than the standard "System.getProperty()" vehicle; I think what is needed
is for SCR to pass the updates through, best a la registered "setter()"
method;
Of course, that seems to be the vehicle of Spring-DM and I applaud;
Again, there could be sprinkles of ignorance on my part... With that
said, if I can get "System.getProperty()" up and running in minutes
while I struggle through this stuff for days and days, well... I think I
have made my point...
Regards, how ever many lumps of sugar necessary... have a good day,
respectfully, Craig
-----Original Message-----
From: Craig Phillips [mailto:lcphillips@praxiseng.com]
Sent: Thursday, July 17, 2008 8:14 AM
To: dev@felix.apache.org
Subject: declarative services and configuration admin
Hi, good morning,
Maybe someone out there knows or has an idea of how configuration is
supposed to work within the context of declarative services and could
give me a one paragraph blurb and point me in the right direction...
I attempted to set up my bundle to provide the ManagedService and an
implementation of "updated(Dictionary)" thereof... My updated() method
was invoked twice with a null argument for Dictionary, even though I
provided a sample property key/value in the OSGI-INF entry;
If I use the net.luminis.cmc-0.2.1.jar and manually attempt to inject a
configuration property, I get the infamous "configuration already sent"
nag...
If I use a file based property a la the file persistence manager, I get
the same "configuration already sent" nag...
I then proceeded to obtain the ConfigurationAdmin service handle and
invoke the "update(Dictionary" method... besides hanging for quite some
time (I literally have to go to the TUI shell is issue a command like
"ps" or something to that effect to break the hang -- I have a number of
issues with TUI causing various functionality to hang, specifically
listen sockets);
I'm about to ditch declarative services and see if I can manually set
all this up... I figure that probably will work... I'm fairly certain
it's the SCR that's conflicting somehow... and, I suspect, if I get
around to reading those pages in the compendium spec, it'll probably be
my own ignorance somehow -- meaning, the SCR has somehow or another
wrapped up all the boiler plate and the end user is supposed to register
a setter method or something...
If someone out there has "felt my pain" and can steer me in the right
direction, much appreciated,
Thanks, Craig Phillips, Praxis
Re: declarative services and configuration admin
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Craig,
Sorry to only be able to follow up on this now (I was as Richard said
ways for vacation).
So here is, what you are looking for:
Felix SCR registers a ManagedService[Factory] for each declared
Component[Factory] with the service.pid property set to the component
name. This ManagedService[Factory] receives configuration updates from
the ConfigurationAdmin on behalf of the component and forwards the
configuration to the component appropriately:
- Components are deactivated and activated
- ComponentFactory have their newInstance method called
(or delete method if a Configuration was deleted)
This is what the spec on Declarative Services says should be done by the
implementation. The spec also says, that components should not (or is it
must not ?) register a ManagedService[Factory] service themselves --
because the Declarative Services implementation is providing the
configuration.
The spec also sais, how the Dictionary returned by
ComponentContext.getProperties() must be filled: with the component
declaration properties overlaid with the properties from the
Configuration Admin (if any).
In short: your component does not have to care about getting the
configuration from the Configuration Admin. It is provided by the
Declarative Services implementation in the ComponentContext given to the
activate method.
This works quite well and in fact Apache Sling heavily relies on this
functionality.
Hope this helps.
Regards
Felix
Craig Phillips schrieb:
> Hi, good morning,
>
> Maybe someone out there knows or has an idea of how configuration is
> supposed to work within the context of declarative services and could
> give me a one paragraph blurb and point me in the right direction...
>
> I attempted to set up my bundle to provide the ManagedService and an
> implementation of "updated(Dictionary)" thereof... My updated() method
> was invoked twice with a null argument for Dictionary, even though I
> provided a sample property key/value in the OSGI-INF entry;
>
> If I use the net.luminis.cmc-0.2.1.jar and manually attempt to inject a
> configuration property, I get the infamous "configuration already sent"
> nag...
>
> If I use a file based property a la the file persistence manager, I get
> the same "configuration already sent" nag...
>
> I then proceeded to obtain the ConfigurationAdmin service handle and
> invoke the "update(Dictionary" method... besides hanging for quite some
> time (I literally have to go to the TUI shell is issue a command like
> "ps" or something to that effect to break the hang -- I have a number of
> issues with TUI causing various functionality to hang, specifically
> listen sockets);
>
> I'm about to ditch declarative services and see if I can manually set
> all this up... I figure that probably will work... I'm fairly certain
> it's the SCR that's conflicting somehow... and, I suspect, if I get
> around to reading those pages in the compendium spec, it'll probably be
> my own ignorance somehow -- meaning, the SCR has somehow or another
> wrapped up all the boiler plate and the end user is supposed to register
> a setter method or something...
>
> If someone out there has "felt my pain" and can steer me in the right
> direction, much appreciated,
>
> Thanks, Craig Phillips, Praxis
>
>