We're connecting to documentum server from Java progream (using dfc.jar) to pull the documents.
In order to connect to the server, it requires us to make dfc.properties available in the classpath.
We already have one master properties file, so want to avoid having one more. Instead, we want to put the properties inside the other properties file and then use them while connecting to the documentum server.
I could find how to use docbroker host and port from Java code, i.e. using IDfTypedObject.
IDfLoginInfo loginInfoObj = clientX.getLoginInfo();
loginInfoObj.setUser(user);
loginInfoObj.setPassword(pwd);
IDfClient client = new DfClient();
IDfTypedObject cfg = client.getClientConfig();
cfg.setString("primary_host", "myhost");
cfg.setInt("primary_port", myport);
IDfSession docbase_session = client.newSession(docbase, loginInfoObj);
Like primary_host and primary_port are being set in the code, is there a way to set through code, the following properties from dfc.properties?
dfc.globalregistry.repository
dfc.globalregistry.username
dfc.globalregistry.password
The DFC properties must be in its own file. This file can however reside outside the application itself.
Option 1: Include
Put an include statement in the beginning of the dfc.properties in your classpath to point at the external configuration, like this:
#include /path/to/external/dfc.properties
You can even use hybrid approaches by including several files and/or appending/overwriting in your app's dfc.properties:
#include /path/to/common/dfc.properties
#include /path/to/more/specific/dfc.properties # may or may not override
<app specific parameters go here> # may or may not override
Option 2: Environment variable
Set the environment variable dfc.properties.file to point at your external dfc.properties. Change your appserver's startup to something like this:
java ... –Ddfc.properties.file=/path/to/external/dfc.properties ...
If you're using Tomcat, you can do this by setting a system variable on the OS itself:
set JAVA_OPTS=–Ddfc.properties.file=/path/to/external/dfc.properties
To summarize
I would not recommend setting DFC parameters in code. Best practice is to have a dedicated configuration file outside the application. Beware that your execution enviroment (JVM) must have access to the file system as necessary. This applies to both alternatives above.
Despite the fact that you need to have connection information for global registry you really don't need to have those details correct. Of course unless you want to use BOF (TBO/SBO) features.
In your case, if you don't need it (BOFs), just leave dfc.properties in place with dummy data for global registry and continue to use code for dynamically setting docbroker connection details.
Just to add that if using the classpath to define the location of the main dfc.properties then the dfc.properties file needs to be in a jar or zip file or it will be ignored.
Related
Currently I read properties file by defining a global element like;
> <configuration-properties doc:name="Local Configuration Properties"
> doc:id="899a4f41-f036-4262-8cf2-3b0062dbd740"
> file="config\local_app.properties" />
But this is not enough for me
when try to deal different clients dynamically.
Usecase
I need to pick right configuration file when request comes in. That is, for different clients I have different properties file.( their credentials and all different). When request is received from listener, i'll check with clientid header and based on that value, i'll pick right configuration file. My properties files are added to different location.(Doing deployment through openshift.) Not within mule app. So, we don't need to redeploy the application each time, when our application supports new client.
So, in this case, how to define ? and how to pick right properties file?
eg:
clientid =google, i have properties file defined for google-app.properties.
clientid=yahoo, i have properties file defined for yahoo-app.properties.
clientid=? I'll add properties file ?-app.properties later
Properties files are read deployment time. That means that if you change the values, you to redeploy the application to read the new ones. System properties need a restart of the Mule Runtime instance to be set. And Runtime Manager properties need a restart of the application. In any case the application will restart. Properties can not be used as you want.
There is no way to use configuration properties dynamically like that. What you could do is to create a module using Mule SDK that read properties files and returns the resulting set of properties, so you can assign the result to a variable, and use the values as variables. You will need to find a way to update the values. Maybe set a flow with a scheduler to read the values with a fixed frequency.
I am currently trying to extract property values from my properties file, but am running into some problems. I can't test this in ML query console, because the properties file doesn't exist there. I am currently trying to grab the values of the file like this
let $port := #{#properties["ml.properties-name"]}
I've also looked at
xdmp:document-get-properties(
$uri as xs:string,
$property as xs:QName
however that is limited to .xml files I believe. Does anyone have a way/work-around of accessing these values? I can't seem to find one I've looked at some documentation on Marklogic's website, but can't seem to get anything to work. The way I was accessing before was in ruby, through monkey-patching allowing me to access those private fields.The problem with that is the ruby script I call is only called once, while my .xqy file is ran every minute that sends args to another function. I need to access those args from the properties file, right now I just have them hard-coded in. Any thoughts?
Thanks
You cannot access deployment properties like that, but you can pass them along with deployment. If you create a new REST app with latest Roxy, you should get a copy of this config.xqy added to src/config/:
https://github.com/marklogic-community/roxy/blob/master/deploy/sample/custom-config.xqy
That file is treated specially when deployed to the modules database. Properties references are replaced inside there. In your case, add another variable, and give it a string value following the #ml.xyz pattern:
declare variable $c:port := "#ml.property-name";
You can then import the config lib, and use it in your code.
These so-called Deployer Substitutions are described in more detail on the Roxy wiki:
https://github.com/marklogic-community/roxy/wiki/Deployer-Substitutions
I know that local.Properties overrides project.Properties.
I also know that that these files define… database connections, ports, build environment, frontend HTTPS, etc.
I further know that project.Properties contains more properties.
Will appreciate if Hybris experts tell me syntax of local.Properties, illustrating with some example.
Please provide correct info.
If we talk about the syntaxes of entries in the project.properties file, then it is key=value
The property files in the hybris are of two types:
The extension level - The property file project.properties is the configuration file that carries properties in the key-value pair for the configurations involved on the extension level For instance, Consider a property in the project.properties of the yacceleratorstorefront (storefront template) extension storefront.storelocator.pageSize.Desktop=10 which clearly indicates the 'StoreLocator' results page size configuration per store. Since the store locator functionality is specific to the storefront and has no relevance for the other modules (like core, facades etc), the property is kept at the extension level.
Please note, project.properties reside in the extension folder
The global level - This is the property file which is the global configuration file, and deals with the properties are extension agnostic and carry a global impact. For instance the property commerceservices.default.desktop.ui.experience=responsive sets the ui experience to responsive mode that specifies the deployment to be for the responsive format.
The local.property file supersedes all of the properties with the same key that is defined in any of the project.proprties.
Please note, the local.properties file reside in the hybris/config folder
The hybris registry creates a property configuration map which constitutes all of the properties mentioned in the deployment configuration. The same could be managed in the HAC under platform/configuration.
The clear intent of the local.proprties file is to have information which either requires to be overriden on a global level. The override may be of different types, e.g. cart expiry time could be made different on different environments by the use of the local.property files.
For further reading, please refer to the link: https://wiki.hybris.com/display/release5/Configuring+the+Behavior+of+the+hybris+Commerce+Suite
property call hierarchy (from primary to secondary):
java -Dproperty.key=something
hybris/config/local.properties
hybris/*/(extension-name)/project.properties
hybris/bin/platform/project.properties
and within java code:
configService.getString("property.key", "last fallback value, if no propertyfile provide this key");
You could review all current variables using the hac interface for properties: http://localhost:9001/platform/config
I have a clustered environment that has two WebSphere Application Servers.
In side the Process definition > Java Virtual Machine > Custom properties section for my servers I store several properties.
Is there any way to share values in this section between two app servers?
I don't think you can share JVM custom properties among multiple servers. However, you can create WebSphere variables (Environment > WebSphere Variables). When you create a variable there, you can choose a scope that will allow the variable to apply to multiple servers. That variable won't work the same as a JVM custom property, so what happens next depends on how the variable is used. If you need to access the variable inside the application, see this link:
http://www.slightlytallerthanaverageman.com/2007/04/02/access-websphere-variables-in-j2ee-applications/
If you need it to act like a JVM custom property, WAS might do variable expansion on JVM custom proerties. Say you defined a WebSphere variable named "WAS_VAR_X" and needed that variable to be set as a JVM property named "jvmPropertyX." You might be able to define the JVM custom property with:
Name: jvmPropertyX
Value: ${WAS_VAR_X}
I haven't tried this myself, so if you try it and it doesn't work, reply so I can edit the answer.
Maybe you can use database/cache(redis, etc) storing the share value.
When the app startup, load properties from database/cache(redis, etc).
Also you can change the properties and the other server can load new shared values.
I want to do custom configuration parameters in config.yml
Example:
In config.yml file
security_enhancement:
authentication:true
authorization:true
In same format like swiftmailer configuration etc.I'm not getting idea how to define.
I'm getting error like:
1/2 ParseException: Unable to parse in "\/var\/www\/demo\/app\/config\/config.yml" at line 217 (near "authentication:true").
Am I missing something here? Is it necessary to add in depending injection extension file? .Actually I want to enable disable authentication,authorization execution during dev mode which is implemented in listener which can be done using config_dev.yml . I don't want to add under Parameters. Any suggestions?
As you've rightly theorised, you do indeed need to add in DI extension files, assuming your configuration relates to particular bundles (which it almost certain will).
Whilst parameters can simply be defined at will, configuration features hierarchical structure and validation.
Usually, configuration is used to in turn, define parameters, but it allows for the values to be parsed and validated prior to their instantiation, so that bundle writers can provide better guidance as to how their services can be used (with meaningful errors), and trust the values that are being passed into them.
A decent read on how to get started with config component can be found in the Symfony2 docs: defining and processing configuration files with the config component.