Christian,
Yes, good point. Even encrypted would be bad. But picking up an encrypted
password from the environment should work and let me put that in the
features for the environments.
I usually stay out of DevOps as much as possible but I'm in a situation at a
client where the previous group of developers really didn't have any idea
about what they were doing. The broke classloaders by duplicating schemas
and regenerating classes in different bundles which meant that identical
package/classes were incompatible because they came from different bundles.
Because they couldn't figure it out, the then converted everything to a
String before dumping it on JMS and then substring parsed stuff they pulled
off...I could go on.
Since they really didn't know anything about this (I believe they are
CSharpies), the created Windows batch scripts to set up all the environments
and scrape the cfg files.
Now that I'm prototyping a Fuse 7 instance with Netty HTTP server as and
OSGi service (thanks Guillaume!) with Camel RESTful DSL, SCR connector
classes with OSGi services using PAX-JDBC, dozer converters to cannoical
models and features file to manage all of it, I'm trying to ensure that I
cut them off at the pass and we don't end up with 20 batch files to run to
install and configure it.
Most of it should be done by Jenkins at build time but security is an
exception. I usually stay out of this side of the equation but assume that
the password would be in the config something like this:
password=ENC(${env:ENCRYPTED_PASS})
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
