We built a website with Tapestry 5.1.0.5 and we encounter, sometimes, a missing key problem when we hit the start-page.
This problem appeared only 4 times, this is a random issue.
Actual configuration:
configuration.add(SymbolConstants.SUPPORTED_LOCALES, "fr"); => so the default local is fr and not en
configuration.add("tapestry.start-page-name", "Accueil"); => so when we hit / tapestry redirects us on /accueil
Here is the problem we sometimes see:
When hitting / tapestry searches keys in *_en.properties instead of *_fr.properties but if we hit /accueil tapestry searches keys in *_fr.properties.
Trace log :
Caused by: java.lang.NumberFormatException: For input string: **"[[missing key: prehome.store.opening.delay]]"**
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:447)
at java.lang.Integer.parseInt(Integer.java:497)
at XXXXXXX.tapestry.components.overlayer.StoreOverlayer.initStoresAndRegions(StoreOverlayer.java:652)
at XXXXXXX.tapestry.components.overlayer.StoreOverlayer.setupRender(StoreOverlayer.java)
at org.apache.tapestry5.internal.structure.ComponentPageElementImpl$SetupRenderPhase.invokeComponent(ComponentPageElementImpl.java:184)
at org.apache.tapestry5.internal.structure.ComponentPageElementImpl$AbstractPhase.run(ComponentPageElementImpl.java:164)
at org.apache.tapestry5.internal.structure.ComponentPageElementImpl.invoke(ComponentPageElementImpl.java:933)
... 94 more
01-02-2012 11:55:52:979 23120252 ERROR org.apache.tapestry5.internal.services.InternalModule.PagePool - Page Page[Accueil en] is dirty, and will be discarded (rather than returned to the page pool).
Has anyone had this problem?
Do you know why when we hit the start-page, tapestry use en locale instead of our default locale fr?
I'd say that if you want to ensure that default locale is French, then just rename all message_fr.properties to message.properties.
Also please take a look into browser settings. If your browser is requesting English version of the site, then Tapestry obeys. You may override that behavior, but I'd suggest treating that like a feature (as user is getting site related to his preference) rather than a bug.
And last hint, if you are supporting more than one language then list them all in supported locales constant.
-= Edit =-
it's also probably worth checking do you have the global messages.properties file in English or in French
Related
I am working with ESAPI to try and validate windows directory paths. For some reason, the part of my directory path named \14\ is getting converted into a CRLF. The error I am receiving is below, what am I not understanding correctly? I feel like my regex should be working.
WARN IntrusionDetector [SECURITY FAILURE Anonymous:null#unknown -> /project-test/IntrusionDetector] Invalid input: context=directoryPath, type(DirectoryName)=^[a-zA-Z0-9:/\\!##$%^&{}\[\]()_+\-=,.~'` ]{1,255}$, input=C:\UsersTESTUS~1AppDataLocalTempTestCase8002TempWorkSpace, orig=C:\Users\TESTUS~1\AppData\Local\Temp\14\TestCase8002TempWorkSpace
As you can see, I am using the regex:
^[a-zA-Z0-9:/\!##$%^&{}[]()_+-=,.~'` ]$
My input is:
C:\Users\TESTUS~1\AppData\Local\Temp\14\TestCase8002TempWorkSpace
Ouput, after ESAPI does canonicalization and validation:
C:\UsersTESTUS~1AppDataLocalTempTestCase8002TempWorkSpace
Here is the line of code that causes me to receive the error;
String validatedSourcePath = ESAPI.validator().getValidInput("directoryUnzip", directory, "DirectoryName", 255, false);
File validFile = new File(validatedSourcePath);
#C.Williams: I was about 30 minutes into writing up a detailed reply in an editor and accidentally excited my editor window. I'm too ticked off at my stupidity of not saving it to write it again, especially since I was only about 75% done.
However, if you want to email me I can arrange to talk to you via Google Hangouts or Signal to tell you want your problem is and how you can fix it. But it's long and complicated and partially related to a bug the ESAPI team just fixed but is not in any official release yet. But I am not going to take another 45 minutes or more trying to reply with any written text. My email address should be easy enough to find. Just google for my name and ESAPI. I am one of the project co-leaders on ESAPI.
-kevin wall
I'm trying to display something like:
Welcome John Doe
In my Liferay Velocity Based Template which is used in a WebContent on Liferay 6.2 GA1 CE
So far the code i have is the following:
#set ($userLS = $portal.getClass().forName('com.liferay.portal.service.UserLocalServiceUtil'))
#set ($userId = $getterUtil.getLong($request.get("theme-display").get("user-id")))
#set ($user = $userLS.getUserById($userId))
<div class="user-welcome">
#if($user.isMale())
<span class="welcome-msg">Bienvenido</span><br>
#else
<span class="welcome-msg">Bienvenida</span><br>
#end
<span class="username">$user.getFullName() $user.getLastName()</span>
</div>
The errors i'm having are:
$user.isMale() always returns false
in my span.username the output is the code itself. It doesn't print the value.
Thanks in advance
Edit: The answer to your question upfront, I'll leave the rest of the explanation below:
If you want to access the current user, you can get it from $permissionChecker. So just replace your first three lines with this:
#set( $user = $permissionChecker.getUser() )
Here's my old explanation on why the technique used in your question didn't work:
Check $userLS.getClass().getName(): It's already not resolving properly. The reason most likely is this setting:
#
# Set a comma delimited list of Java classes the Velocity engine cannot have
# access to.
#
velocity.engine.restricted.classes=\
java.lang.Class,\
java.lang.ClassLoader,\
java.lang.Thread
Check this Wiki article to learn about serviceLocator, but be aware that it is - for good reasons - also unavailable from templates.
#
# Set a comma delimited list of variables the Velocity engine cannot
# have access to. This will affect Dynamic Data List templates, Journal
# templates, and Portlet Display templates.
#
velocity.engine.restricted.variables=serviceLocator
If you're the only one writing templates (or if you trust everyone doing so) it's fine to change this configuration in portal-ext.properties: Configure serviceLocator to not be restricted, then call
#set($userLocalService = $serviceLocator.findExceptionSafeService(
"com.liferay.portal.service.UserLocalService"))
On the positive side: This will ease error handling, as the exceptionSafeService will transparently ignore all exceptions - velocity can't handle them and without this behaviour you'd see no result (and no hint for the error message) at all, should an exception occur ever.
related to this bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7028073 i need to fix the display of the currency format for PERU.
How can i change the properties for de locale of PE_es?
Currenctly the currency is shown as S/ but it should be "S/.".
Can i just replace the properties file? i am looking for a soluction in the jre instalation or the code. I have tried looking for the file without luck.
Java version is 1.7.0 _22 b11
Thanks
The bug you mentioned is already fixed in the version 8u34. However, starting tomorrow, there will be a new "bug" (until it is changed/fixed).
Starting Dic 15th, the Peruvian Symbol will be S/ (without the dot).
Depending on which version of the JVM you currently have, you may (or may not) run into this problem. In case you currently have the last version, your only options might be:
Use a workaround for Peruvian Currency
Wait until they update the JVM with the change so you can update it.
Regarding the second point, you may also want to file a bug/change report (similar to the bug_id 7028073).
Source: El Peruano (Article 2) (Source is in Spanish).
A possible solution for that is make a little function to make it manually:
public String getPeruvianCurrencyFormat(double value)
{
NumberFormat nf = NumberFormat.getNumberInstance();
nf.setGroupingUsed(true);
return "S/. " + nf.format(value);
}
I try to use i18n localization but I have stuck.
If I use:
I18n i18n = new I18n(slingRequest);
i18n.get("myMessage");
I always get the english message for key: myMessage.
In accept-language header I can see these values: de,en;q=0.5
but:
request.getLocale() returns: en
request.getLocales() returns: en
If I use code below everything is good:
Locale myLocale = new Locale("de");
ResourceBundle resourceBundle = slingRequest.getResourceBundle(myLocale);
I18n i18n = new I18n(resourceBundle);
Why don't cq read "accept-language" request headers?
ps: I use standalone cq jar...
Thanks in advance!
CQ/Sling (as of 5.6) does not read the Accept-Language header for the locale you get via slingRequest.getLocale() (or slingRequest.getResourceBundle(null) which implicitly uses that locale), instead it uses the user's language setting (~/preferences/#language in the JCR) or a configurable default (1).
The reasoning is that a fixed setting is much stabler, also when using different browsers across devices, than guessing the language header.
But it's extensible: you can hook in a custom org.apache.sling.i18n.RequestLocaleResolver service (with a higher service rank), which is the service that provides the value for slingRequest.getLocale() (2). This could also take the accept language into account; it gets access to the underlying servlet request object, which should give you the Accept-Language header value in getLocale() and getLocales() (at least the built-in servlet engine in CQ does that since 5.4).
(1) Configure default locale on this service: http://localhost:4502/system/console/configMgr/org.apache.sling.i18n.impl.JcrResourceBundleProvider
(2) Sling's I18nFilter which you probably have seen in stack traces already does all the magic and wraps the request to provide the slingRequest.getLocale() and slingRequest.getResourceBundle() implementations using the RequestLocaleResolver and ResourceBundleProvider services
Is the first code example copy pasted? If the sample is pasted from your code, then a typo in your key may be the issue because the language key in your example is "myMesage" and not "myMessage" as indicated later in your post.
How to provide multi language support through JSP/Servlet? How to include static data of different languages at run time on basis of language selected?
In a "plain vanilla" JSP/Servlet application, the best solution is the JSTL fmt taglib. (just drop jstl-1.2.jar in /WEB-INF/lib) How to use it is covered in Oracle Java EE 5 tutorial part II chapter 7 and in this answer: How to internationalize a Java web application?.
If you're using a MVC framework such as Oracle JSF or Apache Struts, then you need to consult its specific documentation using keywords "internationalization" (i18n) or "localization" (l10n). In most cases they also provides specific tags for that, such as <f:loadBundle> in case of JSF, which in turn is covered in Oracle Java EE 5 tutorial part II chapter 15.
Those i18n tags already checks the default language/locale by ServletRequest#getLocale() (you don't need to do it "low-level" by checking the header as one suggested before --which would involve more work parsing the header as per the HTTP spec). You can let the user choose the language itself (dropdown?) and store it in the session scope and instruct those taglibs to use it. Here's an example with JSTL fmt taglib:
<fmt:setLocale value="${someSessionBean.locale}" />
..where ${someSessionBean.locale} can return en, en_US, en_UK, etc. Those are in turn used by the java.util.ResourceBundle API to load the localized text (you don't need to create/load the ResourceBundle itself, the taglibs already do that, just read the linked javadoc to learn a bit more about how it works).
If you want the language available as first pathinfo part of URL (such as http://example.com/en/, which is best for SEO), then you can best use a Filter for this which listens on /*, checks the pathinfo, splits the language part from it, stores/compares it as/with session value and forwards the request without language part in pathinfo further to the desired front controller.
There are several important aspects to this issue. The first part is determining each request's locale. You can use something like this:
HttpServletRequest req ...;
String browserLocale = req.getHeader("Accept-Language"); // typically something like 'en'
Next, you need to decide how to manage the site's localized content. The most Java-like (not necessarily the best) approach is to externalize all messages using a ResourceBundle. You can learn about the core Java facilities for I18N, G13N in their Isolating Locale Specific Data tutorial.
Using only this approach is quite poor in my opinion. Different languages' content size differently, match better with different layouts, etc. So you can completely eliminate resource bundles (if you don't have a lot of multi-locale data) or augment the approach by using XSLT or other templating that is locale specific.
One very performant but high-development overhead approach is to use a servlet filter to redirect traffic to language- (or locale-) specific subsites. In this case, anyone hitting http://my.domain.fake/xyz would get redirected to http://my.domain.fake/en/xyz
Finally, it is worth noting that most of the serious web frameworks have their own I18N support. Their approaches differ based on the framework philosophy.
We can to create messages.properties, messages_????.properties and to place this files into /scr/java directory. (where ???? - en_US, ru_RU and other)
Example lines into messages.properties:
About = About
Buy = Buy
Company = Company
ContactUs = Contact Us
Then to paste into jsp file for example lines:
Locale locale = Locale.getDefault();
String lng = locale.getCountry();
session.setAttribute( "language", lng);
if (lng.equals( "UA"))
locale = new Locale( "uk", "UA");
else if (lng.equals( "RU"))
locale = new Locale( "ru", "RU");
else
locale = Locale.US;
ResourceBundle boundle = ResourceBundle.getBundle( "messages", locale);
for (Enumeration e = boundle.getKeys(); e.hasMoreElements(); ) {
String key = (String) e.nextElement();
String s = boundle.getString(key);
session.setAttribute( key, s);
}
Now you can paste ${name} into next jsp code (${About}, ${Buy}, ...).