On Mon, Nov 22, 2010 at 2:37 PM, Marcel Offermans <[email protected]> wrote: > On 22 Nov 2010, at 13:59 , Bram de Kruijff wrote: > >> On Mon, Nov 22, 2010 at 11:34 AM, Marcel Offermans >> <[email protected]> wrote: >>> On 22 Nov 2010, at 10:52 , Bram de Kruijff wrote: >>> >> I'd like it considered :) If it would be possible to delegate to a >> callbackhandler I would be able to seperate business from plumbing >> (see motivation below) and it would clear a path for recieving >> configuration before instantation of the serviceimpl by the factory. >> Right? I may be cutting some corners here ;) > > Fair enough, could you please create a JIRA issue for me, so I won't forget.
Created the "wish" under FELIX-2706 >>> The question I have for you is, is the validation of a configuration part >>> of your business logic, or considered "OSGi plumbing" (what you call >>> "service logic")? >> >> I consider validation of the configuration values (eg. does a passed >> in directory exist) part of the business logic. However, the delivery >> mechanism of updated(Dictionary dict) and validation of that (eg. does >> the dict contain my required key/value) is OSGi plumbing. I would much >> rather have my business logic deal with constructor or setter based >> injection giving me a much cleaner (typed) mechnism. > > Ok. As a note, we did relax the requirements for this mechanism in the sense > that: > > a) the object does not need to implement ManagedService, just having an > updated(Dictionary) method is enough; > b) you can override the name of the method, so it can have "any name", and > throw "any exception" but it still takes a Dictionary. > > With the callback instance you could add a class that takes the Dictionary > and transforms it to calls to setters (constructor is a bit more tricky). > However, one can argue if setter based injection is indeed cleaner, because > you completely loose the transactional nature of the current update mechanism > as one configuration update might lead to multiple non-related calls to > setters, leading to all kinds of invalid intermediate configuration states > when going from one configuration to the next. The setters of the Date class > in Java are perhaps the classic example here of bad design. This may certainly be true in some cases but I dont think it applies to my "factory use case". Still it does make me wonder.. should I be able to (temporarily) deregister my component onUpdate? Not entirely clear on the current implementation, but... should I be able to deregister the service during the configuration update or even entirely because the new configuration tells me so and then maybe reregister when a new configuration with appropriate values pops up? > Some related alternatives: > > 1) Take a look at the Metatype provider as a way to provide a lot more > information about what is expected from a configuration (required keys, > datatypes, descriptions, etc.). Don't think metatype realy solves my concern (more plumbing / still get a Dictionary) > 2) Get the OSGi 4.3 early draft 2 and look at the proposed changes in > Configuration Admin. It specifically discusses a more "user friendly > configuration" (in 5.4) and you might want to design a mechanism that is > compatible with that (with the usual disclaimers since the API is obviously > still a draft). I'll have a look! Thanks again, Bram --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
