Dan Tihelka
2014-10-29 20:18:28 UTC
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.
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.