RFC - new configuration handling

Hi all,

some time ago I have added the native configuration allowing to launch CC by 
systemd init deamon. Since than, the systemd was adopted by many Linux 
distributions, so native systemd unit for CC launch should be taken seriously.

However, the configuration by command line options (and/or Java properties) is 
not very system'd friendly, as related to a change of options according to a 
user. In other words, if a user wants to change, add or delete an single 
command line option, it must basically rewrite the whole execution command in 
the CC-systemd unit file. When discussing this with the systemd community, it 
was recommended to use a configuration file instead of command line options - in 
this case, any user can just change the content of the file but does not have 
to touch the systemd unit.

Therefore, I have tried to rewrite the part of options parsing. In general, CC 
can be configured from 3 sources (from lowest to highest priority):

- config XML file
- properties defined by -D
- command line options

with hardcoded default value defined for each config option. It is in 
Configuration.java.

Also, each option has its type assigned, so e.g. when we know that port must 
be a number, the validity of the option is checked automatically and exception 
is thrown when not matching.

Also, there is s simple logic for options pointing to a file or directory:

- first, if the path is absolute and the file/dir exists, it is returned 
directly
- otherwise, the file/directory is searched under the current working dir
- and finally, if all above fail, the file/dir is searched under the home 
directory of the user under which CC was started
- otherwise, exception is thrown

Most of the changes are rather trivial, but there are few which I would like 
to have a feedback of those who use them, and the new code broke CC launch. If 
you find one, it could be great to make a test case for it and send it to me. I 
have tried not to break the way how it works currently, but I'm no 100% sure. 
Anyway, it works in our deployment of CC.


Files legend:

Configuration.java, ConfigurationTest.java
- the configuration handler

LogInterface.java, LogBuffer.java, Log4J.java
- special simple classes used to pass log messages before "real" logger 
(log4j) is initialized. This ensures that all messages will end up in the log 
file; currently some early messages are printed to STDERR only, which is more 
difficult to to get them when the CC launch fails.

Launcher.java, Main.java, CruiseControlMain.java, MainTest.java, 
LauncherTest.java
- were modified to use the Configuration framework, with the tests adjusted 
accordingly

TestUtil.java
- was extended by class restoring properties changed during a test

CruiseControlControllerAgent.java, LaunchException.java, 
DashboardControllerTest.java, 
- just fixes to make the whole stuff  build and run


Thanks for looking at it, feels free to ask whatever you don't understand. 
Looking forward to your feedback.

Best regards,
Dan T.

------------------------------------------------------------------------------

_______________________________________________
Cruisecontrol-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cruisecontrol-devel