rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jasha Joachimsthal <j.joachimst...@onehippo.com>
Subject Re: Handling database objects
Date Tue, 19 Jul 2011 20:44:34 GMT
On 19 July 2011 17:58, Ciancetta, Jesse E. <jcian@mitre.org> wrote:

> 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?
>

That's what SURFnet did too for the Shindig configuration but with a
different implementation: create a bridge between Guice and Spring so all
the (Java) webapps use Spring configurations. For the users (sysadmins in
this case) it's easier when they have one single way of configuring
databases instead of 2 different setups.

Jasha



> 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:j.joachimsthal@onehippo.com]
> >Sent: Tuesday, July 19, 2011 9:14 AM
> >To: rave-dev@incubator.apache.org
> >Subject: Re: Handling database objects
> >
> >On 19 July 2011 13:44, Franklin, Matthew B. <mfranklin@mitre.org> wrote:
> >
> >>
> >>
> >> On 7/19/11 3:29 AM, "Jasha Joachimsthal" <j.joachimsthal@onehippo.com>
> >> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message