cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Huss <johnth...@gmail.com>
Subject Re: Reuse of code. Global ServerRuntime?
Date Sun, 14 Feb 2016 14:16:43 GMT
It's your responsibility.

You can't get the runtime that way, but you probably don't need to (except
for your existing code!). The injector has everything you'd need except the
runtime itself.
On Sun, Feb 14, 2016 at 8:02 AM Hugi Thordarson <hugi@karlmenn.is> wrote:

> Thanks John, I had no idea getThreadObjectContext() existed. Does Cayenne
> somehow manage this variable or is it solely my responsibility?
>
> It isn’t quite exactly what I’m looking for, though—ideally, the method
> I’m looking for would be named getProcessServerRuntime().
>
> Would CayenneRuntime.getThreadInjector().getInstance( ServerRuntime.class
> ) return the currently operating ServerRuntime?
>
> - hugi
>
>
>
> > On 14. feb. 2016, at 13:50, John Huss <johnthuss@gmail.com> wrote:
> >
> > If you just need a context and not the runtime you can use:
> >
> > BaseContext.getThreadObjectContext();
> >
> > as long as you bind one to the thread earlier.
> >
> > Or you can use the thread injector to get other stuff like an
> > EntityResolver, or also a context, if you've bound it to a thread:
> > public static ObjectContext newObjectContext() {
> > ObjectContextFactory factory =
> >
> CayenneRuntime.getThreadInjector().getInstance(ObjectContextFactory.class);
> > return factory.createContext();
> > }
> >
> >
> > On Sun, Feb 14, 2016 at 7:19 AM Hugi Thordarson <hugi@karlmenn.is>
> wrote:
> >
> >> Hi all.
> >>
> >> In almost all of my Cayenne projects, I have a class that holds my
> >> ServerRuntime and creates ObjectContexts from that ServerRuntime; sort
> of a
> >> central station for my DB connectivity. Works fine, but it means my
> code is
> >> somewhat tied to that runtime and calls to
> >> MyCentralCayenneClass.newContext() are littered all over the place.
> >>
> >> I’m currently writing a lot of unit tests and these use a separate
> >> ServerRuntime with a different configuration that connects to a test
> >> database. But since some of my code is directly creating contexts from
> the
> >> other ServerRuntime (which connects to the production DB) I end up with
> >> unintended consequences. Same thing for framework code that’s supposed
> to
> >> be reusable—how should it obtain ObjectContexts without knowing anything
> >> about the currently active ServerRuntime?
> >>
> >> I see several solutions to the situtation but I wanted to start out by
> >> checking if there’s a canonical method of solving the problem? (I
> believe
> >> I’m actually asking if there’s a way to obtain something like a global
> >> currently active ServerRuntime, that can be used by reusable code and
> >> tests. But I didn’t want to frame the question in the wrong way
> creating an
> >> XY Problem)
> >>
> >> Cheers,
> >> - hugi
>
>

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