[JBoss JIRA] Created: (GTNPORTAL-985) Many users can not add pages at once during Perf test
by Arthur Peltier (JIRA)
Many users can not add pages at once during Perf test
-----------------------------------------------------
Key: GTNPORTAL-985
URL: https://jira.jboss.org/jira/browse/GTNPORTAL-985
Project: GateIn Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.0.0-GA
Environment: IE7, FF3.5 - JBoss 5.1.0.GA- Java1.6.0-14
Reporter: Arthur Peltier
Steps:
- Create group and assign user to that group
- Create page by winzard
Scenarios:
- Run with 2 threads with the scripts with steps above by Jmeter
Result:
- 2 groups are created <-- it is ok
- Only 1 page is created <--- it is invalid.
The problem may be conflict of concurrence. Because when I run 1 user but with repeat actions( steps by steps), many pages are created successfully. However, when many users are run at once, only 1 page is created.
Expected :
- Able to add many pages at once with many v-users.
--
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
12 years, 4 months
[JBoss JIRA] Created: (GTNPORTAL-961) No limits on the MapResourceBundle recursive lookup
by Matt Wringe (JIRA)
No limits on the MapResourceBundle recursive lookup
---------------------------------------------------
Key: GTNPORTAL-961
URL: https://jira.jboss.org/jira/browse/GTNPORTAL-961
Project: GateIn Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Matt Wringe
The map resource bundle doesn't have any limits on the amount of recursion it will try and do when resolving a message.
For example, if we have a properties file with:
word.cancel=#{word.cancel}
Then we will end up in an infinite loop (eventual stackoverflow exception) when trying to resolve #{word.cancel}.
When it tries to resolve word.cancel, it will get back #{word.cancel} which it will try and resolve again, ...
We are going to need to have a check on the level of recursion allowed when resolving messages from the resource bundle.
--
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
12 years, 4 months
[JBoss JIRA] Created: (GTNPORTAL-933) Remove custom_*.* resource bundles from portal.war
by Patrice Lamarque (JIRA)
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
12 years, 4 months
[JBoss JIRA] Created: (GTNPORTAL-975) Date format bug in PublishDate during Node creation
by Arthur Peltier (JIRA)
Date format bug in PublishDate during Node creation
---------------------------------------------------
Key: GTNPORTAL-975
URL: https://jira.jboss.org/jira/browse/GTNPORTAL-975
Project: GateIn Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: ff, xp, tomcat, 1.6, n/a
Reporter: Arthur Peltier
Priority: Minor
Portal\Portal Navigation\Node\Create
*Login as root
*go to site link and edit Navigation
*Add node with "Publication date & time"
*fill date and save input in format "dd/mm/yy hh:mm:ss" is possible but after save it becomes "dd/mm/00yy hh:mm:ss". I should at least put ".../20yy hh:..." by default.
Result : "03/09/0011 14:27:55" I doubt it will ever be published
Expected : having put in "03/09/11 14:27:55" during creation I wanted "03/09/2011 14:27:55"
linked to test POR_14_01_026
--
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
12 years, 4 months