Akka configuration overwritting - configuration

I'm trying to overwrite Akka configuration in my application. I have created additional lib for the application, which also has application.conf file as it uses Akka. So I have 2 of them:
application.conf in my lib:
my-conf {
something = 1
}
application.conf in my app, which uses the lib:
something-else = "foo"
my-conf {
something = 1000
}
When I'm running the app from Intellij Idea, everything is fine, and lib configuration is being overwritten. To load the config in my app I'm using simple ConfigFactory.load() operation.
But when I create a jar of my app with mvn clean compile assembly:single and try to run it with this command: java -Xmx4048m -XX:MaxPermSize=512M -Xss256K -classpath myApp.jar com.myapp.example.MyMain I get error:
Caused by: com.typesafe.config.ConfigException$Missing: No configuration setting found for key 'something-else'
So I decided to rename the conf file in my app, and load it in such way:
val defConfig = ConfigFactory load
val myConfig = ConfigFactory load "myconf"
val combined = myConfig.withFallback(defConfig)
val config = ConfigFactory load combined
It finds missing settings, but unfortunately config from my app doesn't override config in my lib.
In my lib I load config in default way: val settings = ConfigFactory load
Also, "my-conf.something" is an important setting, and I'd like to overwrite it from my app.
What I'm doing wrong? Thanks in advance!
Also, I thought there could be an issue how I create the jar:
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.4</version>
<configuration>
<archive>
<manifest>
<mainClass>com.myapp.example.MyMain</mainClass>
</manifest>
</archive>
<finalName>loadtest</finalName>
<appendAssemblyId>false</appendAssemblyId>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
<executions>
<execution>
<id>dist-assembly</id>
<phase>package</phase>
<goals>
<goal>assembly</goal>
</goals>
</execution>
</executions>
</plugin>

Straight from akka documentation:
If you are using Maven to package your application, you can also make use of the Apache Maven Shade Plugin support for Resource Transformers to merge all the reference.confs on the build classpath into one.
This resolved the issue for me.
<transformers>
<transformer
implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
<resource>reference.conf</resource>
</transformer>
<transformer
implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<manifestEntries>
<Main-Class>akka.Main</Main-Class>
</manifestEntries>
</transformer>
</transformers>

As far as I understand, your library should create file called reference.conf. According to https://github.com/typesafehub/config :
libraries should use a Config instance provided by the app, if any,
and use ConfigFactory.load() if no special Config is provided.
Libraries should put their defaults in a reference.conf on the
classpath.
So, i suggest putting a reference.conf into your library first, to make it clear that it is default configuration, and you won't need to have a withFallback - typesafe-config will handle it for you.
Update: I don't remember how maven-assembly-plugin works - it may combine all of jar files and resources in a single file, meaning that lib/src/main/resources/application.conf will be overwritten by app/src/main/resources/application.conf in your case - so yet another reason to use reference.conf.

That's right! Just in order to add a bit more information related to that reference.conf I would say that you should go to:
Akka Documentation: http://akka.io/docs/?_ga=1.90177882.150089464.1402497958
, pick the version you are using and in it look for General->Configuration
inside that page look for 'Listing of the Reference Configuration', that's all the content you may need for that reference.conf. In my case I just copied it all.
Hope it helps to save sometime!

Related

How to configure custom main class using YAML in wildfly swarm application

I am trying to build a Wildfly Swarm application using custom main class specified in plugin configuration ( as shown below )
<plugin>
<groupId>org.wildfly.swarm</groupId>
<artifactId>wildfly-swarm-plugin</artifactId>
<version>2018.3.3</version>
<configuration>
<mainClass>rnd.web.service.rest.App</mainClass>
</configuration>
</plugin>
But during build/run is show deprecation warning/information (see below) with reference to documentation. But the documentation does not provide any details on how to implement it.
Custom main() usage is intended to be deprecated in a future release
and is no longer supported, please refer to
http://docs.wildfly-swarm.io for YAML configuration that replaces it.
If someone has encountered and implemented it. Please share the approach and correct reference.
As the deprecation warning says, it's not the <mainClass> setting that's deprecated, it's the entire usage of custom main method. All the configuration you do in your main method, you should be able to do with the YAML configuration. If you find something missing, then that's a bug.

Unable to Configure CAS Database Authentication

Following this tutorial I am unable to configure database configuration.
Using the cas-overlay, I've added settings to the cas.properties file, but when I run the project it fails to authenticate.
I don't think the settings are loading completely, because my cas.authn.jdbc.query[0].passwordEncoder.type=BCRYPT setting doesn't take.
I'm coming to this pretty green, so I feel like there is a gap in the documentation.
I figured out my problem. It wasn't necessarily the cas.properties file was wrong. I was actually missing a dependency that imports JDBC support.
Their documentation kind of reads like it is supported, but makes an assumption the reader knows to add the dependency.
Added this to my overlay pom.xml
<dependency>
<groupId>org.apereo.cas</groupId>
<artifactId>cas-server-support-jdbc</artifactId>
<version>${cas.version}</version>
</dependency>

SecurityException when running plain JUnit + Mockito in Eclipse RCP Project

I have an Eclipse RCP Project with multiple plugins. I am writing plain JUnit tests (no dependencies to Eclipse/UI) as separate fragments to the plugin-under-test.
When using Mockito and trying to mock an interface from another plugin (which is exported correctly; I can use the interface in my code), I get a SecurityException related to class signing:
org.mockito.exceptions.base.MockitoException:
Mockito cannot mock this class: interface ch.sbb.polar.client.communication.inf.service.IUserService
Mockito can only mock visible & non-final classes.
If you're not sure why you're getting this error, please report to the mailing list.
at org.mockito.internal.runners.JUnit45AndHigherRunnerImpl$1.withBefores(JUnit45AndHigherRunnerImpl.java:27)
[...]
Caused by: org.mockito.cglib.core.CodeGenerationException: java.lang.reflect.InvocationTargetException-->null
at org.mockito.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:238)
[...]
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[...]
Caused by: java.lang.SecurityException: Signers of 'ch.sbb.polar.client.communication.inf.service.IUserService$$EnhancerByMockitoWithCGLIB$$a8bfe723' do not match signers of other classes in package
at java.lang.ClassLoader.checkPackageSigners(ClassLoader.java:361)
at java.lang.ClassLoader.defineClass(ClassLoader.java:295)
... 40 more
When I run the tests as "JUnit Plugin tests", i.e. with an OSGi environment, everything works as expected. But I'd like to use the plain JUnit execution because of speed; in the class under test, I don't need the OSGi environment.
Does anybody know a way to do that?
As is mentioned in the comments, the root cause is that the Eclipse Orbit package of Mockito (which I had added to my target platform) is signed, and because of a bug in the underlying CGLIB, you cannot mock unsigned classes/interfaces with a signed Mockito.
See https://code.google.com/p/mockito/issues/detail?id=393 for the most detailed description. The bug is fixed in CGLIB head, but has not yet appeared in a release. Mockito only uses released versions as dependencies, so the fix is not yet in Mockito, with an unknown (to me) timeline, as when this will be in.
Workaround: Provide unsigned Mockito in separate bundle
The workaround is to package the Mockito JAR (and its dependencies) in its own bundle and export the necessary API packages.
When using Maven Tycho, JUnit, Hamcrest, and Mockito, the only way I was able to make this work and resolve all dependency / classpath / classloader issues correctly was the following way:
Create Maven module with the following entries in the pom.xml:
<packaging>eclipse-plugin</packaging>
[...]
<dependencies>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>1.10.19</version>
</dependency>
</dependencies>
[...]
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-test-libs</id>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>lib</outputDirectory>
<stripVersion>true</stripVersion>
<includeScope>runtime</includeScope>
</configuration>
</execution>
</executions>
</plugin>
Use following entries in the MANIFEST.MF:
Bundle-ClassPath: lib/mockito-core.jar,
lib/objenesis.jar
Export-Package: org.mockito,
org.mockito.runners
Require-Bundle: org.junit;bundle-version="4.11.0";visibility:=reexport,
org.hamcrest.library;bundle-version="1.3.0";visibility:=reexport,
org.hamcrest.core;bundle-version="1.3.0";visibility:=reexport
And finally in your unit test fragment, add this new bundle as a dependency.
I ran into this same issue and was able to resolve it by using a more recent Orbit repository which pulls Mockito 2.x:
http://download.eclipse.org/tools/orbit/downloads/drops/R20181128170323/?d
This repository contains Mockito 2.23.0 which uses Byte Buddy instead of CGLIB.
In my target, I simply pull mockito-core 2.23.0 and Byte Buddy Java Agent 1.9.0 from the Orbit repository above.
<unit id="org.mockito" version="2.23.0.v20181106-1534"/>
<unit id="org.mockito.source" version="2.23.0.v20181106-1534"/>
<unit id="net.bytebuddy.byte-buddy-agent" version="1.9.0.v20181106-1534"/>
<unit id="net.bytebuddy.byte-buddy-agent.source" version="1.9.0.v20181106-1534"/>

How to specify a logback configuration as a classpath resource rather than a file

I have the following situation. I need to be able to run two programs launched by different batch files where each batch file invokes a java class with main() from the same jar. I would like each program to have its own log. However, the second program is an installer for the first, and therefore, I don't want to/can't easily specify -Dlogback.configurationFile=/path/to/config file as that location may not yet exist.
Logback documentation seems to provide a solution but I need an example of how to make it work:
Specifying the location of the default configuration file as a system
property
If you wish, you can specify the location of the default configuration
file with a system property named logback.configurationFile. The value
of this property can be a URL, a resource on the class path or a path
to a file external to the application.
java -Dlogback.configurationFile=/path/to/config.xml
chapters.configuration.MyApp1
Can anyone point me to an example where logback.configurationFile is defined as a resource on the classpath as opposed to the file system?
You can simply put a my-logback.xml in the root of one of your classpath entries and specify -Dlogback.configurationFile=my-logback.xml. Internally it will probably use ClassLoader#getResource(String name) to get the file - check the JavaDoc of this method for more information.
the answer to this question is in the supplied link:
https://logback.qos.ch/manual/configuration.html#configFileProperty
with the examples below:
The contents to include can be referenced as a file, as a resource, or as a URL.
As a file:
To include a file use the file attribute. You can use relative paths but note that the current directory is defined by the application and is not necessarily related to the path of the configuration file.
As a resource:
To include a resource, i.e a file found on the class path, use the resource attribute.
<include resource="includedConfig.xml"/>
As a URL:
To include the contents of a URL use the url attribute.
<include url="http://some.host.com/includedConfig.xml"/>
I have a slightly different solution than offering command line arguments.
My project is set up like so:
| foo
- src
- conf
- logback.xml
- main
- test
I wanted the logback.xml outside of the jar since I had the scanPeriod set for live reload. I figured since it should get picked up on the classpath, I'll add the path to the manifest.mf and it'll get picked up automatically.
Related parts of foo's pom.xml looks like this:
<plugins>
. . . Some plugins before
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>3.0.2</version>
<executions>
<execution>
<id>copy-resources</id>
<phase>validate</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${basedir}/target/conf</outputDirectory>
<resources>
<resource>
<directory>src/conf</directory>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.0.2</version>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>lib/</classpathPrefix>
<mainClass>com.company.foo.main.Main</mainClass>
</manifest>
<manifestEntries>
<version>${project.version}</version>
<Class-Path>.</Class-Path>
<Class-Path>conf/</Class-Path>
</manifestEntries>
</archive>
</configuration>
</plugin>
. . . Some plugins after
</plugins>
Important things to take note of:
Maven Resources Plugin
Copies all files in src/conf to the standard compilation folder target/conf.
Maven Jar Plugin
Adds the conf folder to the MANIFEST.MF's classpath so that you don't need to specify the location on the command line.
All files in the conf folder will be added to the classpath, not just logback.xml
For the jar to run in this scenario, the conf folder must be placed alongside the jar. It will look like so:
path/to/jar
| foo.jar
| lib/
| conf/
| logback.xml
The MANIFEST.MF looks something like this:
Manifest-Version: 1.0
Built-By: $user
Class-Path: lib/x.jar lib/y.jar lib/z.jar conf/
version: 0.0.1-SNAPSHOT
Created-By: Apache Maven 3.5.2
Build-Jdk: 1.8.0_161
Main-Class: com.company.foo.main.Main
OK I went ahead and tried it out.
If the logback config file is local to the jar (in the same jar you're running in), this works:
System.setProperty("logback.configurationFile", "org/package/path/your.logback.xml");
works. If it's in the classpath 'anywhere'. Which is really weird since normally with a call to getResource you have to specify it with a preceding slash like:
YourClass.class.getResource("/org/package/path/your.logback.xml") so not sure why.
Other more exotic resource paths like specifying the exact jar also seem to not work. Weird.

maven-release-plugin: Perform fails with 'working directory "...workspace\target\checkout\workspace" does not exist!'

I have maven project that fails when release:perform is called, though release;prepare works as expected.
I have found the bug report (below) which certainly seems to resemble the issue I have but not entirely sure I understand the problem:
MRELEASE516
The last few lines of output I get:
[INFO] Executing: cmd.exe /X /C "p4 -d E:\hudson\jobs\myHudsonJob\workspace\target\checkout -p 1.1.1.1:1111: client -d myProjectWorkspace-MavenSCM-E:\hudson\jobs\myHudsonJob\workspace\target\checkout"
[INFO] Executing goals 'deploy'...
[WARNING] Base directory is a file. Using base directory as POM location.
[WARNING] Maven will be executed in interactive mode, but no input stream has been configured for this MavenInvoker instance.
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error executing Maven.
Working directory "E:\hudson\jobs\myHudsonJob\workspace\target\checkout\workspace" does not exist!
From reading the bug report the possible cause of the error is related to my modules' structure, I've tried to outline it below:
/workspace
|
|+ pom.xml (root pom whose parent is the build pom,
| calling release:perform on this pom)
| [Modules: moduleA and moduleB]
|
|- moduleA
|+ pom.xml (parent is also build pom)
|+ build/pom.xml (the build pom - no custom parent)
|- moduleB
|+ pom.xml (parent is build pom)
It seems that the root pom should be in some common directory inside 'workspace' from the error but tried that and doesn't work, nor make sense as to why I need it.
What does the warning Base directory is a file want me to do instead?! It then figures that the base directory is workspace which then means the working directory is not found...any ideas?
Thanks in advance.
EDIT:
Having checked the SCM configuration it all looks ok to me...in each module and the root pom I have:
<scm>
<connection>
scm:perforce:1.1.1.1:1111://rootToDirectoryContainingRelevantPom
</connection>
<developerConnection>
scm:perforce:1.1.1.1:1111://rootToDirectoryContainingRelevantPom
</developerConnection>
</scm>
EDIT 2:
Maybe I have hit MRELEASE-261?
I got this working by using a newer version of the release plugin. The Maven super pom has a dependency on v2.0 of the release plugin defined. If you don't override this then that the version will be used.
You can specify a newer version when you run the plugin
mvn org.apache.maven.plugins:maven-release-plugin:2.2.1:perform
Or you can override the dependency version in your pom
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.2.1</version>
</plugin>
I'm not sure you're facing MRELEASE-516 (which is about release:prepare). However, I wonder if you have correct <scm> informations in each POM. Can you confirm this?
Working directory "E:\hudson\jobs\myHudsonJob\workspace\target\checkout\workspace" does not exist!
I just saw the above line in your log. It looks like you have some screwy path setting somewhere. Do you overwrite the Workspace somewhere? Check your configuration and try to eliminate as much as possible the optional settings.
In my case the same symptoms turned out to be a result of a bug in maven-release-plugin:2.2.1. See MRELEASE-705.
So to get rid of the error, I've got to put this into the parent pom:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.0</version>
</plugin>
</plugins>
</build>
This error was occurring for us
Working directory E:\Data\myproject\target\checkout does not exist!
We're in the middle of a large transition of server tools and maven's release:prepare appeared to be failing silently, claiming the tags and version number changes had been pushed without error. However, after some research, these things had only been committed to the local git repository, not pushed - even though the release:prepare was executing commands to perform a push but never reported a failure -- even with the maven -e and -X command line parameters.
We're using Maven 3.3.9, maven release plugin 2.5.3, and git client 2.9.2.
Our end solution was to add a (or correct the, as your case may be) definition in maven's ~\.m2\settings.xml file for our git server (origin master) including username and password with privileges for pushing tags (as well as pushing to master). The id in the server definition for the git server needed to be the git server's hostname:
<servers>
<server>
<id>git-server</id>
<username>dan</username>
<password>changeit</password>
</server>
<servers>
With this update, the tag completes on the server and the checkout occurred successfully.