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 <[email protected]> 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 <[email protected]> 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 >> >>
