felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: declarative services and configuration admin
Date Thu, 17 Jul 2008 19:18:15 GMT
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
>
>   

Mime
View raw message