On Tue, Dec 15, 2009 at 4:48 PM, Raymond Feng <[email protected]> wrote: > A few of PMC members including me are out for vacation. Would it be possible > that we hold off some of the changes?
Sure, did you see the other email about not changing the existing modules while people are out? >>> Some to remove: >>> - all the ones using classloaders >>> - the Client Interface and just add the getService method to Node >>> - the destroy method >>> - the getInstance(String domainURI) as there's the createNode that >>> includes the URI >>> > > +1. Do you plan to have a Helper that can be used to populate > NodeConfiguration from the resource and classloader? > Not unless someone has a good use case for needing it. (and then if they do I'd wonder why the methods to support it wouldn't go in the actual API classes instead of a helper) >> >> Another method to consider for removal is the Node start() method. I >> don't see why is thats needed now as after a node is created you can >> do nothing except start or stop it so it might as well just be created >> in the started state. If for some reason the was a need to pass around >> an unstarted Node you can just pass around a NodeConfiguration >> instead. >> > > I prefer to keep the start() method for a few reasons: > 1) symmetric with stop(): users of the API will remember to call stop() if > they call start(). > 2) consistent with the other SPIs that involve the lifecycle management, > such as LifeCycleListener > 3) the start/stop can be potentially exposed to management layer > What would the management layer do with it? If there's a use case then fine, but right now there's not much useful you can do. If we do keep a separate start() then I'd like to be able to add other methods to Node so you can do configuration directly on the Node before starting it, eg node=NodeFactory.createNode(); node.addContribution(contribution); node.start(); ...ant
