In portals, all the resources that are not portlets themselves but are accessed through portlets - reading
PortletRequest, and writing to
PortletResponse - are referred to as 'bridged'.
Any resources that are accessed directly, bypassing portal filters and servlets, are referred to as 'non-bridged'.
Non-bridged servlets, and .jsps have no access to
PortalRequest. They do not use
to determine current
Locale. Instead, they use
which is subject to precise semantics defined by Servlet specification - it reflects browser's language
In other words, non-bridged resources do not have a notion of current
in the same sense that portlets do. The result is that when mixing portlets and non-bridged resources there may be
a localization mismatch - an inconsistency in the language used by different resources composing your portal page.
This problem is addressed by
LocalizationFilter. This is a filter that changes the behaviour of
method so that it behaves the same way as
PortletRequest.getLocale(). That way even localization of
servlets, and .jsps accessed in a non-bridged manner can stay in synchronization with the portlet localization.
is installed through the
file of the portal.
One tiny limitation to this mechanism is that it is unable to determine the current portal, and consequently
its default language. As a result, the
English, but can be configured to something else by using filter's
init param. For example:
is applied to *.jsp, which is considered the minimum required by GateIn 3.5 to properly keep its non-bridged
resources in synchronization with the rest of the portal. Additionally, deployed portlets and portal applications
may need broader mapping to cover their non-bridged resources.
,/private/*, and similar broad mappings as
sometimes adversely interacts with the processing of portlet requests. Use multiple filter-mappings instead to
specifically target non-bridged resources.
Keeping the mapping limited to only non-bridged resources will minimize any impact on performance as well.