Reputation: 564
We ran to this behaviour on our MFP 7.1 which wasn't the case on WL 6.2 where it raised an alert in our team.
Issue clarification:
In Worklight.properties I have an entry:
ENV = MFP-DEV.
I'm using and adapter to read this property:
var environment = WL.Server.configuration["ENV"];
WL.Logger.info ("Env Enabled is :" + environment);
I compile my server code and create the war file to be deployed on my actual server. When I deoply the war file, the "EVN" entry comes as empty which is the same case as we had when we were running WL 6.2.
The isse is that in WL 6.2, if I didn't assign the value on the server level. The output of my adapter for this entry comes as "undefined"
WL.Logger.info ("Env Enabled is :" + environment);
// Env Enabled is undefined
However, in MFP 7.1 for the same test. The result comes as:
WL.Logger.info ("Env Enabled is :" + environment);
// Env Enabled is MFP-DEV
That means the MFP server is actually reading the worklight.properties to get the assigned value of the entry which is inside the war file if the JNDI value is not set on the server level. Unless I put an actual value in the JNDI, the server will always read the default one inside its war file.
This raised a concern for the following properties as we don't assign any values to them on the JNDI server.
Default values in worklight.properties:
#The path to the keystore, relative to the server folder in the MobileFirst Project, for example: conf/my-cert.jks
wl.ca.keystore.path=conf/mfp-default.keystore
#The type of the keystore file. Valid values are jks or pkcs12.
wl.ca.keystore.type=jks
#The password to the keystore file.
wl.ca.keystore.password=jYCuzgPNXNMLKfmlk6WM
#The alias of the entry where the private key and certificate are stored, in the keystore.
wl.ca.key.alias=mfp-default-cert
#The password to the alias in the keystore.
wl.ca.key.alias.password=82ShbwXc0KD5ni9Zc6yq
Server JNDI:
Is there any recommendations on how to handle this?
Server version: 7.1.0.00.20160401-2103
Upvotes: 0
Views: 129
Reputation: 44516
It sounds to me more like a bug that was fixed.
You have set a custom property in worklight.properties and in v7.1 you can actually get to said property in your adapter code. That's great. Change your implementation accordingly.
I also do not see the relation to the other properties you've mentioned.
You say there is a "concern" and "issue", but you do not specify what is the "concern" and "issue".
Upvotes: 0