The patch I sent in late last night / early this morning allows you to
re-define a feature that's already been registered. I did this specifically
to address the problem you're probably finding yourself with now.
If you already have your own CrossServletState implementation (which you
probably should to replace the security token, if nothing else), just make a
second call to loadFeatures with your custom implementation (using the same
name, it will overwrite it) This winds up looking something like this:
GadgetFeatureRegistry registry = new
GadgetFeatureRegistry("res://features/features.txt");
registry.loadFeatures("res://mydata/opensocial-0.7/feature.xml");
If you don't have your own CrossServletState, the easiest way is to rename
your feature (something like features/opensocial-0.7-custom/feature.xml),
and then add it to the features.txt list (don't change the file contents).
What this will cause to happen is that opensocial-0.7 will get loaded, and
then your feature will come along and overwrite it.
Not the cleanest solution in the world, but it's probably the best we can do
other than requiring actually overwriting the file and keeping that in sync.
On Fri, Feb 22, 2008 at 3:25 PM, Brian McCallister <[EMAIL PROTECTED]> wrote:
> So I went to pull in the newest shindig code and bring my container up to
> date against it and notice a shiny JsonContainer in the "opensocial-0.7"
> feature. I am a bit confused about the best way implement another
> container
> based on Shindig with that container taking that feature name...
>
> What *is* the right way?
>
> -Brian
>
--
~Kevin
If you received this email by mistake, please delete it, cancel your mail
account, destroy your hard drive, silence any witnesses, and burn down the
building that you're in.
