Configure Interlok to automatically check out config from GIT when starting.


Basic Configuration

All configuration for version control will live in The following basic properties must be set (if not set, then no VCS operations are performed):

Property Description
vcs.workingcopy.url This is the URL to the local directory where all files will be checked out to.
vcs.remote.repo.url This is the URL to your remote Git repository

All files from the remote location will be checked out to your local directory location. Standard Git URL and protocol formats are supported such as file://, http://, https:// and


Additional bootstrap properties will control the various authentication schemes available to Git.

Property Description
vcs.username Your Git username
vcs.password The password associated with your username May be treated as a password
vcs.ssh.keyfile.url The URL to your local keyfile
vcs.ssh.passphrase Your passphrase for your local keyfile. May be treated as a password
vcs.ssl.certificate.url The URL to your certificate file (if using SSL based certificate authentication)
vcs.ssl.password Your password matched with your certificate file. May be treated as a password


Property Description
vcs.implementation since 3.5.1 Which VCS implementation to load
vcs.revision The revision/tag/branch to checkout; by default this will be the latest revision for the remote URL, and will be logged.
vcs.always.reset Whether or not to always discard any uncommitted changes when updating; defaults to false
log4j12Url Deprecated: use loggingConfigUrl instead.
loggingConfigUrl since 3.1.0 If specified then then an attempt is made to re-configure the logging (log4j1.2 or log4j2) subsystem with the referenced URL. This is done after any checkout/update is performed.
vcs.ssh.proxy since 3.5.0; if required, you can specify a proxy server here to use an HTTP proxy to access the target remote SSH URL
vcs.ssh.proxy.type since 3.5.1; if required, specify the type of proxy here HTTP, SOCKS4, SOCKS5 (defaults to HTTP)
vcs.ssh.proxy.username since 3.5.0; if required the proxy username
vcs.ssh.proxy.password since 3.5.0; if required the proxy password
vcs.auth The authentication method to use, either “SSH” or “UsernamePassword”, defaults to the later.


If we take an example Note that this project does exist on, and is currently enabled for public view-only access (so the should be usable as-is).


# The adapter configuration file is VCS managed; so we refer to the local working copy.

# Our Log4j is VCS managed; so we can refer to the local working copy.

# Again, the jetty.xml is checked in, so let's refer to the local working copy.

# This controls how we connect to Git.
# Enabled for public access we don't need username/passsword.
# vcs.username=my-user-name
# vcs.password={password}PW:My-encoded-password

# Threadsafe jruby
# Force jboss to use slf4j

Which should give you logging similar to :

Bootstrap of Interlok 3.1-SNAPSHOT(2015-11-19) complete
TRACE [main] [BootstrapProperties] Properties resource is []
TRACE [main] [PropertyResolver] Parsing PropertyResolver URL [jar:file:/C:/Users/lchan/work/runtime/v3-nightly/lib/adp-core.jar!/META-INF/com/adaptris/core/management/properties/resolver]
TRACE [main] [PropertyResolver] Registered Decoders : {}
TRACE [main] [BootstrapProperties] Adding org.jboss.logging.provider=slf4j to system properties
TRACE [main] [BootstrapProperties] Adding org.jruby.embed.localcontext.scope=threadsafe to system properties
INFO  [main] [RuntimeVersionControlLoader] Found version control system for [Git]
INFO  [main] [GitVCS] GIT: Checking local repository [C:\Users\lchan\work\runtime\v3-nightly\config\interlok-config-example]
INFO  [main] [GitVCS] GIT: [C:\Users\lchan\work\runtime\v3-nightly\config\interlok-config-example] does not exist, performing fresh checkout.
INFO  [main] [GitVCS] GIT: Performing checkout to [C:\Users\lchan\work\runtime\v3-nightly\config\interlok-config-example]
TRACE [main] [JGitApi] GIT: Check out []
TRACE [main] [JGitApi] GIT: Pulling changes for branch [master]
TRACE [main] [JGitApi] GIT: Check out to revision/tag/branch [master]
INFO  [main] [GitVCS] GIT: Updated configuration to revision: 2cbc3b1e601f2472d933c5950d7a60b44f795267
TRACE [main] [BootstrapProperties] Attempting Logging reconfiguration using file://localhost/./config/interlok-config-example/log4j2.xml
WARN  [main] [ResponseProducer.<init>()] [ResponseProducer] is deprecated, use [com.adaptris.core.http.jetty.StandardResponseProducer] instead
WARN  [main] [JdkHttpProducer.<init>()] [JdkHttpProducer] is deprecated, use [] instead
TRACE [main] [WorkflowManager.configureMessageCounter()] Message count interceptor added for [com.adaptris:type=Workflow,adapter=MyInterlokInstance,channel=WebServer,id=HandleProductCodeLookup], tracks metrics for ~1hr
TRACE [main] [WorkflowManager.configureMessageCounter()] Message count interceptor added for [com.adaptris:type=Workflow,adapter=MyInterlokInstance,channel=WebServer,id=HandleProductMovement], tracks metrics for ~1hr
TRACE [main] [WorkflowManager.configureMessageCounter()] Message count interceptor added for [com.adaptris:type=Workflow,adapter=MyInterlokInstance,channel=WebServer,id=HandleProductRecall], tracks metrics for ~1hr
TRACE [main] [WorkflowManager.configureMessageCounter()] Message count interceptor added for [com.adaptris:type=Workflow,adapter=MyInterlokInstance,channel=WebServer,id=DefaultURL], tracks metrics for ~1hr
TRACE [main] [WorkflowManager.configureMessageCounter()] Message count interceptor added for [com.adaptris:type=Workflow,adapter=MyInterlokInstance,channel=WebClient,id=ProductLookup], tracks metrics for ~1hr
TRACE [main] [RuntimeInfoComponentFactory.create()] No RuntimeInfoComponent for class com.adaptris.core.NoRetries
TRACE [main] [RuntimeInfoComponentFactory.create()] No RuntimeInfoComponent for class com.adaptris.core.NullProcessingExceptionHandler
TRACE [main] [RuntimeInfoComponentFactory.create()] No RuntimeInfoComponent for class com.adaptris.core.NullLogHandler
INFO  [main] [UnifiedBootstrap.createAdapter()] Adapter created
TRACE [main] [JettyServerComponent.connectToUrl()] Connecting to ./config/interlok-config-example/jetty.xml
TRACE [main] [JettyServerComponent.createServer()] Create Server from XML
TRACE [main] [JmxRemoteComponent.register()] MBean [com.adaptris:type=JmxConnectorServer] registered
TRACE [StandardBootstrap] [JettyServerComponent.start()] JettyServerComponent Started
WARN  [StandardBootstrap] [Adapter.warnOnErrorHandlerBehaviour()] [Adapter(MyInterlokInstance)] has a MessageErrorHandler with no behaviour; messages may be discarded upon exception


Be aware that if no initial log4j configuration is available on the classpath on startup then you will not have any logging until after checkout/update and logging reconfiguration is completed which will make it very hard to verify whether you have the configuration correct. In the example above, you can see that the logging configuration has actually changed because the log4j2 configuration PatternLayout contains the method name in addition to the classname subsequent to checking out the configuration.

You may also notice an error in the logging similar to this; Cannot run program "bash" (in directory "C:\Users\myUser"): CreateProcess error=2, The system cannot find the file specified
        at java.lang.ProcessBuilder.start(
        at java.lang.Runtime.exec(
        at org.eclipse.jgit.util.FS.readPipe(
        at org.eclipse.jgit.util.FS_Win32.discoverGitPrefix(
        at org.eclipse.jgit.util.FS.gitPrefix(
        at org.eclipse.jgit.util.SystemReader$Default.openSystemConfig(
        at com.adaptris.vcs.git.api.JGitApi.getRepository(
        at com.adaptris.vcs.git.api.JGitApi.getBareRepository(
        at com.adaptris.vcs.git.api.JGitApi.updateCopy(
        at com.adaptris.vcs.git.api.JGitApi.update(
        at com.adaptris.vcs.git.GitVCS.update(
Caused by: CreateProcess error=2, The system cannot find the file specified
        at java.lang.ProcessImpl.create(Native Method)
        at java.lang.ProcessImpl.<init>(
        at java.lang.ProcessImpl.start(
        at java.lang.ProcessBuilder.start(
        ... 18 more

The reason for this error is in JGit tries to find native git by running the command “which git” in a bash process. If native git isn’t installed or bash or git are not configured on the system PATH then this command fails. JGit logs an error to leave a trace message that this attempt to find native git failed but will work ok anyway. JGit tries to find native git in order to locate the system wide git configuration which is located in a path relative to the native git installation. If it doesn’t find a native git installation JGit can’t locate this system wide git configuration and hence will ignore it.

If you do see this error, you can ignore it knowing that version control with Git will work anyway.

Tags: advanced