On Wed, Apr 2, 2008 at 9:20 PM, Raymond Auge <[EMAIL PROTECTED]> 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. > > But that's not a very nice way of working with it. At the very least we > need some way to wire in an implementation. This way you could have X > backends bundled to handle the different possible scenarios, direct > JDBC, DAO Service Tier, RPC implementation, etc, while still allowing > for custom implementations. > > In our case, we're plugging in directly to our generated DAO service > tier, so as to leverage existing caching infrastructure, cluster > support, etc..., which means we'd want to implement the backend as a > custom code anyway. > > The question is "which is the most accepted way of building out these > plug-able backend implementations?" > > You can go anywhere from > - classNames as servlet init-params in the web.xml file > - classpath properties files specifying implementation classes > ... all the way to ... > - a Dependency Injection container like Spring... The DI wiring is already started (as of about 5pm today), using Guice. Spring or other frameworks can be layered on top of this as appropriate. Again, though, this only satisfies the case of sites that are already Java based. -- ~Kevin
