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

Reply via email to