So, what if we add a separate method called override that allowed you override the values in the blur-site / blur-default files? And then you could call that after the base constructor is called?
Also that would just a be a shortcut for calling config.set(name,value) which you can do now (I think). Would either of these solve the issue? I think that an improvement to MiniCluster would be to random choose ports for the Blur thrift servers to bind to automatically. This is how the HDFS mini cluster works. Aaron On Wed, Sep 19, 2012 at 10:55 PM, Aaron McCurry <[email protected]> wrote: > What would you suggest we do even if it's not backwards compatible? > > > On Wed, Sep 19, 2012 at 10:21 PM, Tim Williams <[email protected]>wrote: > >> On Wed, Sep 19, 2012 at 10:12 PM, Tim Williams <[email protected]> >> wrote: >> > I'm working BLUR-23[1] and running into an issue with configs. >> > BlurConfiguration currently initializes all defaults in the >> > constructor. This makes it impossible to merge a few user overrides >> > on top of the defaults. If the user wants to pass a >> > BlurConfiguration, they currently have to own the whole thing. The >> > only clean way I can see to move to allowing this while maintaining >> > compatibility is to create a new constructor allowing passing in >> > overrides.. (e.g. BlurConfiguration(BlurConfiguration overrides). >> > Another solution might be to just add a "merge(BlurConfiguration >> > overrides)" method, I suppose. >> >> Sorry, i take it back. Because we initialize the defaults in the >> default constructor (which the caller would have used) - I don't see a >> way of allowing overrides in the existing paradigm through either >> methods or constructors - in a backwards compatible way, at least. >> Thoughts? >> >> --tim >> > >
