Custom Processing of Container Config Files?

[Jamey Wood <Ja...@sun.com>]

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).

Thanks,
Jamey

Re: Custom Processing of Container Config Files?

[Jamey Wood <Ja...@sun.com>]

Kevin Brown wrote:
> On Tue, May 27, 2008 at 11:22 AM, Jamey Wood <Ja...@sun.com> 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).
>>     
>
> Since you're just doing expansion, loadFromString can probably just be made
> protected without causing any real issues.
>   

Yep, that handles my case perfectly.  Thanks!

--Jamey

Re: Custom Processing of Container Config Files?

[Kevin Brown <et...@google.com>]

On Tue, May 27, 2008 at 11:22 AM, Jamey Wood <Ja...@sun.com> 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
>