We Keep Coding

How to define datasource properties for WildFly bootable JAR without openshift CLI?

So normally you could use the standalone.xml to do this, but the wildfly bootable JAR seems not to have a standalone.xml since it's all within a single JAR.
The examples that JBoss provides assume you'll only ever use OpenShift for some reason and uses some arcane OpenShift CLI command (below) that just somehow creates the right file in the right spot. https://github.com/wildfly-extras/wildfly-jar-maven-plugin/tree/4.0.0.Final/examples/postgresql
oc new-app --name database-server \
--env POSTGRESQL_USER=admin \
--env POSTGRESQL_PASSWORD=admin \
--env POSTGRESQL_DATABASE=sampledb \
postgresql
However, there is no config file created with that command (or they didnt check it in), and the documentation doesn't say anything about how to do the same for non-OpenShift projects.
Trying to find any info on how to do configure a (postgres) data-source for a non-OpenShift deployment.

Figured this out on my own with some experimentation. WildFly documentation on bootable jars is still really minimal and lacking lots of detail that required lots of guessing / experimenting.
While there is an overlay that lets you specify DB info via environment variables, that's a bit hacky and doesn't allow you to define more than one datasource nor can you specify the JNDI name. Instead, I used a CLI script which gets fed into the jar builder plugin.
datasource.cli
data-source add --name=<name> --jndi-name=java:jboss/datasources/<schema> --driver-name=postgresql --connection-url=jdbc:postgresql://localhost:5432/<db> --user-name=<user> --password=<pass>
Make sure to use your own values for placeholders <name>, <schema>, <db>, <user>, <pass> and swap out the hostname / port if needed.
pom.xml (snippet)
<configuration>
<cli-sessions>
<cli-session>
<script-files>
<script>scripts/datasource.cli</script>
</script-files>
<resolve-expressions>true</resolve-expressions>
</cli-session>
</cli-sessions>
<feature-packs>
<feature-pack>
<location>wildfly#maven(org.jboss.universe:community-universe)#23.0.0.Final</location>
</feature-pack>
<feature-pack>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-datasources-galleon-pack</artifactId>
<version>1.2.2.Final</version>
</feature-pack>
</feature-packs>
<layers>
<layer>jaxrs-server</layer>
<layer>postgresql-driver</layer>
</layers>
</configuration>
In the above XML config, items of note are
<script> value tells the builder where to find the CLI script that will do the datasource adding
<feature-pack> for the datasource pack. Though I didn't test if this was required... maybe the driver layer is all that's needed. Worth trying if you have time.
<layer> that specifies the postgresql-driver value. This is required and without it, the bootup will complain about missing a driver when the CLI script runs.

Invalid path of external Kafka keystore and truststore

My app connects to Kafka topic and everything goes well in local environment when truststore and keystore are stored under classpath, but when I try to switch to Dockerized external environment and point to those files localized on a server, then the app crashes.
Snippet in a local environment where it works:
spring.kafka.ssl.trust-store-location=file:src/main/resources/keys/application.truststore.jks
spring.kafka.ssl.key-store-location=file:src/main/resources/keys/application.keystore.jks
Snippet of application.properties on a server side when the app is launched inside a docker container and does not work. Both keys are stored in /deployment/keys folder inside the container:
spring.kafka.ssl.trust-store-location=/deployment/keys/application.truststore.jks
spring.kafka.ssl.key-store-location=/deployment/keys/application.keystore.jks
The following java exception occurs:
NoSuchFileException: /tmp/tomcat-docbase.45456574985379.8080/deployment/keys/application.keystore.jks
So for an unknown reason Spring Boot inside Docker container adds the /tmp/tomcat-docbase.45456574985379.8080/ prefix to the keystore and truststore location.
I have also tried:
spring.kafka.ssl.trust-store-location=file:/deployment/keys/application.truststore.jks
spring.kafka.ssl.key-store-location=file:/deployment/keys/application.keystore.jks
and
spring.kafka.ssl.trust-store-location=file:///deployment/keys/application.truststore.jks
spring.kafka.ssl.key-store-location=file:///deployment/keys/application.keystore.jks
but none of them seem to work. I would not like to change the code but what comes to my mind is to create a Properties object and create strings with those paths. Then inject them to the KafkaTemplate as a bean. However, I have not yet checked if this could help. Would rather focus just on adjusting application.properties file than correct the code. Could you please help me find the solution?

Play Framework deploy failed: "the application secret has not been set, and we are in prod mode. Your application is not secure"

I'm deploying on Heroku a web application developed with Play Framework.
The deploy fails returning this error:
[error] p.a.l.c.CryptoConfigParser - The application secret has not been set, and we are in prod mode. Your application is not secure.
What does it means that "we are in prod mode"? Where do I set the mode? I have to change this because it's not a production environment.
Thanks

Put this into your conf/application.conf
Play 2.5
play.crypto.secret="changethissosomethingsecret"
Play 2.6+
play.http.secret.key="changethissosomethingsecret"
You can also start your application with a source with a secret key as a parameter.

you need to add an application secret in your conf file.
play.http.secret.key="changethissosomethingsecret"

You need to set up different keys based on the Play version that your application is using.
What version of play are you using?
Either look at com.typesafe.play:sbt-plugin version inside your project's plugins.sbt or if you have a GNU compatible shell, execute the following command:
find . -name "plugins.sbt" -exec grep -PHin --color=always 'com.typesafe.play.*sbt-plugin.*%\s*"\K.*?(?=")' {} \;
Proceed to the next step, once you know the version number of play used by your app.
What is the key to use in application.conf based on play version?
Play 2.3.x: application.secret (defaults to changeme)
Play 2.4.x: play.crypto.secret (defaults to changeme)
Play 2.5.x: play.crypto.secret (defaults to changeme)
Play 2.6.x: play.http.secret.key (defaults to changeme)
As you can see it is not consistent, but what is consistent is:
In the above versions you can override the secret using APPLICATION_SECRET environment variable/property (so, something like APPLICAITION_SECRET="changed" sbt "runProd 9001")
The default value in each case is changeme
The next two options were tested on Play v2.6.x, but according to the documentation, should work with the same commands for v2.4.x and v2.5.x.
The only exception is v2.3.x which uses play-generate-secret and play-update-secret respectively
How do I get sbt to generate a key for me?
Run the following command from within the directory of your play application (tested with sbt v1.1.6 and play v2.6.x):
$ sbt playGenerateSecret | grep -i 'generated'
[info] Generated new secret: ^7UubY[rFXzkN:v6TB9WL/lfGsP61/vzAHA9tdZNZ#nALH=TEztKAlTC>xz;VUXw
You can manually copy the above as the value for the key (based on play framework version as noted before) OR, you can use the suggestion below.
How do I get sbt to update existing key in application.conf automatically?
Same as above, run the following command from the root directory of your play framework app:
$ sbt playUpdateSecret | grep -i "secret"
[info] Generated new secret: Kz?fHm_I[wt^Onp[#cr<:`ttrQi]KMsdDs>22hEF?RhkoanQ7gA6NAjL33EV2^Xt
[info] Updating application secret in /Users/blah/someplayapp/conf/application.conf
[warn] Did not find application secret in /Users/blah/someplayapp/conf/application.conf
[warn] Adding application secret to start of file
Couple of things to note about this command:
playUpdateSecret will update the existing secret or add a secret to application.conf if it is not present.
This commands looks for the key and/or adds/updates it in application.conf only. This is important if you are following the Best Practice.
This best practice refers to creating a separate production.conf that overrides this key from application.conf:
include "application"
play.http.secret.key="somesecretkey"
and then run your app like so:
/path/to/yourapp/bin/yourapp -Dconfig.file=/path/to/production.conf
As you can see, if you are using playUpdateSecret to generate a new secret then it is going to have no effect since it is being overridden by the secret specified in production.conf.

Before you run your application in production mode, you need to generate an application secret
You need generate token for application in production mode, using activator playGenerateSecret
Configuration Application Secret
Link documentation

How to hide weblogic password in jenkins console

We are using Weblogic Deployer Plugin for Jenkins 1.5 to deploy wars via Jenkins in Weblogic servers. The source, target & credentials are managed through default.xml file.
<weblogic-target>
<name>WeblogicServer</name>
<host>localhost</host>
<port>9001</port>
<login>JenkinsUser</login>
<password>deploy</password>
<authMode>BY_LOGIN</authMode>
</weblogic-target>
But in the console output of Jenkins, the password is being shown as plaintext. We have installed Mask Password plugin & configured it, but this is of no help.
Can someone put forward any idea about hiding this password from appearing in the Jenkins console output?

Finally got it! Weblogic Deployer Plugin version 2.3 onwards has built in capability of hiding password. It uses Weblogic's password encryption functionality. I had to just modify the default.xml like this:
<weblogic-target>
<name>WeblogicServer</name>
<host>localhost</host>
<port>9001</port>
<login>JenkinsUser</login>
<password>deploy</password>
<authMode>BY_KEY</authMode>
<userconfigfile>C:\users\MyUser\Desktop\userconfig</userconfigfile>
<userkeyfile>C:\users\MyUser\Desktop\userkey</userkeyfile>
</weblogic-target>
The userconfigfile & userkeyfile are a properties-key file pair which can be generated from either WLST script or cmd. For everyone's convenience am providing the commands below:
Go to your weblogic server installation folder --> bin, open cmd inside that folder & type setWLSEnv + enter.
java weblogic.Admin -adminurl t3://localhost:9001 -userid userid -password password -userconfigfile "Your designated path to store the file" -userkeyfile "Your designated path to store the file" -STOREUSERCONFIG
It will ask for confirmation, press Y & enter, the pair of files will be created. you can validate if this pair works by the following command:
java weblogic.Admin -adminurl t3://localhost:9001 -userconfigfile "Local path where you stored the confing file in previous step" -userkeyfile "Local path where you stored the key file in previous step" -GETSTATE
If it shows RUNNING then the file is working fine!

If you prefer to use Mask Password Plugin you can use the regex: -password\s.* in your job configuration.

[GAE Java]: WARNING: Not using any credentials

In the Java API example they create a Datastore by using DatastoreHelper.getOptionsfromEnv
But this creates the warning
WARNING: Not using any credentials
and leads ultimately to:
DatastoreException(null): beginTransaction 401
I set my environment variables to the following:
export DATASTORE_DATASET={Project-ID}
export DATASTORE_HOST="https://www.googleapis.com/datastore/v1/datasets/{Project-ID}"
export DATASTORE_SERVICE_ACCOUNT="{email address}"
export DATASTORE_PRIVATE_KEY_FILE="{path to local p12 keyfile}"
But still when I try to see what the credentials are:
println("Datastore helper: " +DatastoreHelper.getOptionsfromEnv
.dataset(datasetId).build().getCredential)
I get null, what could be missing?
Also is there either a way to set the Credentials inside the project (instead of using the getOptionsfromEnv)?

The problem was that even though I used
source ~/.bash_profile
to refresh my environemnt variables and the echo command showed me that they were indeed updated, apperently I needed to restart my terminal (using Mac OSX) for them to be also updated for sbt and Scala.
I am not sure why this is the case and if this is Scala specific but now I managed to authenticate and communicate with the server.
I managed to figure it out by using the local installation of the Datastore Server and continuing to have the same problems.