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.
Related
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
It is possible using multiple RAML files in one APIKit Mule Project?
Let's say I have two functions /api/func1 and /api/func2.
Each of the functions is defined in its own raml - func1.raml and func2.raml.
I've generated a flow in Anypoint for the first function using the APIKit wizard. It's working ok.
Now, I'm trying generating a flow for the second function. The flow is generated with no errors. However, it just doesn't work. I've tried fixing the URLs, bindings, configurations and nothing really helps.
Note, that I don't wanna bind both the RAMLs into one file. The reason is that it's easier to develop/maintain the functions separately.
The only solution I can see is to define two separate projects. But this is not really what I'd like to do.
So, looking for an advice of how to deal with this situation.
Thanks,
Ok, actually, it's possible.
What you need to do is make the "Path"es different in the HTTP connectors for the flows generated.
The apikit wizard generates the default path that looks like this: "/api/*".
So, Mule generates an error when attempting to deploy the app. What you need to do is changing paths to "/api/func1/" and "/api/func2/"
You can continue having a single RAML file and make external references to simplify your raml, here is an example:
#%RAML 0.8
title: Eventlog API
version: 1.0
baseUri: http://eventlog.example.org/{version}
schemas:
- eventJson: !include eventSchema.json
eventListJson: !include eventlistSchema.json
Also going by strict REST design it is recommended to have a resource related details maintained in a single RAML file.
Optionally you may edit the url's to resolve any context related conflict.
I'm writing functional test and having difficulty mocking http:request-config with oauth2. It failed at requesting for token. I tried moving the config to a separate file and create a different config in src/test/resources and include only the test config when testing. Now it complains about "name must be unique" - how do I get around this?
Be sure that your getConfigFiles() override does not include the configuration file that contains the original . This means it will need to be in a separate file from the one containing the flow you are testing.
Another method is to use a mock HTTP server such as sham-http.
In order to test Mule application you can use MUnit:
http://developer.mulesoft.com/docs/display/current/MUnit
It will allow you to mock message processors.
Now, config elements are top level elements. Those can not be mock.
I would suggest you take a look to documentation to see if the tool fit your needs.
HTH
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.
I need to update the JSF2.0 (Primefaces) tooltips dynamically without server restart.
Meaning need to find a way where tooltips (atm from properties file) of the a running application can be changed without requiring a server restart.
We are running websphere and deploying a non exploded EAR (can probably convince to deploy exploded war)
Any Ideas or tips please. Thanks you
The value attribute of the p:toolTip component must be an EL expression or a literal text. Usually, one would reference a resource bundle declared using the var attribute of the f:loadBundle tag, in the EL expression for the tooltip.
The underlying resource bundle declared using the basename attribute could be backed by a property file itself (in which case you need to place the property file in the appropriate directory on the classpath), or for that matter it could be a custom ResourceBundle implementation that could read from a properties file (located outside the container), or a database or any store for that matter.
You could therefore change your existing EL expression from the existing one defined as:
<f:loadBundle var="msg" basename="propfile_location" />
to
<f:loadBundle var="msg" basename="fully qualified class name of the ResourceBundle class" />
In simpler words, you will need to roll your own ResourceBundle class(es) to support the various locales. Needless to state, but you will need to override the ResourceBundle.getObject(java.lang.String) method, as it is invoked by the ResourceBundleELResolver implementation when evaluating the EL expressions referencing ResourceBundles.
Additionally, you will need to ensure that the ResourceBundle.getObject(java.lang.String) implementation of your ResourceBundle will always re-fetch and return the value corresponding to the provided key. Failure to ensure this would mean that the initial value fetched by the resource bundle may be returned on subsequent invocations, especially if you are caching the initial value. You are likely to encounter this behavior even if you deploy an exploded WAR file where you can modify the property file contents without a redeployment of the application, and that is why it is important to use a custom ResourceBundle implementation that does not cache values.