I am using a worker to do some tasks in the background.
When I try to use libraries that depend on the locale (e.g. use spark.formatters.DateTimeFormatter) I notice that they fail, since the locale in the worker is not set at all (e.g. dateTimeFormatter.actualLocaleIDName is null).
How do I set the locale in the worker?
Things I tried that don't work:
FlexGlobals.topLevelApplication.setStyle("locale",LocaleID.DEFAULT);
FlexGlobals.topLevelApplication is null
StyleManager.getStyleManager(null) also returns null, making it impossible to set the property there
StyleManager.getStyleManager(this.moduleFactory) null once more
Things that work but do not solve the problem for me:
Setting the locale style property manually on all DateTimeFormatter etc. instances. This would mean modifying third party library code and maintaining a fork ourselves.
Thanks!
Michael
Related
I'm hosting a service using Windsor's WCF Facility, but I can't get UseSynchronisationContext and ConcurrencyMode set that one would normally do using the ServiceBehaviorAttribute. I've seen two options that apparently should work (but tried both to no avail):
Registering ServiceBehaviorAttribute as a Component for IServiceBehavior
Modifying the Description collection of Behaviors in the OnCreated configuration callback in the WCF registration.
A third method that I've tried is using AddExtensions, but that results in an exception because there's already a ServiceBehaviorAttribute (by default?) in the list of Behaviors. This is also the case with method 2, but in that case I can remove it and add a new one, or modify the existing entry.
It's really frustrating that there doesn't seem any documentation on this except a line stating 'Remove the ServiceBehaviorAttribute' from your services, apparently because it can conflict with the WcfFacility.
Can someone point me on how to properly do this? Any hint is appreciated!
Unfortunately I didn't properly test. Modifying the properties of the ServiceBehaviorAttribute in the list of Behaviors of the Description property in the OnCreated action actually works as intended.
Sample registration:
container.Register(Component.For<IWCFWarehouseServiceAsyncCallback>()
.ImplementedBy<WarehouseService>()
.AsWcfService(new DefaultServiceModel()
.AddBaseAddresses(baseAddress)
.OnCreated(host =>
{
var sb = host.Description.Behaviors.Find<ServiceBehaviorAttribute>();
sb.UseSynchronizationContext = false;
sb.ConcurrencyMode = ConcurrencyMode.Reentrant;
})
.AddEndpoints(WcfEndpoint.BoundTo(binding).At("WarehouseService"))));
I'm working on an app that serves domain classes as json results.
Is there a way to change the default max for the results?
What I'm doing is http://site/domain-class.json and I'm only getting 10 results. I want to avoid creating all the links as http://site/domain-class.json?max=999
Is there a way to increase that default value to something different? I tried searching the source code without any luck. :(
That's not configurable using the #Resource annotation.
However, you can always generate your controller for your domain and modify the implementation of the list() method to have a different default maximum.
Here is the controller which backs a domain which is marked with the #Resource interface annotation. As you can see the default maximum value is not driven by any configuration value.
Using grails generate-controller for your domain will allow you to change that value in the generated controller for your domain.
I'm confused. SharedObject seems have two ways to store value in it, by data and setProperty():
so.data.foo = 'bar';
so.setProperty('boo', 'bar');
What's the different? And why doesn't it have getProperty()?
From the SharedObject reference: setProperty() marks a property as "dirty" in addition to setting it, which you need to do if you're using a remote SharedObject, as it tells the server that the value needs to be updated in other clients.
It's slightly more convenient than manually setting the property and then calling setDirty(), and there's obviously no need to for a similar getProperty() method, as the server doesn't need to be informed when you do that.
My problem is every time after changing the Liferay portal-properties (and this is frequent especially at beginning of a new portal project) I need to restart the whole portal.
Some properties I can set over hook and these values will be changed after redeployment. Also that must be possible to change most portal properties at run time.
However, do you know some approach to reflect changes in portal-ext.properties without restarting Liferay portal?
As stoldark mentioned, this is not possible in a production environment at all. Since portal.properties's properties are loaded at portal start-up.
But for development you can use a tool like JRebel, some steps to configure it here. The only issue you would get with this tool is that it is paid ;-).
I know it is a very old thread but it may be helpful for someone who is looking for some type of work around
As we know there is no straight forward way for this but I did this by using java reflection and class loader.
Liferay Version : 6.x
//Loading the PropsUtil class by using PortalClassLoader
Class<?> prospsUtilClass = PortalClassLoaderUtil.getClassLoader().loadClass("com.liferay.portal.util.PropsUtil");
//getting the reload method of PropsUtil class
Method reloadMethod = prospsUtilClass.getMethod("reload", null);
//Invoking the static reload method
reloadMethod.invoke(null, null);
Reload method (re)loads the portal-ext properties to the portal so we can use new properties without restarting Liferay server.
This has also been asked in Liferay forums:
https://www.liferay.com/community/forums/-/message_boards/message/800954
But I am afraid that most properties are only read once during portal startup.
Usually, the use of a properties file as in this case has this drawback.
There's even an issue open at Liferay about this, but is still unresolved:
http://issues.liferay.com/browse/LEP-5579
If you create a hook to override portal properties, you will be able to change properties with just deploying the hook without restarting the Portal.
Be aware that you cannot modify all properties with a hook. For a list of the ones that you can modify, check out: https://docs.liferay.com/portal/6.2/definitions/.
I've just searched for reloading portal-ext.properties and landed here.
Ok - not a feature in Liferay.
So I'll use an old trick I like:
place custom properties in (liferay-tomcat-home)/conf/filename.properties
reload them whenever you want by
Properties customProperties = new Properties();
customProperties.load(new FileInputStream(new File(System.getProperty("catalina.base"), "conf/filename.properties")));
I must confess I haven't tried this in a Liferay-Portlet-Environment, but this system property ("catalina.base") should be available in this context, at least by using some Liferay-Helper-Class.
Some of the Liferay classes read their properties when initialising static field constants. E.g.:
public static final boolean ENABLED = GetterUtil.getBoolean(
PropsUtil.get(DynamicCSSFilter.class.getName()));
Basically, it is possible to reload the properties (eg via script in control-panel), but all those static constants will remain.
I'm trying to debug an issue where I'm using a JColorChooser. I'm trying to set the local, but it keeps reverting back to the System's Locale despite what UIManager, Locale.setDefault, or JColorChooser.setLocale I set it to.
The locale that I'm setting the JColorChooser differs from the System locale. The rest of my applet is using the requested UI.
I've tried the following:
JColorChooser colors = new JColorChooser();
colors.setLocale([spanish]);
Locale.setLocale([spanish]);
UIManager.getDefaults().setDefaultLocale([spanish]);
However, none of those options changes the component.
EDIT
as I mentioned earlier (below :-), JColorChooser (and most other localizable pre-fabricated components) locale support is suboptimal (aka: buggy). Setting its locale property directly simply doesn't work. Per-application setting worksforme (my system default is German), though:
Locale.setDefault(new Locale("es"));
Do so very early in the application code, best before creating any component, gives the best chances to get the expected non-system localized texts.
Original answer (having ranted a bit)
Localization support in Swing is half-hearted, to put it mildly.
Part of the problem is an impedance mismatch between the locale resolve mechanism between AWT vs Swing: the former resolves up the parent chain, expecting most of the children to have a null locale property, the latter explicitly sets the default as returned by JComponent.getDefaultLocale() very early in its life (in JComponent constructor). The other part of the problem is that a setLocale fires a change event as appropriate .. but nobody listens. That has dramatic consequences for pre-fabricated containers like f.i. JColorChooser: the ui delegate should update the locale property of all children but simply does nothing. (It's easy to overlook - SwingX components like datePicker had the same problem, hopefully fixed now ;-)
What is even worse: for some reason, the ui doesn't even respect the default as set on JComponent ...
So, the only way to make it completely respect any locale seems to be to set the default locale on Locale and then restore it afterwards (if you want to have only the color chooser in that locale, which I don't think is what you want :-)
Locale old = Locale.getDefault();
Locale.setDefault(new Locale("es"));
JColorChooser chooser = new JColorChooser(Color.RED);
Locale.setDefault(old);
ahhh .. all panels (DefaultXXChooserPanel) installed by the ui are buggy in that they get the localized text by
// wrong:
UIManager.getString(somekey)
instead of
// correct
UIManager.getString(somekey, appropriateLocale)