I went even more old-school. I have a CayenneUtils class where I can set the ServerRuntime and a createDataContext() method. Main app can set the ServerRuntime to the actual runtime, unit tests can set it to something else. Everywhere else in the code I call CayenneUtils.createDataContext() and it uses the configured runtime to create a new DC for me. Works with and without Tapestry IoC.
mrg On Sun, Feb 14, 2016 at 12:38 PM, Andrus Adamchik <[email protected]> wrote: > FWIW, I came to dislike thread-bound context approach. I prefer dependency > injection outside Cayenne. I either inject ServerRuntime directly or a thin > wrapper service ([1] gives a Tapestry example of such service, but it will > work with any kind of DI). > > Andrus > > > [1] > https://github.com/andrus/wowodc13/tree/master/services/src/main/java/demo/services/cayenne > > > > On Feb 14, 2016, at 5:34 PM, Hugi Thordarson <[email protected]> wrote: > > > > Yes. I did, in fact, see that, the first time you wrote it. I’m going to > get myself some more coffee now. > > > > Thanks, > > - hugi > > > > > > > >> On 14. feb. 2016, at 14:31, John Huss <[email protected]> wrote: > >> > >> The second method I gave. Just bind the injector to the thread earlier. > >> On Sun, Feb 14, 2016 at 8:20 AM Hugi Thordarson <[email protected]> > wrote: > >> > >>> How would you go about creating a new ObjectContext in framework code; > >>> i.e. in code that doesn’t know anything about the environment it’s > running > >>> in? > >>> > >>> > >>>> On 14. feb. 2016, at 14:16, John Huss <[email protected]> wrote: > >>>> > >>>> 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 <[email protected]> > >>> 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 <[email protected]> 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 <[email protected]> > >>>>> 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 > >>>>> > >>>>> > >>> > >>> > > > >
