No, what you are suggesting is reasonable when there's only one
variation from the common ServerRuntime, which is currently my use
case. What you're saying about caching this unrestricting qualifier
runtime makes sense for my situation, and I like to stick to the
recommended practices whenever po
> I was able to do this in six easily-understandable lines of code with
> a ServerRuntime(Modules) constructor, and I fear that your suggested
> approach requires me to create several separate classes, store
> configuration globally, and create new modules for each qualifier that
> I need to disabl
While I can understand the desire for purity with that pattern, it
seems to me that it's too expensive to maintain in this use case.
I don't want to have to maintain a factory for building runtimes and
track all of the configuration needed to do that, just to turn off a
qualifier.The existing
In my case the copy was the same. The point was to create a separate DB
connection pool for background tasks to use so that they could do DB
intensive tasks without impacting the main DB connection pool. I see your
point though.
On Fri, Sep 27, 2013 at 11:49 AM, Andrus Adamchik wrote:
> > So i
> So it looks like I can reuse modules to create my own runtime.
Yes.
> However, the current 3.1 API isn't very friendly toward this approach.
Yes - see my other email. A common pattern is to have some kind of external
factory that defines the modules.
Also I don't perceive 'copy' method as
I've had to make a copy of a ServerRuntime object before too - an API for
it would be useful.
On Fri, Sep 27, 2013 at 11:39 AM, Mike Kienenberger wrote:
> So it looks like I can reuse modules to create my own runtime.
> However, the current 3.1 API isn't very friendly toward this approach.
> I h
So it looks like I can reuse modules to create my own runtime.
However, the current 3.1 API isn't very friendly toward this approach.
I had to clone the ServerRuntime class so that I could create my own
version so I could call CayenneRuntime(Module... modules) in my
constructor.
Having a cloned Se
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/cayen
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 ou
