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:[EMAIL PROTECTED] 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
