felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clement Escoffier" <clement.escoff...@gmail.com>
Subject RE: declarative services and configuration admin
Date Sat, 19 Jul 2008 07:30:24 GMT

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:

The second link refer on the ability to create/dispose/reconfigure instances
with the configuration admin (Managed Service Factory): 



-----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?






On Thu, Jul 17, 2008 at 5:53 PM, Craig Phillips
<lcphillips@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

View raw message