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.
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'm trying to use the new long path support at my app. In order to use it, without forcing clients to have the newest .NET 4.6.2 version instelled on their machines, one should only add those elements to his app.config (see the link for more info https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcing-net-framework-4-6-2/) :
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5.1"/>
</startup>
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
</runtime>
When I use it in my execution project it works perfectly. The problem is in my testing projects (which use Nunit). I've added app.config to my test project in the same way I've added it to the execution project.
Using the ConfigurationManager class I've managed to ensure that app config indeed loaded (in short: using an app setting which i was able to retrieve in a unit test).
Using ConfigurationManager.GetSection("runtime"), I even managed to ensure the runtime element has been loaded properly (_rawXml value is the same as in app.config).
But (!) for some reason the app config runtime element is not influencing the UseLegacyPathHandling variable and therefore all of my calls with long path fail.
I guess the problem is somehow relates to the fact that testing projects become dll's that are loaded using the Nunit engine, which is the execution entry point.
I'm facing the exact same problem in another project I have, which is a dll loaded by Office Word application. I believe the problem is the same in both cases and derived from the fact that the projects are not meant to be an execution entry point.
It's important to understand that I've no access to the executions their self (Word Office or Nunit) and therefore I can't configure them myself.
Is there an option to somehow make the AppContextSwitchOverrides get loaded from scratch dynamically? Other ideas will be most welcome.
I've been having the same issue, and have noted the same lack of loading of that particular setting.
So far, what I've got is that the caching of settings is at least partly to blame.
If you check out how it's implemented, disabling the cache has no effect on future calls to values (i.e. if caching is enabled and something is accessed during that time, then it will always be cached).
https://referencesource.microsoft.com/#mscorlib/system/AppContext/AppContext.cs
This doesn't seem to be an issue for most of the settings, but for some reason the UseLegacyPathHandling and BlockLongPaths settings are getting cached by the time I can first step into the code.
At this time, I don't have a good answer, but if you need something in the interim, I've got a highly suspect temporary fix for you. Using reflection, you can fix the setting in the assembly init. It writes to private variables by name, and uses the specific value of 0 to invalidate the cache, so it's a very delicate fix and not appropriate for a long term solution.
That being said, if you need something that 'just works' for the time being, you can check the settings, and apply the hack as needed.
Here's a simple example code. This would be a method you'll need in your test class.
[AssemblyInitialize]
public static void AssemblyInit(TestContext context)
{
// Check to see if we're using legacy paths
bool stillUsingLegacyPaths;
if (AppContext.TryGetSwitch("Switch.System.IO.UseLegacyPathHandling", out stillUsingLegacyPaths) && stillUsingLegacyPaths)
{
// Here's where we trash the private cached field to get this to ACTUALLY work.
var switchType = Type.GetType("System.AppContextSwitches"); // <- internal class, bad idea.
if (switchType != null)
{
AppContext.SetSwitch("Switch.System.IO.UseLegacyPathHandling", false); // <- Should disable legacy path handling
// Get the private field that is used for caching the path handling value (bad idea).
var legacyField = switchType.GetField("_useLegacyPathHandling", System.Reflection.BindingFlags.Static | System.Reflection.BindingFlags.NonPublic);
legacyField?.SetValue(null, (Int32)0); // <- caching uses 0 to indicate no value, -1 for false, 1 for true.
// Ensure the value is set. This changes the backing field, but we're stuck with the cached value for now.
AppContext.TryGetSwitch("Switch.System.IO.UseLegacyPathHandling", out stillUsingLegacyPaths);
TestAssert.False(stillUsingLegacyPaths, "Testing will fail if we are using legacy path handling.");
}
}
}
I need to access the location of the change log file so that I can get the URL of other files that are in the same directory from a custom task.
The Change interface has a setter for the ChangeSet object which can be used to get the change log file, but the CustomChangeTask interface does not have this method.
From my understanding I need to use CustomChangeTask as my task does not generate SQL.
This is my question. I have decided to implement AbstractChange. It works just fine doing that and returning an empty array of SqlStatements.
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 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.