Would, longer term the intention be to define the services in a Guice
Module that was referenced in the web.xml ?
<context-param>
<param-name>guice-modules</param-name>
<param-value>org.apache.shindig.gadgets.http.HttpGuiceModule:org.apache.shindig.gadgets.DefaultServiceModule</param-value>
</context-param>
or, for a custom service impl
<context-param>
<param-name>guice-modules</param-name>
<param-value>org.apache.shindig.gadgets.http.HttpGuiceModule:org.sakaiproject.shindig.SakaiServiceModule</param-value>
</context-param>
Or is that the wrong way to do it? ... just feeling my way in the dark.
Ian
On 03/04/2008, Ross Gardler <[EMAIL PROTECTED]> wrote:
> Raymond Auge wrote:
>
> > The shindig plugin we developed works as a fire and forget app in all
> > the app server/servlet containers/RDBMS combinations that we support
> > (which is extensive, literally hundreds of combinations).
> >
> > What we're missing is that "injectable" datasource backend.
> >
> > Right now I'm flat out replacing the implementation of
> >
> org.apache.shindig.social.opensocial.OpenSocialDataHandler
> >
> > overriding the implementations of the Basic*Services.
> >
>
> It's a long way from perfect, but a really quick solution (for Java folk)
> is in the patch attached to SHINDIG-154. This allows the Basic*Sevices to be
> replaced by local classes defined in web.xml
>
> In our implmentation we have added our own services that talk to our
> existng back-end via the REST API, transform the data to the right XML
> format and then let shindig get on with it.
>
> It's quick and dirty, but it's simple and works.
>
> Ross
>
