Upgrading from 1.6.8 to 1.6.9 Processes can't find configuration about chorus HOT 8 CLOSED

Hi, that would be unexpected!

We do have quite a lot of regression tests for processes and process configs which are all still passing with 1.6.9. Can you confirm it still works if you downgrade back to 1.6.8?

If it does, then can you tell me how the processes config is named, and where the file is located relative to the feature file? Also the properties/contents and as much of the feature as possible

from chorus.

It still works when we go back to 1.6.8

Our Structure looks like

features
features/FeatureX
features/FeatureX/TestX
features/FeatureX/TestX/conf
features/FeatureX/TestX/conf/log4j.xml
features/FeatureX/TestX/conf/TestX-processes.properties
features/FeatureX/TestX/TestX.feature

TestX-processes.properties

consoleFlow.mainclass=com.xx.xx.Xxx
consoleFlow.classpath=/Users/bretkumler/xxx
consoleFlow.jvmargs=-Xmx1024m -Xms256m
consoleFlow.terminateWaitTime=120
consoleFlow.stdOutMode=capturedwithlog
consoleFlow.stdErrMode=file
consoleFlow.readTimeoutSeconds=120
consoleFlow.readAheadBufferSize=165536
consoleFlow.scope=scenario

In the TestX.feature has

Given I start a consoleFlow process named console

from chorus.

This is a tricky one since I've tried with a feature and config as close as I can to the example above, but it all works OK for me, and we run tests quite similar to it during the regression testing on all the major platforms so would have hope to flush out any obvious regressions. One quick question, the scope is correct is it? (in the example above you are setting scenario scope, which would mean it would not work if you start the process in Feature-Start: but refer to it in another scenario).

Another question - does your config file exist at the start of the feature? You're not doing anything in Feature-Start which writes the config file, are you? We moved config load to the start of the feature in the migration between 1.6.8 and 1.6.9, which shouldn't affect anything in normal circumstances, but might if you were generating configs dynamically during the run - previously it was a lazy load, when you first started a process.

If neither of the above seem to point to the issue, then what's the error you are seeing in the output exactly?. It would help if you can send me a (sanitized) log file from the feature with Chorus set to debug mode (-l DEBUG). If we can't identify it from that, then we'll have a think what next.

from chorus.

"Another question - does your config file exist at the start of the feature? You're not doing anything in Feature-Start which writes the config file, are you?"

We generate all of our processes.properties dynamically in Feature-Start:

Some cases in the Scenario.

This is the issue I believe.

from chorus.

OK, the timing of the config load for a handler hasn't yet been fixed / specified clearly enough yet and we need to address that.

Moving the config load to feature start was intended to address this - to make the config loading an aspect of initializing the feature.

In the past it was a lazy load - but that lazy load would load all process configuration (so the first time you started a process, that would load the configs both for that process and for any others started later in the feature) - this seemed less determinate.

We can possibly add a setting which would turn off caching of configs during a feature run - this would have the effect of loading the config each time you start a process, and would enable you to continue doing what you're doing with the dynamic config generation.

I'll discuss with the other Chorus devs here and get back to you.

from chorus.

We propose fixing this temporarily in a 1.6.10 by reverting to the previous lazy load behaviour.

It sounds as if we need a better API for dynamic property configuration - such that you could configure process properties dynamically using the API without actually having to generate and write out a local properties file. (This mechanism should work in a generic way for any handler class which wishes to support property configuration).

With this you'd be able to access all the process properties from one of your custom handlers during the Feature-Start section, and add new configs or modify the existing ones directly in code.

We could aim to get an API which supports that in for the new chorus 2.x which we are working on. Once in, we'd fix the load of property files to the start of the feature, so that the property field load in the same manner for every handler type

Does that sound like it might work OK for you?
If we did it that way you'd be able to take 1.6.10 to fix the present issues you're having with 1.6.9 without making any changes on your side. When we release 2.0 you'd need to make a few changes to use the new API to configure your dynamic processes instead of writing the properties to file.

from chorus.

Sounds like a good solution.
Once you have this new API to configure dynamic processes, I wouldn't mind trying it out before deciding to upgrade to 2.0.

Any idea when 1.6.10 will be available?

Thanks

from chorus.

Closing this since we have identified the problem and a solution is in progress

from chorus.