[gatein-issues] [JBoss JIRA] Updated: (GTNPORTAL-933) Remove custom_*.* resource bundles from portal.war

[Patrice Lamarque (JIRA)]

     [ https://jira.jboss.org/jira/browse/GTNPORTAL-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Patrice Lamarque updated GTNPORTAL-933:
---------------------------------------

    Description: 

custom_* resource bundles are provided inside portal.war and contain a single entry (test=test).

I guess that the intention of this file, like for Portal 2.5, is to provide an out-of the box extension point for custom i18n keys.
for the record, in portal 2.x we used to override these bundle files at build time, effectively modifying these files in the portal.war.

With GateIn's portal extension mechanism, I expect (maybe erroneously) to be able to add custom locales simply by putting some custom_*.properties files inside my own portal war (ex: csdemo.war!WEB-INF/classes/locale/custom.properties ). And rely on the classloader resolution provided by the extension mecanism.

Strangely, it works well for all but english (en) locale. Actually, for english, the keys in my custom.properties are not resolved in my own gtmpl.
For example, in my homepage's gtmpl, an expression such as <%=_ctx.appRes("UIHomePagePortlet.cs-community")%> will result in displaying the "cs-community"  which means the key was not resolved.

I have several workarounds possible : 
1. copy-paste ALL custom*.* in my own portal war (ex: csdemo.war!WEB-INF/classes/locale/) then modify the bundles for the translations I have
2. define my own BaseResourceBundlePlugin for the ResourceBundleService component then xml conf change the "portal.resource.names" to add something like "locale.portal.csdemo" . Then provide csdemo.properties and csdemo_fr.properties
3. remove portal.war!WEB-INF/classes/locale/custom*.* and only provide the bundles for the locales I want  (ex: custom.properties)

1. is not pratically doable (I can't guess how many languages are supported)
2. is the current workaround. But then you could very well remove custom*.* 
3. is almost good except the need to modify portal.war in order to obtain the expected behaviour

I'm not sure if this could qualify as a but, but none of the possible solutions is satifying in terms of extensibility.

The quickfix for gatein would be simply to remove custom*.* from portal.war. By keeping the ResourceBundleService config as-is, it would make a very handy implicit extension point for customizations. 


  was:

custom_* resource bundles are provided inside portal.war and contain a single entry (test=test).

I guess that the intention of this file, like for Portal 2.5, is to provide an out-of the box extension point for custom i18n keys.
for the record, in portal 2.x we used to override these bundle files at build time, effectively modifying these files in the portal.war.

With GateIn's portal extension mechanism, I expect (maybe erroneously) to be able to add custom locales simply by putting some custom_*.properties files inside my own portal war (ex: csdemo.war!WEB-INF/classes/locale/custom.properties ). And rely on the classloader resolution provided by the extension mecanism.

Strangely, it works well for all but english (en)locale.
The keys of my custom.properties are not resolved in my own gtmpl.
For example, in my homepage's gtmpl, an expression such as <%=_ctx.appRes("UIHomePagePortlet.cs-community")%> will result in displaying the "cs-community"  which means the key was not resolved.

I have several workarounds possible : 
1. copy-paste ALL custom*.* in my own portal war (ex: csdemo.war!WEB-INF/classes/locale/) then modify the bundles for the translations I have
2. digg into the ResourceBundleService xml conf change the "portal.resource.names" to add something like "locale.portal.csdemo" for my own keys
3. remove portal.war!WEB-INF/classes/locale/custom*.* and only provide the bundles for the locales I want  (ex: custom.properties)

1. is not pratically doable (I can't guess how many languages are supported
2. is the current workaround. But then you could very well remove custom*.* 
3. is almost good except the need to modify portal.war in order to obtain the expected behaviour

I'm not sure if this could qualify as a but, but none of the possible solutions is satifying in terms of extensibility.

The quickfix for gatein would be simply to remove custom*.* from portal.war. By keeping the ResourceBundleService config as-is, it would make a very handy implicit extension point for customizations. 




> Remove custom_*.* resource bundles from portal.war
> --------------------------------------------------
>
>                 Key: GTNPORTAL-933
>                 URL: https://jira.jboss.org/jira/browse/GTNPORTAL-933
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.0.0-GA
>            Reporter: Patrice Lamarque
>            Priority: Minor
>
> custom_* resource bundles are provided inside portal.war and contain a single entry (test=test).
> I guess that the intention of this file, like for Portal 2.5, is to provide an out-of the box extension point for custom i18n keys.
> for the record, in portal 2.x we used to override these bundle files at build time, effectively modifying these files in the portal.war.
> With GateIn's portal extension mechanism, I expect (maybe erroneously) to be able to add custom locales simply by putting some custom_*.properties files inside my own portal war (ex: csdemo.war!WEB-INF/classes/locale/custom.properties ). And rely on the classloader resolution provided by the extension mecanism.
> Strangely, it works well for all but english (en) locale. Actually, for english, the keys in my custom.properties are not resolved in my own gtmpl.
> For example, in my homepage's gtmpl, an expression such as <%=_ctx.appRes("UIHomePagePortlet.cs-community")%> will result in displaying the "cs-community"  which means the key was not resolved.
> I have several workarounds possible : 
> 1. copy-paste ALL custom*.* in my own portal war (ex: csdemo.war!WEB-INF/classes/locale/) then modify the bundles for the translations I have
> 2. define my own BaseResourceBundlePlugin for the ResourceBundleService component then xml conf change the "portal.resource.names" to add something like "locale.portal.csdemo" . Then provide csdemo.properties and csdemo_fr.properties
> 3. remove portal.war!WEB-INF/classes/locale/custom*.* and only provide the bundles for the locales I want  (ex: custom.properties)
> 1. is not pratically doable (I can't guess how many languages are supported)
> 2. is the current workaround. But then you could very well remove custom*.* 
> 3. is almost good except the need to modify portal.war in order to obtain the expected behaviour
> I'm not sure if this could qualify as a but, but none of the possible solutions is satifying in terms of extensibility.
> The quickfix for gatein would be simply to remove custom*.* from portal.war. By keeping the ResourceBundleService config as-is, it would make a very handy implicit extension point for customizations. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira