cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Baldwin <jfbald...@earthlink.net>
Subject Re: ServerRuntime.builder().addConfig
Date Wed, 17 Jul 2019 21:22:45 GMT
John,

> https://stackoverflow.com/questions/18948418/set-database-path-in-cayenne

Is that still applicable to 4.0.1?

It looks like Module is an interface (per your docs).

Joe



> On Jul 17, 2019, at 12:10 PM, John Huss <johnthuss@gmail.com> wrote:
> 
> You should only have one project file. You can change the DB connection
> properties using a module passed to the runtime. Here's some info:
> https://stackoverflow.com/questions/18948418/set-database-path-in-cayenne
> 
> 
> On Wed, Jul 17, 2019 at 11:01 AM Joe Baldwin <jfbaldwin@earthlink.net>
> wrote:
> 
>> John,
>> 
>>> What are you trying to override for testing? If it's the database
>> connection properties there are better ways to do that.
>> 
>> 
>> The context is automated testing.  (i.e. unit and integrated testing).  I
>> am using the project file to set the connection properties (i.e. mysql,
>> server-ip).   The unit testing will be on a different server from
>> integrated testing.
>> 
>> The initial idea is to have gradle perform the unit tests, while have
>> jenkins orchestrate the integrated testing.
>> 
>> I assumed that this could be handled via a simple change to the project
>> file connection parameters.  However, with the addConfig assumption of
>> classpath (disallowing explicit path), coupled with gradle defaults of
>> adding both main resources AND test resources, cayenne runtime is
>> complaining that it is finding two project files.   In the short run, I am
>> relying on Cayenne preferring the first project file found.
>> 
>> However, this is a short term solution - I would like to replace it with a
>> more durable solution.   I would like to be able to build various testing
>> databases as the need requires and apply connection properties (in a
>> deterministic but simple-to-modify manner).
>> 
>>> The typical approach is to put the project file in the root of the
>> classpath.
>> 
>> 
>> That is indeed an “approach” but as I summarized in the previous email, it
>> disallows explicitly setting the path - so it looks like the *only*
>> approach - at least based on my experimentation with addConfig() - and one
>> that cayenne runtime is complaining about in this case.
>> 
>> I am trying to come up a connection configuration strategy that uses
>> cayanne best practices, as well as conforms to gradle and jenkins
>> capabilities.  Just relying on “classpath” is causing problems right now,
>> and it does not look reliable (based on the complaints by cayenne runtime).
>> 
>> Joe
>> 
>> 
>> 
>>> On Jul 17, 2019, at 10:54 AM, John Huss <johnthuss@gmail.com> wrote:
>>> 
>>> The typical approach is to put the project file in the root of the
>>> classpath.
>>> 
>>> What are you trying to override for testing? If it's the database
>>> connection properties there are better ways to do that.
>>> 
>>> On Wed, Jul 17, 2019 at 9:25 AM Joe Baldwin <jfbaldwin@earthlink.net>
>> wrote:
>>> 
>>>> Goal:
>>>> My goal is to provide an unambiguous (deterministic) path to my project
>>>> xml file to ServerRuntime during automated testing (the plan is to have
>>>> multiple stages of testing).
>>>> 
>>>> My understanding  is that 4.0.1 uses:
>>>>    ServerRuntime.builder().addConfig()
>>>> to accomplish this normally.
>>>> 
>>>> Problems:
>>>> 1. While trying to understand the behavior of .addConfig(), I have had
>> to
>>>> rely primarily on experiments (i.e. hacking), since I have found no
>>>> documentation in JavaDocs (addConfig() JavaDoc has no comments).
>>>> 
>>>> 2. So it appears from my experiments that addConfig() assumes CLASSPATH
>>>> referencing and will not accept an explicit path.
>>>> Example:
>>>> org.apache.cayenne.configuration.server.DataDomainLoadException:
>> [v.4.0.1
>>>> Dec 20 2018 11:02:32] Configuration resource
>>>> "/webdev/cms/src/main/resources/config/cayenne/cayenne-CMSDomain.xml" is
>>>> not found.
>>>> Note:
>>>> If I understand the behavior, addConfig() *only* allows
>> project-file-path
>>>> specification relative to one of the paths already specified in the
>>>> CLASSPATH, and will not accept a full path entry.
>>>> 
>>>> 3. To further complicate this, during testing, cayenne is complaining
>> that
>>>> multiple project files are found in the classpath (gradle, by default,
>>>> appears to create a complex classpath that include multiple resource
>>>> directories that contain the two project files).
>>>> 
>>>> Note:
>>>> Currently, I have the test-resources earlier in the classpath (cayenne
>>>> runtime appears to select based on classpath positioning).  I would
>> prefer
>>>> a more explicit solution.
>>>> 
>>>> 
>>>> Questions:
>>>> 1. With not much info in the JavaDocs on usage-options, does anyone have
>>>> an online reference that could provide more insight (i.e. alternatives,
>>>> use-case examples, etc)?
>>>> 
>>>> 2. Does anyone know of a simpler way to accomplish my goal (i.e.
>>>> deterministically or explicitly provide the project file to cayenne
>>>> runtime)?
>>>> 
>>>> 
>>>> Thanks
>>>> Joe
>>>> 
>>>> 
>> 
>> 


Mime
View raw message