ServerRuntime encapsulates a full Cayenne stack (which includes injector). How you create and manage it is left up to the app. Here is for instance how I usually encapsulate it in a Tapestry application:
https://github.com/andrus/wowodc13/blob/master/services/src/main/java/demo/services/cayenne/CayenneService.java CayenneService in this example is both a factory (defining custom modules among other things) and a holder of a reference to ServerRuntime. CayenneService itself is a singleton injectable via Tapestry to pages and other services. Your version of CayenneService can store multiple runtimes if needed. As to where to put CayenneService, you may use something like Spring or put it in ServletContext. In other words just follow the patterns for managing app singletons that you are using already. Cayenne is intentionally made agnostic to that. Andrus On Sep 27, 2013, at 6:46 PM, Mike Kienenberger <[email protected]> wrote: > The idea of creating a new ServerRuntime is good, but the > implementation leaves me with a few questions. My ServerRuntime is > created in the context of the web app. > > Is it reasonable to try to create it using the information in the > existing ServerRuntime? Can I pull the injector and modules out of > the existing Runtime and reuse them to create a new runtime, or do I > need to create copies of the existing modules and injector? My guess > is that each runtime needs unique injector and modules objects, but I > want to minimize the work I need to do. > > It looks like I have to pull my configurationLocation out of the > ServerModule, which doesn't really provide it. > > I'm not seeing an easy way to create a new ServerRuntime from scratch > without having access to data which was only available back when the > web application started up, short of storing that information > somewhere globally and reusing it. > > On Tue, Sep 24, 2013 at 2:04 PM, Andrus Adamchik <[email protected]> > wrote: >>> The "special DataContext" case where the qualifier should be ignored can >>> probably be handled by starting a separate ServerRuntime, where you can >>> strip off the qualifiers. For whatever overhead it creates (ideally not >>> much), this has an advantage of cleanly separating "spaces" with different >>> ORM rules. >> >> Elaborating on this a bit… The old Configuration allowed multiple >> DataDomains, each of those requiring its own DataMap(s) saved in the project >> upfront. Good idea, but hard to use in practice. >> >> ServerRuntime (with single DD each) is more user-friendly. By starting >> multiple independent runtimes you to easily reuse a single mapping project, >> tweaking each in-memory copy local to each Runtime (as well as tweaking >> other parameters like cache). 2 Runtimes can reuse a single DataSource >> (JNDI, or otherwise), etc. >> >> Andrus >> >
