10:29 a.m.
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.
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.
--
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
10:41 a.m.
New subject: [JBoss JIRA] Updated: (GTNPORTAL-933) Remove custom_*.* resource bundles from portal.war
[
https://jira.jboss.org/jira/browse/GTNPORTAL-933?page=com.atlassian.jira....
]
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
10:56 a.m.
New subject: [JBoss JIRA] Updated: (GTNPORTAL-933) Remove custom_*.* resource bundles from portal.war
[
https://jira.jboss.org/jira/browse/GTNPORTAL-933?page=com.atlassian.jira....
]
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 csdemo_en.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 I'd like to avoid the duplicate custom.properties in
custom_en.properties
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. 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.
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 csdemo_en.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 I'd like to avoid the duplicate custom.properties
in custom_en.properties
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
4:45 a.m.
New subject: [JBoss JIRA] Updated: (GTNPORTAL-933) Remove custom_*.* resource bundles from portal.war
[
https://jira.jboss.org/browse/GTNPORTAL-933?page=com.atlassian.jira.plugi...
]
Minh Hoang TO updated GTNPORTAL-933:
------------------------------------
Original Estimate: 6 hours
Remaining Estimate: 6 hours
Labels: sprint_36 (was: )
Remove custom_*.* resource bundles from portal.war
--------------------------------------------------
Key: GTNPORTAL-933
URL: https://jira.jboss.org/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
Original Estimate: 6 hours
Remaining Estimate: 6 hours
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 csdemo_en.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 I'd like to avoid the duplicate custom.properties
in custom_en.properties
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/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:34 a.m.
New subject: [JBoss JIRA] Work started: (GTNPORTAL-933) Remove custom_*.* resource bundles from portal.war
[
https://jira.jboss.org/browse/GTNPORTAL-933?page=com.atlassian.jira.plugi...
]
Work on GTNPORTAL-933 started by kien nguyen.
Remove custom_*.* resource bundles from portal.war
--------------------------------------------------
Key: GTNPORTAL-933
URL: https://jira.jboss.org/browse/GTNPORTAL-933
Project: GateIn Portal
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 3.0.0-GA
Reporter: Patrice Lamarque
Assignee: kien nguyen
Priority: Minor
Original Estimate: 6 hours
Remaining Estimate: 6 hours
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 csdemo_en.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 I'd like to avoid the duplicate custom.properties
in custom_en.properties
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/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:34 a.m.
New subject: [JBoss JIRA] Assigned: (GTNPORTAL-933) Remove custom_*.* resource bundles from portal.war
[
https://jira.jboss.org/browse/GTNPORTAL-933?page=com.atlassian.jira.plugi...
]
kien nguyen reassigned GTNPORTAL-933:
-------------------------------------
Assignee: kien nguyen
Remove custom_*.* resource bundles from portal.war
--------------------------------------------------
Key: GTNPORTAL-933
URL: https://jira.jboss.org/browse/GTNPORTAL-933
Project: GateIn Portal
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 3.0.0-GA
Reporter: Patrice Lamarque
Assignee: kien nguyen
Priority: Minor
Original Estimate: 6 hours
Remaining Estimate: 6 hours
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 csdemo_en.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 I'd like to avoid the duplicate custom.properties
in custom_en.properties
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/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:17 p.m.
New subject: [JBoss JIRA] Work stopped: (GTNPORTAL-933) Remove custom_*.* resource bundles from portal.war
[
https://jira.jboss.org/browse/GTNPORTAL-933?page=com.atlassian.jira.plugi...
]
Work on GTNPORTAL-933 stopped by kien nguyen.
Remove custom_*.* resource bundles from portal.war
--------------------------------------------------
Key: GTNPORTAL-933
URL: https://jira.jboss.org/browse/GTNPORTAL-933
Project: GateIn Portal
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 3.0.0-GA
Reporter: Patrice Lamarque
Assignee: kien nguyen
Priority: Minor
Attachments: 2010-08-04-GTNPORTAL-933.patch
Original Estimate: 6 hours
Remaining Estimate: 6 hours
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 csdemo_en.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 I'd like to avoid the duplicate custom.properties
in custom_en.properties
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/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:17 p.m.
New subject: [JBoss JIRA] Updated: (GTNPORTAL-933) Remove custom_*.* resource bundles from portal.war
[
https://jira.jboss.org/browse/GTNPORTAL-933?page=com.atlassian.jira.plugi...
]
kien nguyen updated GTNPORTAL-933:
----------------------------------
Attachment: 2010-08-04-GTNPORTAL-933.patch
I attached patch for removing custom*.* from portal.war
Remove custom_*.* resource bundles from portal.war
--------------------------------------------------
Key: GTNPORTAL-933
URL: https://jira.jboss.org/browse/GTNPORTAL-933
Project: GateIn Portal
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 3.0.0-GA
Reporter: Patrice Lamarque
Assignee: kien nguyen
Priority: Minor
Attachments: 2010-08-04-GTNPORTAL-933.patch
Original Estimate: 6 hours
Remaining Estimate: 6 hours
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 csdemo_en.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 I'd like to avoid the duplicate custom.properties
in custom_en.properties
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/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:07 a.m.
New subject: [JBoss JIRA] Updated: (GTNPORTAL-933) Remove custom_*.* resource bundles from portal.war
[
https://jira.jboss.org/browse/GTNPORTAL-933?page=com.atlassian.jira.plugi...
]
Minh Hoang TO updated GTNPORTAL-933:
------------------------------------
Labels: sprint_36 sprint_37 (was: sprint_36)
Remove custom_*.* resource bundles from portal.war
--------------------------------------------------
Key: GTNPORTAL-933
URL: https://jira.jboss.org/browse/GTNPORTAL-933
Project: GateIn Portal
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 3.0.0-GA
Reporter: Patrice Lamarque
Assignee: kien nguyen
Priority: Minor
Attachments: 2010-08-04-GTNPORTAL-933.patch
Original Estimate: 6 hours
Remaining Estimate: 6 hours
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 csdemo_en.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 I'd like to avoid the duplicate custom.properties
in custom_en.properties
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/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:55 p.m.
New subject: [JBoss JIRA] (GTNPORTAL-933) Remove custom_*.* resource bundles from portal.war
[
https://issues.jboss.org/browse/GTNPORTAL-933?page=com.atlassian.jira.plu...
]
Boleslaw Dawidowicz closed GTNPORTAL-933.
-----------------------------------------
Resolution: Out of Date
Should be verified in gatein master and reopened if still valid
Remove custom_*.* resource bundles from portal.war
--------------------------------------------------
Key: GTNPORTAL-933
URL: https://issues.jboss.org/browse/GTNPORTAL-933
Project: GateIn Portal
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 3.0.0-GA
Reporter: Patrice Lamarque
Assignee: kien nguyen
Priority: Minor
Labels: sprint_36, sprint_37
Attachments: 2010-08-04-GTNPORTAL-933.patch
Original Estimate: 6 hours
Remaining Estimate: 6 hours
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 csdemo_en.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 I'd like to avoid the duplicate custom.properties
in custom_en.properties
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, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4320
days inactive
5178
days old
9 comments
4 participants
participants (4)
-
Boleslaw Dawidowicz (JIRA) -
kien nguyen (JIRA)
-
Minh Hoang TO (JIRA)
-
Patrice Lamarque (JIRA)