On Tue, May 27, 2008 at 11:22 AM, Jamey Wood <[EMAIL PROTECTED]> wrote:
> Is there some easy way to add one's own processing logic for container
> config files? Until recently, ContainerConfig.loadFromString(String json)
> was a public method. So we subclassed ContainerConfig and overrode this
> method to tie-in our own pre-processing logic (basically expanding
> ${xyz}-style references to properties that are defined in our env) before
> passing the resulting string on via super.loadFromString(myProcessedJson).
> But that no longer works, since this method is now private in Shindig. I
> don't see any obvious way to do something similar now (without duplicating a
> lot of ContainerConfig's logic ourselves).
loadFromString can be made public again, though we'd need an alternative
locking mechanism so that inheritance could work. The primary motivation for
this change was to make it so that containers could add new inheriting
configuration without having to maintain a patch against the default, so
anything that preserves that would be fine.
What you're describing was actually brought up before (performing
substitution on container configs), but demand was low so it wasn't
investigated further. It's a useful generalization, in any case, and I know
I have a few uses for it that we're working around through a bunch of
copying.
Since you're just doing expansion, loadFromString can probably just be made
protected without causing any real issues.
>
> Thanks,
> Jamey
>
