cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kienenberger <mkien...@gmail.com>
Subject Re: Creating a new ServerRuntime from an existing ServerRuntime
Date Fri, 27 Sep 2013 16:39:56 GMT
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 ServerRuntime on which to make customizations seems
like a reasonable use case that we should support.   Can we add such a
method to ServerRuntime?   I think that's a better choice than making
it easier to create a ServerRuntime subclass.

private ServerRuntime(Module... modules) {
    super(modules);
}

public ServerRuntime copy() {
        return ServerRuntime(serverRuntime.getModules());
}

It might be reasonable to make the private constructor public so that
someone can create ServerRuntimes where they are not required to pass
configurationLocation data but can provide their own alternative to
ServerModule.  This would have also worked in my case, removing the
need to have a copy() method.   However, I think the copy() method
provides assurance to the developer that this approach is viable.


Here's what my application code ended up looking like (using my cloned
class), and I think it's a good approach (except for the cloned class)
for these cases:

        PaymentMethod paymentMethod = paymentHistory.getPaymentMethod();
        if (null == paymentMethod) {
            ServerRuntime currentRuntime = ServiceLocator.getCayenneRuntime();

            // Payment method was invalidated at this point -- create
a runtime that can read invalidated payment methods

            CopiedServerRuntime copiedRuntime = new
CopiedServerRuntime(currentRuntime);
            DataDomain dataDomain = copiedRuntime.getDataDomain();
            dataDomain.setSharedCacheEnabled(false);

            EntityResolver entityResolver = dataDomain.getEntityResolver();
            ObjEntity paymentMethodObjEntity =
entityResolver.getObjEntity(PaymentMethod.class.getSimpleName());
            paymentMethodObjEntity.setDeclaredQualifier(null);

            ObjectContext unrestrictedObjectContext =
copiedRuntime.getContext();
            PaymentHistory unrestrictedPaymentHistory =
unrestrictedObjectContext.localObject(paymentHistory);
            paymentMethod = unrestrictedPaymentHistory.getPaymentMethod();
        }


On Fri, Sep 27, 2013 at 11:46 AM, Mike Kienenberger <mkienenb@gmail.com> 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 <andrus@objectstyle.org> 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
>>

Mime
View raw message