When I wrote all of the Shindig extensions we use internally I stuck with using Spring to manage all of those components and used the Spring integration provided by Guice to get instances of those beans out of the Spring ApplicationContext and Guice inject them into the Shindig components that need them. I thought this worked out pretty well and wouldn't mind seeing this model continue in Rave as well -- since our container is Spring based it would seem to make sense to keep things consistent on the shindig side if we can.
Anyone else have an opinion one way or another? Here is the doc for the Guice SpringIntegration class I used: http://google-guice.googlecode.com/svn/trunk/javadoc/com/google/inject/spring/SpringIntegration.html and here are some snippets of code which should give enough of a sense of how I used it: ---- public class SampleGuiceModule extends AbstractModule { //This module gets service object instances from Spring, but doesnt have any easy way to get access to the //ApplicationContext that was created by the Spring ContextLoaderListener since we dont have any access to the //ServletContext (since we arent a Servletish object). We want to use that context because we dont want to end //up having multiple instances of our service objects -- so we provide this static field and wrap a setter around //it so that our SpringContextListener can set a reference to the Spring ApplicationContext for us. private static ApplicationContext applicationContext; public void configure() { try { bind(BeanFactory.class).toInstance(applicationContext); bind(GadgetService.class).toProvider(SpringIntegration.fromSpring(GadgetService.class, "gadgetService")); bind(AppDataService.class).toProvider(SpringIntegration.fromSpring(AppDataService.class, "appDataService")); bind(PersonService.class).toProvider(SpringIntegration.fromSpring(PersonService.class, "personService")); bind(ActivityService.class).toProvider(SpringIntegration.fromSpring(ActivityService.class, "activityService")); } catch (Exception e) { logger.error("Caught an exception while trying to configure SampleGuiceModule!", e); } } public static void setApplicationContext(ApplicationContext applicationContext) { SampleGuiceModule.applicationContext = applicationContext; } } ---- public class SpringContextListener implements ServletContextListener { public void contextInitialized(ServletContextEvent servletContextEvent) { //Our Sample Guice module needs to be able to pull objects out of our Spring ApplicationContext, but it doesnt //have access to a ServletContext to grab it from, and we dont want it to create its own separate context. //Grab the Spring ApplicationContext from the ServletContext that was put there by the Spring ContextLoaderListener //and pass it to our Sample guice module so it can use it when it runs. ApplicationContext applicationContext = WebApplicationContextUtils.getRequiredWebApplicationContext(servletContextEvent.getServletContext()); SampleGuiceModule.setApplicationContext(applicationContext); } } ---- >-----Original Message----- >From: Jasha Joachimsthal [mailto:[email protected]] >Sent: Tuesday, July 19, 2011 9:14 AM >To: [email protected] >Subject: Re: Handling database objects > >On 19 July 2011 13:44, Franklin, Matthew B. <[email protected]> wrote: > >> >> >> On 7/19/11 3:29 AM, "Jasha Joachimsthal" <[email protected]> >> wrote: >> >> >I'm still working on storing OAuth information in the database (almost >> >done >> >now). I see a difference in handling database objects/queries between the >> >rave-portal module and the rave-shindig module. >> >All rave-portal beans implement o.a.rave.portal.model.BasicEntity while >> >all >> >rave-shindig beans implement >> >o.a.shindig.social.opensocial.jpa.api.DbObject. >> >In rave-portal all classes that handle DB queries implement >> >o.a.rave.portal.repository.Repository and are configured through Spring. >> >The >> >Repository implementations extend AbstractJpaRepository which supports >at >> >simple CRD operations. The Repository implementations have test classes. >> >In rave-shindig there seems to be no common interface and injection is >> >done >> >through Guice (the @Injects are commented out btw). Tests are missing. >> > >> >Is there someone who has time (and knowledge) to create a common >basis for >> >database operations in both modules and set up tests for DB operations >> >rave-shindig? >> >> I will update the ticket for adding unit tests to rave-shindig to >> replicate the rave-portal JPA pattern to rave-shindig. Probably the >> easiest thing to do is create a rave-common project under trunk and start >> putting this pattern and any other common code in that project. I can >> take this on after I finish canvas/home view toggling. >> > >Thanks :) I'm currently trying to inject the database config for the OAuth >persistence through a Guice module in the rave-shindig project (since >shindig relies on Guice instead of Spring). I hope to wrap it up before my >holiday (end of this week). > >Jasha
