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:[EMAIL PROTECTED] Sent: jeudi 17 juillet 2008 21:39 To: [email protected] 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > Sent: Thursday, July 17, 2008 8:14 AM > To: [email protected] > 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 [EMAIL PROTECTED]
