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 <johnth...@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 <jfbald...@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 <johnth...@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 <jfbald...@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 >>>> >>>> >> >>
