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: >> >>> Thanks, I overlooked this signature. However, it seems only to solve >>> my case partially as I do not get the updated on the callback handler. >>> A quick look at the code seems to indicate that the >>> ConfigurationDependency does not consider the callbackhandler(?) I >>> guess if this where the case indeed this mechanism would allow me to >>> fully seperate business and service logic and create the factory I am >>> looking for. >> >> The callback handler you set is for the (init, start, stop and destroy) life >> cycle methods of the component. Dependencies have their own callbacks and >> can also get their own callback handlers. For example, take a look at a >> service dependency, it also has a setCallbacks() method and does support a >> callback handler. >> >> Currently, configuration dependencies do not support such a method, but I >> think it is worth considering adding this as an extension. > > 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. >> 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. 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.). 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). Greetings, Marcel --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
