[jira] [Commented] (TRINIDAD-2492) Layout Tables to support Accessibility and OAG2.0 guidelines
[ https://issues.apache.org/jira/browse/TRINIDAD-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14055334#comment-14055334 ] Jeanne Waldman commented on TRINIDAD-2492: -- Completed: At revision: 1608901 Layout Tables to support Accessibility and OAG2.0 guidelines Key: TRINIDAD-2492 URL: https://issues.apache.org/jira/browse/TRINIDAD-2492 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Bino Kohli Attachments: OAG2.0-trinidad-tablelayout Original Estimate: 24h Remaining Estimate: 24h The renderlayoutTableAttributes method adds the role=presentation in screenreader mode . we need to always include role=presenattion to make it OAG2.0 compatible . solution: update the method (org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.OutputUtils.renderLayoutTableAttributes) to also include the role=presentation when in regular rich mode -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TRINIDAD-2492) Layout Tables to support Accessibility and OAG2.0 guidelines
[ https://issues.apache.org/jira/browse/TRINIDAD-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman updated TRINIDAD-2492: - Resolution: Fixed Fix Version/s: 2.1.1-core Assignee: Jeanne Waldman Status: Resolved (was: Patch Available) Layout Tables to support Accessibility and OAG2.0 guidelines Key: TRINIDAD-2492 URL: https://issues.apache.org/jira/browse/TRINIDAD-2492 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Bino Kohli Assignee: Jeanne Waldman Fix For: 2.1.1-core Attachments: OAG2.0-trinidad-tablelayout Original Estimate: 24h Remaining Estimate: 24h The renderlayoutTableAttributes method adds the role=presentation in screenreader mode . we need to always include role=presenattion to make it OAG2.0 compatible . solution: update the method (org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.OutputUtils.renderLayoutTableAttributes) to also include the role=presentation when in regular rich mode -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (TRINIDAD-2436) We should update Table's selection state during invoke application phase
[ https://issues.apache.org/jira/browse/TRINIDAD-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman reopened TRINIDAD-2436: -- rolled back the changes due to regressions. We should update Table's selection state during invoke application phase Key: TRINIDAD-2436 URL: https://issues.apache.org/jira/browse/TRINIDAD-2436 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Environment: generic Reporter: Jing Wu Assignee: Jeanne Waldman Priority: Minor Fix For: 2.1.1-core Attachments: JIRA-2436-rollback.patch, updateselectionbroadcastTrinidad.patch Currently, when selection changes is sent to server, component's state is changed at decoding, but if there's any validation error, the component's state is invalid. We should update the component's selection state when we distribute the selectionEvent, not when we decode the request. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TRINIDAD-2436) We should update Table's selection state during invoke application phase
[ https://issues.apache.org/jira/browse/TRINIDAD-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14051727#comment-14051727 ] Jeanne Waldman commented on TRINIDAD-2436: -- ROLLBACK CHECKIN: Sending content: C:\Trinidad\Trunk3\trinidad-api\src\main\java-templates\org\apache\myfaces\trinidad\component\UIXTableTemplate.java Sending content: C:\Trinidad\Trunk3\trinidad-api\src\main\java\org\apache\myfaces\trinidad\component\TableUtils.java Sending content: C:\Trinidad\Trunk3\trinidad-api\src\main\java-templates\org\apache\myfaces\trinidad\component\UIXTreeTemplate.java Completed: At revision: 1607699 We should update Table's selection state during invoke application phase Key: TRINIDAD-2436 URL: https://issues.apache.org/jira/browse/TRINIDAD-2436 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Environment: generic Reporter: Jing Wu Assignee: Jeanne Waldman Priority: Minor Fix For: 2.1.1-core Attachments: JIRA-2436-rollback.patch, updateselectionbroadcastTrinidad.patch Currently, when selection changes is sent to server, component's state is changed at decoding, but if there's any validation error, the component's state is invalid. We should update the component's selection state when we distribute the selectionEvent, not when we decode the request. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TRINIDAD-2490) skin additions are not loaded for simple, minimal and casablanca skins
[ https://issues.apache.org/jira/browse/TRINIDAD-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14051787#comment-14051787 ] Jeanne Waldman commented on TRINIDAD-2490: -- Sending content: C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\skin\provider\SkinProviderRegistry.java Sending content: C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\skin\provider\BaseSkinProvider.java Sending content: C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\skin\SkinUtils.java Sending content: C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\config\GlobalConfiguratorImpl.java Sending content: C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\skin\SkinImpl.java Sending content: C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\skin\provider\TrinidadSkinProvider.java Sending content: C:\Trinidad\Trunk3\trinidad-api\src\main\java\org\apache\myfaces\trinidad\skin\SkinAddition.java Sending content: C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\skin\provider\ExternalSkinProvider.java Completed: At revision: 1607709 skin additions are not loaded for simple, minimal and casablanca skins -- Key: TRINIDAD-2490 URL: https://issues.apache.org/jira/browse/TRINIDAD-2490 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.1.0-core Reporter: Anand V Nath Fix For: 2.1.1-core Attachments: jira-2490.patch Skin additions present in trinidad-skins.xml are not loaded if the skin used is one of the Trinidad provided skins, such as simple, casablanca or minimal. Applications may add skin additions to these using trinidad-skins.xml and they should get loaded. For example: An application added a skin addition to simple.desktop using its trinidad-skins.xml and used simple skin family in its trinidad-config.xml. In this case, the skin addition that application added does not get picked up. This happens only for the default skins provided by trinidad out of the box. This bug appears after SkinProvider SPI and SkinFactory deprecation. Earlier SkinFactory used to eager load and process all skins at start-up. With SkinProvider we defer the skin load until the time user requests it. Default trinidad skins are handled by TriniadBaseSkinProvider and those defined in trinidad-skins.xml are handled by TrindiadSkinProvider. It is the responsibility of SkinProviderRegistry that coordinates between all SkinProviders to ensure that the skin additions added in TrindiadSkinProvider are applied to all skins. So I added this logic into SkinProviderRegistry. I also added more comments and javadoc for SkinProvider where I found it missing and did some rearrangements for coding standards compliance. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TRINIDAD-2489) Incorrect filename displayed in Chrome while using FILEDOWNLOADACTIONLISTENER
[
https://issues.apache.org/jira/browse/TRINIDAD-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14050377#comment-14050377
]
Jeanne Waldman commented on TRINIDAD-2489:
--
Completed: At revision: 1607424
Incorrect filename displayed in Chrome while using FILEDOWNLOADACTIONLISTENER
-
Key: TRINIDAD-2489
URL: https://issues.apache.org/jira/browse/TRINIDAD-2489
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Reporter: Naizam Olakara
Assignee: Jeanne Waldman
Priority: Minor
Fix For: 2.1.1-core
Attachments: trunk.patch
When using the fileDownloadActionListener, if the filename has a comma (,)
chrome will show the comma as %2C. Firefox and IE work fine.
Create a page with filedownload action listener like below
tr:commandLink immediate=true text=Command Link
tr:fileDownloadActionListener contentType=text/plain
filename=526,1.zip method=#{fileDownload.sendHelloFile}/
/tr:commandLink
Sample file name is, 526,1.zip
In firefox and IE, the filename will be displayed as 526,1.zip. In chrome
it will be 526%2C1.zip.
Fix:-
src\main\java\org\apache\myfaces\trinidadinternal\taglib\listener\FileDownloadActionListener.java
Here, the filename is encoded differently based on browsers. Currently IE and
all webkit browsers has UTF-8 URL encoding and others (gecko) have UTF-8
quoted-printable encoding. Chrome also needs UTF-8 quoted-printable encoding.
A check is added to handle this case.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TRINIDAD-2489) Incorrect filename displayed in Chrome while using FILEDOWNLOADACTIONLISTENER
[
https://issues.apache.org/jira/browse/TRINIDAD-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeanne Waldman updated TRINIDAD-2489:
-
Resolution: Fixed
Fix Version/s: 2.1.1-core
Assignee: Jeanne Waldman
Status: Resolved (was: Patch Available)
fixed on trunk
Incorrect filename displayed in Chrome while using FILEDOWNLOADACTIONLISTENER
-
Key: TRINIDAD-2489
URL: https://issues.apache.org/jira/browse/TRINIDAD-2489
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Reporter: Naizam Olakara
Assignee: Jeanne Waldman
Priority: Minor
Fix For: 2.1.1-core
Attachments: trunk.patch
When using the fileDownloadActionListener, if the filename has a comma (,)
chrome will show the comma as %2C. Firefox and IE work fine.
Create a page with filedownload action listener like below
tr:commandLink immediate=true text=Command Link
tr:fileDownloadActionListener contentType=text/plain
filename=526,1.zip method=#{fileDownload.sendHelloFile}/
/tr:commandLink
Sample file name is, 526,1.zip
In firefox and IE, the filename will be displayed as 526,1.zip. In chrome
it will be 526%2C1.zip.
Fix:-
src\main\java\org\apache\myfaces\trinidadinternal\taglib\listener\FileDownloadActionListener.java
Here, the filename is encoded differently based on browsers. Currently IE and
all webkit browsers has UTF-8 URL encoding and others (gecko) have UTF-8
quoted-printable encoding. Chrome also needs UTF-8 quoted-printable encoding.
A check is added to handle this case.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TRINIDAD-2473) Improve diagnostic support for resource bundle feature in skinning framework
[
https://issues.apache.org/jira/browse/TRINIDAD-2473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeanne Waldman updated TRINIDAD-2473:
-
Resolution: Fixed
Assignee: Jeanne Waldman
Status: Resolved (was: Patch Available)
Completed: At revision: 1600529
on trunk
Improve diagnostic support for resource bundle feature in skinning framework
Key: TRINIDAD-2473
URL: https://issues.apache.org/jira/browse/TRINIDAD-2473
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Prakash Udupa
Assignee: Jeanne Waldman
Attachments: TRINIDAD-2473-take-2.trunk.patch,
TRINIDAD-2473-take-3.trunk.patch, TRINIDAD-2473.trunk.patch
Original Estimate: 24h
Remaining Estimate: 24h
We had difficulty diagnosing a skinning issue where the server logs reported
some translated keys not being able to be resolved to its value in the
resource bundle attached to the skins.
There are messages like these two in the logs:
1.
17.02.2014 21:22 Uhr MEZ Error
org.apache.myfaces.trinidad.context.RenderingContext BEA-00
Ressourcenschlüssel af_document.LABEL_SPLASH_SCREEN konnte nicht aus Skin
gsr40518e9c_5b59_459a_8d71_85d8a9d30676.desktop abgerufen werden
2.
17.02.2014 21:23 Uhr MEZ Error HTTP BEA-101020
[ServletContext@797966157[app:de_arbeitsagentur_portal module:apps
path:/apps spec-version:2.5 version:1.0.0.5.159]] Servlet failed with
Exception
java.util.MissingResourceException: Can't find resource for bundle
at
org.apache.myfaces.trinidadinternal.skin.SkinImpl.getTranslatedValue(SkinImpl.
java:183)
===
These are not as useful because they do not give the details of skin or the
bundle class that is expected to resolve it, or how in the skin hierarchy
this was resolved (or lack of). Relevant code is here:
===
In RenderingContext.getTranslatedString():
try
{
return getSkin().getTranslatedString(getLocaleContext(), key);
}
catch (MissingResourceException mre)
{
// Instead of halting execution, return ???key???,
// just like JSF and JSTL will do, and log a severe error
_LOG.severe(CANNOT_GET_RESOURCE_KEY, new String[]{key,
getSkin().getId()});
return ??? + key + ???;
}
This would not tell if the bundle was read properly in the first place.
The issue is more evident in this code in SkinImpl.getTranslatedValue():
if (translatedValue == null)
{
throw new MissingResourceException(Can't find resource for bundle,
getBundleName(),
key);
}
Although the bundle name and key is passed to the exception, it does not get
included in the message in the log, this information should be included in
the first parameter.
This issue is to track the needed improvement in logging here to improve
debug-ability. Will provide a patch soon.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TRINIDAD-2436) We should update Table's selection state during invoke application phase
[ https://issues.apache.org/jira/browse/TRINIDAD-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman resolved TRINIDAD-2436. -- Resolution: Fixed Assignee: Jeanne Waldman committed to trunk We should update Table's selection state during invoke application phase Key: TRINIDAD-2436 URL: https://issues.apache.org/jira/browse/TRINIDAD-2436 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Environment: generic Reporter: Jing Wu Assignee: Jeanne Waldman Priority: Minor Fix For: 2.1.1-core Attachments: updateselectionbroadcastTrinidad.patch Currently, when selection changes is sent to server, component's state is changed at decoding, but if there's any validation error, the component's state is invalid. We should update the component's selection state when we distribute the selectionEvent, not when we decode the request. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TRINIDAD-2436) We should update Table's selection state during invoke application phase
[ https://issues.apache.org/jira/browse/TRINIDAD-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13963319#comment-13963319 ] Jeanne Waldman commented on TRINIDAD-2436: -- Sending content: C:\Trinidad\Trunk3\trinidad-api\src\main\java-templates\org\apache\myfaces\trinidad\component\UIXTableTemplate.java Sending content: C:\Trinidad\Trunk3\trinidad-api\src\main\java\org\apache\myfaces\trinidad\component\TableUtils.java Sending content: C:\Trinidad\Trunk3\trinidad-api\src\main\java-templates\org\apache\myfaces\trinidad\component\UIXTreeTemplate.java Completed: At revision: 1585818 We should update Table's selection state during invoke application phase Key: TRINIDAD-2436 URL: https://issues.apache.org/jira/browse/TRINIDAD-2436 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Environment: generic Reporter: Jing Wu Priority: Minor Fix For: 2.1.1-core Attachments: updateselectionbroadcastTrinidad.patch Currently, when selection changes is sent to server, component's state is changed at decoding, but if there's any validation error, the component's state is invalid. We should update the component's selection state when we distribute the selectionEvent, not when we decode the request. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TRINIDAD-2459) Addition of ValueUpdatedEvent + ValueUpdatedListener
[
https://issues.apache.org/jira/browse/TRINIDAD-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948200#comment-13948200
]
Jeanne Waldman commented on TRINIDAD-2459:
--
Completed: At revision: 1581963
Addition of ValueUpdatedEvent + ValueUpdatedListener
Key: TRINIDAD-2459
URL: https://issues.apache.org/jira/browse/TRINIDAD-2459
Project: MyFaces Trinidad
Issue Type: New Feature
Components: Components
Affects Versions: 2.1.0-core
Environment: N/A
Reporter: Ji Kim
Fix For: 2.1.1-core
Attachments: valueUpdatedEvent.patch
Original Estimate: 24h
Remaining Estimate: 24h
This change is to add a new ValueUpdatedEvent + ValueUpdatedListener where
ValueUpdatedEvent will be queued within UIXEditableValueTemplate.updateModel
method.
This is to allow components and etcetera to listen to this event by adding a
listener in the new UIXEditableValueTemplate.addValueUpdatedListener API.
The pro of adding this event + listener is that various components can then
listen when the value has been updated in the model.
This is beneficial in
1) Clearing up any data that would have been persisted for some reason [i.e.
if the app wished to keep a temporary value of a component using some kind of
polling from client to server to not lose any dirty data {i.e. how confluence
wiki allows users to preserves the old states}].
2) To avoid sending a certain asynchronous dirty data from the client to the
server
Thanks!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TRINIDAD-2459) Addition of ValueUpdatedEvent + ValueUpdatedListener
[
https://issues.apache.org/jira/browse/TRINIDAD-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeanne Waldman updated TRINIDAD-2459:
-
Resolution: Fixed
Fix Version/s: 2.1.1-core
Assignee: Jeanne Waldman
Status: Resolved (was: Patch Available)
committed for Ji Kim on trunk.
Addition of ValueUpdatedEvent + ValueUpdatedListener
Key: TRINIDAD-2459
URL: https://issues.apache.org/jira/browse/TRINIDAD-2459
Project: MyFaces Trinidad
Issue Type: New Feature
Components: Components
Affects Versions: 2.1.0-core
Environment: N/A
Reporter: Ji Kim
Assignee: Jeanne Waldman
Fix For: 2.1.1-core
Attachments: valueUpdatedEvent.patch
Original Estimate: 24h
Remaining Estimate: 24h
This change is to add a new ValueUpdatedEvent + ValueUpdatedListener where
ValueUpdatedEvent will be queued within UIXEditableValueTemplate.updateModel
method.
This is to allow components and etcetera to listen to this event by adding a
listener in the new UIXEditableValueTemplate.addValueUpdatedListener API.
The pro of adding this event + listener is that various components can then
listen when the value has been updated in the model.
This is beneficial in
1) Clearing up any data that would have been persisted for some reason [i.e.
if the app wished to keep a temporary value of a component using some kind of
polling from client to server to not lose any dirty data {i.e. how confluence
wiki allows users to preserves the old states}].
2) To avoid sending a certain asynchronous dirty data from the client to the
server
Thanks!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TRINIDAD-2449) warning logged for bad icons is internal - not required for customers
[ https://issues.apache.org/jira/browse/TRINIDAD-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893831#comment-13893831 ] Jeanne Waldman commented on TRINIDAD-2449: -- Completed: At revision: 1565446 warning logged for bad icons is internal - not required for customers - Key: TRINIDAD-2449 URL: https://issues.apache.org/jira/browse/TRINIDAD-2449 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.1.0-core Reporter: Anand V Nath Priority: Trivial Fix For: 2.1.1-core Attachments: jira-2449.patch Skinning framework has a convention for defining IconStyles. Styles ending with '-icon' (or contains '-icon:' for handling psuedo classes) or alias ending with 'Icon:alias' are considered as IconStyles. The basic requirement for an IconStyle is that it should have a 'content'. However skin framework does not enforce this. For backward compatibility reasons and because the styles were already public, we allow users to use styles defined in the IconStyle format as normal styles. But we log a warning for those IconStyles that do not have a 'content': WARNING: The skin selector af|dialog::close-icon is not a Skin Icon Object since it does not have a content attribute. If you created this selector, please rename it to end with style instead of icon so that the Skinning Framework will treat it as a style, not an icon. The warning for bad IconStyles is mainly for internal styles and need not be highlighted as a warning to external customers. We can log this as an INFO instead of WARNING. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TRINIDAD-2449) warning logged for bad icons is internal - not required for customers
[ https://issues.apache.org/jira/browse/TRINIDAD-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman updated TRINIDAD-2449: - Resolution: Fixed Assignee: Jeanne Waldman Status: Resolved (was: Patch Available) applied patch to trunk warning logged for bad icons is internal - not required for customers - Key: TRINIDAD-2449 URL: https://issues.apache.org/jira/browse/TRINIDAD-2449 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.1.0-core Reporter: Anand V Nath Assignee: Jeanne Waldman Priority: Trivial Fix For: 2.1.1-core Attachments: jira-2449.patch Skinning framework has a convention for defining IconStyles. Styles ending with '-icon' (or contains '-icon:' for handling psuedo classes) or alias ending with 'Icon:alias' are considered as IconStyles. The basic requirement for an IconStyle is that it should have a 'content'. However skin framework does not enforce this. For backward compatibility reasons and because the styles were already public, we allow users to use styles defined in the IconStyle format as normal styles. But we log a warning for those IconStyles that do not have a 'content': WARNING: The skin selector af|dialog::close-icon is not a Skin Icon Object since it does not have a content attribute. If you created this selector, please rename it to end with style instead of icon so that the Skinning Framework will treat it as a style, not an icon. The warning for bad IconStyles is mainly for internal styles and need not be highlighted as a warning to external customers. We can log this as an INFO instead of WARNING. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [Commit Request] (TRINIDAD-2448) Optimize ChangeManager.createDocumentChange() implementation
I'll do it. On 1/28/2014 11:33 AM PT, Prakash Udupa wrote: Hi, I uploaded TRINIDAD-2448_over_trunk.patch, this is the patch file over Trinidad trunk for this issue. One of the developers with write permission, please commit this patch. https://issues.apache.org/jira/browse/TRINIDAD-2448 Thanks, Prakash Original Message Subject:[jira] [Updated] (TRINIDAD-2448) Optimize ChangeManager.createDocumentChange() implementation Date: Fri, 24 Jan 2014 01:07:38 + (UTC) From: Prakash Udupa (JIRA) dev@myfaces.apache.org Reply-To: MyFaces Development dev@myfaces.apache.org To: dev@myfaces.apache.org [https://issues.apache.org/jira/browse/TRINIDAD-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prakash Udupa updated TRINIDAD-2448: Status: Patch Available (was: Open) Optimize ChangeManager.createDocumentChange() implementation Key: TRINIDAD-2448 URL:https://issues.apache.org/jira/browse/TRINIDAD-2448 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.1.0-core Reporter: Prakash Udupa Attachments: TRINIDAD-2448_over_trunk.patch Original Estimate: 1h Remaining Estimate: 1h Currently the implementation of org.apache.myfaces.trinidad.change ChangeManager.createDocumentChange( ComponentChange change) does not account for fact that the supplied ComponentChange implementation can also be implementing DocumentChange. Improvement is to do this check first, type cast the supplied component to DocumentChange and return. There are several ComponentChange implementations in Trinidad that actually also implement DocumentChange, so this is common usecase. Currently clients need to do this check outside of this call, which can be moved in here. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TRINIDAD-2448) Optimize ChangeManager.createDocumentChange() implementation
[ https://issues.apache.org/jira/browse/TRINIDAD-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13884791#comment-13884791 ] Jeanne Waldman commented on TRINIDAD-2448: -- Sending content: C:\Trinidad\trinidad-api\src\main\java\org\apache\myfaces\trinidad\change\ChangeManager.java Sending content: C:\Trinidad\trinidad-api\src\main\java\org\apache\myfaces\trinidad\change\BaseChangeManager.java Completed: At revision: 1562288 Optimize ChangeManager.createDocumentChange() implementation Key: TRINIDAD-2448 URL: https://issues.apache.org/jira/browse/TRINIDAD-2448 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.1.0-core Reporter: Prakash Udupa Fix For: 2.1.1-core Attachments: TRINIDAD-2448_over_trunk.patch Original Estimate: 1h Remaining Estimate: 1h Currently the implementation of org.apache.myfaces.trinidad.change ChangeManager.createDocumentChange( ComponentChange change) does not account for fact that the supplied ComponentChange implementation can also be implementing DocumentChange. Improvement is to do this check first, type cast the supplied component to DocumentChange and return. There are several ComponentChange implementations in Trinidad that actually also implement DocumentChange, so this is common usecase. Currently clients need to do this check outside of this call, which can be moved in here. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TRINIDAD-2448) Optimize ChangeManager.createDocumentChange() implementation
[ https://issues.apache.org/jira/browse/TRINIDAD-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman updated TRINIDAD-2448: - Resolution: Fixed Fix Version/s: 2.1.1-core Assignee: Jeanne Waldman Status: Resolved (was: Patch Available) patched trunk Optimize ChangeManager.createDocumentChange() implementation Key: TRINIDAD-2448 URL: https://issues.apache.org/jira/browse/TRINIDAD-2448 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.1.0-core Reporter: Prakash Udupa Assignee: Jeanne Waldman Fix For: 2.1.1-core Attachments: TRINIDAD-2448_over_trunk.patch Original Estimate: 1h Remaining Estimate: 1h Currently the implementation of org.apache.myfaces.trinidad.change ChangeManager.createDocumentChange( ComponentChange change) does not account for fact that the supplied ComponentChange implementation can also be implementing DocumentChange. Improvement is to do this check first, type cast the supplied component to DocumentChange and return. There are several ComponentChange implementations in Trinidad that actually also implement DocumentChange, so this is common usecase. Currently clients need to do this check outside of this call, which can be moved in here. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [Commit Request] (TRINIDAD-2448) Optimize ChangeManager.createDocumentChange() implementation
done On 1/28/2014 11:33 AM PT, Prakash Udupa wrote: Hi, I uploaded TRINIDAD-2448_over_trunk.patch, this is the patch file over Trinidad trunk for this issue. One of the developers with write permission, please commit this patch. https://issues.apache.org/jira/browse/TRINIDAD-2448 Thanks, Prakash Original Message Subject:[jira] [Updated] (TRINIDAD-2448) Optimize ChangeManager.createDocumentChange() implementation Date: Fri, 24 Jan 2014 01:07:38 + (UTC) From: Prakash Udupa (JIRA) dev@myfaces.apache.org Reply-To: MyFaces Development dev@myfaces.apache.org To: dev@myfaces.apache.org [https://issues.apache.org/jira/browse/TRINIDAD-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prakash Udupa updated TRINIDAD-2448: Status: Patch Available (was: Open) Optimize ChangeManager.createDocumentChange() implementation Key: TRINIDAD-2448 URL:https://issues.apache.org/jira/browse/TRINIDAD-2448 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.1.0-core Reporter: Prakash Udupa Attachments: TRINIDAD-2448_over_trunk.patch Original Estimate: 1h Remaining Estimate: 1h Currently the implementation of org.apache.myfaces.trinidad.change ChangeManager.createDocumentChange( ComponentChange change) does not account for fact that the supplied ComponentChange implementation can also be implementing DocumentChange. Improvement is to do this check first, type cast the supplied component to DocumentChange and return. There are several ComponentChange implementations in Trinidad that actually also implement DocumentChange, so this is common usecase. Currently clients need to do this check outside of this call, which can be moved in here. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TRINIDAD-2445) Prevent exceptions from propagating out of the ServletFilter
[ https://issues.apache.org/jira/browse/TRINIDAD-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman updated TRINIDAD-2445: - Resolution: Fixed Fix Version/s: 2.1.1-core Assignee: Jeanne Waldman Status: Resolved (was: Patch Available) committed t o Trunk Prevent exceptions from propagating out of the ServletFilter Key: TRINIDAD-2445 URL: https://issues.apache.org/jira/browse/TRINIDAD-2445 Project: MyFaces Trinidad Issue Type: Bug Components: Archetype Affects Versions: 2.1.1-core Reporter: Arjun Vade Assignee: Jeanne Waldman Fix For: 2.1.1-core Attachments: 17191718.patch Any exceptions from the Trinidad code that runs before JSF lifecycle that propagates to application server layer may result in the end user not seeing a meaningful error message in UI. Solution: Trinidad code that runs before the JSF lifecycle shouldn't allow exceptions to propagate out of the ServletFilter. The fix is simply to add code to our various ServletFilters to trap the errors at that point before the errors propagate out. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TRINIDAD-2445) Prevent exceptions from propagating out of the ServletFilter
[ https://issues.apache.org/jira/browse/TRINIDAD-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13880990#comment-13880990 ] Jeanne Waldman commented on TRINIDAD-2445: -- Sending content: C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\webapp\TrinidadFilterImpl.java Sending content: C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\config\xmlHttp\XmlHttpConfigurator.java Sending content: C:\Trinidad\Trunk3\trinidad-impl\src\main\xrts\org\apache\myfaces\trinidadinternal\resource\LoggerBundle.xrts Completed: At revision: 1561022 Prevent exceptions from propagating out of the ServletFilter Key: TRINIDAD-2445 URL: https://issues.apache.org/jira/browse/TRINIDAD-2445 Project: MyFaces Trinidad Issue Type: Bug Components: Archetype Affects Versions: 2.1.1-core Reporter: Arjun Vade Assignee: Jeanne Waldman Fix For: 2.1.1-core Attachments: 17191718.patch Any exceptions from the Trinidad code that runs before JSF lifecycle that propagates to application server layer may result in the end user not seeing a meaningful error message in UI. Solution: Trinidad code that runs before the JSF lifecycle shouldn't allow exceptions to propagate out of the ServletFilter. The fix is simply to add code to our various ServletFilters to trap the errors at that point before the errors propagate out. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TRINIDAD-2444) Need pass through for newly supported placeholder pseudo-element / classes
[ https://issues.apache.org/jira/browse/TRINIDAD-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13880424#comment-13880424 ] Jeanne Waldman commented on TRINIDAD-2444: -- Sending content: C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\style\util\CSSGenerationUtils.java Completed: At revision: 1560827 Need pass through for newly supported placeholder pseudo-element / classes --- Key: TRINIDAD-2444 URL: https://issues.apache.org/jira/browse/TRINIDAD-2444 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.1.0-core Reporter: Prakash Udupa Fix For: 2.1.1-core Attachments: TRINIDAD-2444_Patch_Over_Trunk.patch Original Estimate: 3h Remaining Estimate: 3h TRINIDAD-2170 provided pass through support for implicit pseudo-classes / elements in general, and thereby allowed supporting placeholder text styling. There has been since then few changes in how browsers support this styling: 1. FF changed this from pseudo-class to pseudo-elements https://developer.mozilla.org/en-US/docs/Web/CSS/::-moz-placeholder https://bugzilla.mozilla.org/show_bug.cgi?id=737786 2. IE started supporting http://msdn.microsoft.com/en-us/library/ie/hh772745(v=vs.85).aspx We need to adapt to these changes now. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TRINIDAD-2444) Need pass through for newly supported placeholder pseudo-element / classes
[ https://issues.apache.org/jira/browse/TRINIDAD-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman updated TRINIDAD-2444: - Resolution: Fixed Fix Version/s: 2.1.1-core Assignee: Jeanne Waldman Status: Resolved (was: Patch Available) Need pass through for newly supported placeholder pseudo-element / classes --- Key: TRINIDAD-2444 URL: https://issues.apache.org/jira/browse/TRINIDAD-2444 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.1.0-core Reporter: Prakash Udupa Assignee: Jeanne Waldman Fix For: 2.1.1-core Attachments: TRINIDAD-2444_Patch_Over_Trunk.patch Original Estimate: 3h Remaining Estimate: 3h TRINIDAD-2170 provided pass through support for implicit pseudo-classes / elements in general, and thereby allowed supporting placeholder text styling. There has been since then few changes in how browsers support this styling: 1. FF changed this from pseudo-class to pseudo-elements https://developer.mozilla.org/en-US/docs/Web/CSS/::-moz-placeholder https://bugzilla.mozilla.org/show_bug.cgi?id=737786 2. IE started supporting http://msdn.microsoft.com/en-us/library/ie/hh772745(v=vs.85).aspx We need to adapt to these changes now. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TRINIDAD-2433) unnecessary use of FacesContext in SkinProvider API
[
https://issues.apache.org/jira/browse/TRINIDAD-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838004#comment-13838004
]
Jeanne Waldman commented on TRINIDAD-2433:
--
Sending content:
C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\skin\provider\ExternalSkinProvider.java
Sending content:
C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\skin\SkinFactoryImpl.java
Sending content:
C:\Trinidad\Trunk3\trinidad-api\src\main\java\org\apache\myfaces\trinidad\skin\SkinMetadata.java
Sending content:
C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\skin\provider\TrinidadBaseSkinProvider.java
Sending content:
C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\skin\SkinUtils.java
Sending content:
C:\Trinidad\Trunk3\trinidad-api\src\main\java\org\apache\myfaces\trinidad\skin\SkinVersion.java
Sending content:
C:\Trinidad\Trunk3\trinidad-api\src\main\java\org\apache\myfaces\trinidad\skin\CustomMetadata.java
Sending content:
C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\skin\provider\TrinidadSkinProvider.java
Sending content:
C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\skin\pregen\SkinPregenerationService.java
Sending content:
C:\Trinidad\Trunk3\trinidad-api\src\main\java\org\apache\myfaces\trinidad\skin\SkinProvider.java
Sending content:
C:\Trinidad\Trunk3\trinidad-impl\src\test\java\org\apache\myfaces\trinidadinternal\renderkit\RenderKitTestCase.java
Sending content:
C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\skin\provider\SkinProviderRegistry.java
Sending content:
C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\resource\TranslationsResourceLoader.java
Sending content:
C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\skin\provider\BaseSkinProvider.java
Sending content:
C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\renderkit\core\CoreRenderingContext.java
Sending content:
C:\Trinidad\Trunk3\trinidad-api\src\main\java\org\apache\myfaces\trinidad\skin\SkinFactory.java
Completed: At revision: 1547514
unnecessary use of FacesContext in SkinProvider API
---
Key: TRINIDAD-2433
URL: https://issues.apache.org/jira/browse/TRINIDAD-2433
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Anand V Nath
Priority: Minor
Fix For: 2.1.1-core
Attachments: jira-2433-new.patch, jira-2433.patch
SkinProvider API uses FacesContext in its methods. All that is done inside
the API is to extract the ExternalContext. So it is sufficient to pass
ExternalContext to the API. Though this is a public API change, the
SkinProvider API is introduced recently and not widely used. This gives us a
chance to correct the API now.
Proposed change:
- public CollectionSkinMetadata getSkinMetadata(FacesContext context)
+ public CollectionSkinMetadata getSkinMetadata(ExternalContext context)
{
return Collections.emptyList();
}
- public abstract Skin getSkin(FacesContext context, SkinMetadata
skinMetadata);
+ public abstract Skin getSkin(ExternalContext context, SkinMetadata
skinMetadata);
and the related internal API changes.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TRINIDAD-2433) unnecessary use of FacesContext in SkinProvider API
[
https://issues.apache.org/jira/browse/TRINIDAD-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeanne Waldman updated TRINIDAD-2433:
-
Resolution: Fixed
Fix Version/s: 2.1.1-core
Assignee: Jeanne Waldman
Status: Resolved (was: Patch Available)
unnecessary use of FacesContext in SkinProvider API
---
Key: TRINIDAD-2433
URL: https://issues.apache.org/jira/browse/TRINIDAD-2433
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Anand V Nath
Assignee: Jeanne Waldman
Priority: Minor
Fix For: 2.1.1-core
Attachments: jira-2433-new.patch, jira-2433.patch
SkinProvider API uses FacesContext in its methods. All that is done inside
the API is to extract the ExternalContext. So it is sufficient to pass
ExternalContext to the API. Though this is a public API change, the
SkinProvider API is introduced recently and not widely used. This gives us a
chance to correct the API now.
Proposed change:
- public CollectionSkinMetadata getSkinMetadata(FacesContext context)
+ public CollectionSkinMetadata getSkinMetadata(ExternalContext context)
{
return Collections.emptyList();
}
- public abstract Skin getSkin(FacesContext context, SkinMetadata
skinMetadata);
+ public abstract Skin getSkin(ExternalContext context, SkinMetadata
skinMetadata);
and the related internal API changes.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TRINIDAD-2428) rtl styles are getting overriden by non rtl styles
[
https://issues.apache.org/jira/browse/TRINIDAD-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13836743#comment-13836743
]
Jeanne Waldman commented on TRINIDAD-2428:
--
Sending content: C:\Trinidad\Trunk3\src\site\xdoc\devguide\skinning.xml
Sending content:
C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\style\xml\parse\StyleSheetNode.java
Completed: At revision: 1547128
rtl styles are getting overriden by non rtl styles
--
Key: TRINIDAD-2428
URL: https://issues.apache.org/jira/browse/TRINIDAD-2428
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Anand V Nath
Fix For: 2.1.1-core
Attachments: jira2428.patch
Consider the following selectors in a skin
af|foo:rtl
{
color: red;
}
af|foo
{
color: blue;
}
With trinidad-config containing the right-to-left configuration, the selector
that gets applied is
af|foo
{
color: blue;
}
This is wrong. The rtl specific style should get applied.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TRINIDAD-2428) rtl styles are getting overriden by non rtl styles
[
https://issues.apache.org/jira/browse/TRINIDAD-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeanne Waldman updated TRINIDAD-2428:
-
Resolution: Fixed
Status: Resolved (was: Patch Available)
rtl styles are getting overriden by non rtl styles
--
Key: TRINIDAD-2428
URL: https://issues.apache.org/jira/browse/TRINIDAD-2428
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Anand V Nath
Assignee: Jeanne Waldman
Fix For: 2.1.1-core
Attachments: jira2428.patch
Consider the following selectors in a skin
af|foo:rtl
{
color: red;
}
af|foo
{
color: blue;
}
With trinidad-config containing the right-to-left configuration, the selector
that gets applied is
af|foo
{
color: blue;
}
This is wrong. The rtl specific style should get applied.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
Re: [VOTE] Release of Apache MyFaces Trinidad 2.1.0
compiled and ran a test +1 On 11/18/2013 10:44 AM PT, Scott O'Bryan wrote: +1 -- Scott O'Bryan On November 18, 2013 at 8:25:37 AM, Max Starets (max.star...@oracle.com mailto://max.star...@oracle.com) wrote: +1 On 11/15/2013 4:02 PM, Scott O'Bryan wrote: Hello everyone, I was running the tasks needed to release Apache MyFaces Trinidad v. 2.1.0 which is the latest in the Trinidad render kit series. This is the first release in over a year and contains over a hundred bug fixes since the last release. All Blocker bugs are currently fixed and all patches request by the community have been applied. All tests are passing as is the apache-rat:check. I have generated the tag [1] and have deployed the build artifacts to nexus [2]. I have also included the source archive [3]. Please take a look at the Apache MyFaces Trinidad v. 2.1.0 release artifacts and vote. Please note: This vote is majority approval with a minimum of three +1 votes (see [4]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott O'Bryan [1] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.1.0 [2] https://repository.apache.org/content/repositories/orgapachemyfaces-141 [3] https://repository.apache.org/content/repositories/orgapachemyfaces-141/org/apache/myfaces/trinidad/trinidad/2.1.0/trinidad-2.1.0-source-release.zip [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: [Commit Request] (TRINIDAD-2423) wrong assertion for font-size that it should be numeric
I'll do it. On 11/5/2013 2:36 AM PT, Anand V. Nath wrote: Hello, Can someone review and commit the patch uploaded in TRINIDAD-2423? Thanks Anand On 11/5/2013 4:02 PM, Anand V Nath (JIRA) wrote: [ https://issues.apache.org/jira/browse/TRINIDAD-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813828#comment-13813828 ] Anand V Nath commented on TRINIDAD-2423: Skinning framework asserts that font-size specified should be always be a number. Otherwise we throw an AssertionError. font-size can be a non numeric string like [ xx-small | x-small | small | medium | large | x-large | xx-large ]. Thus the assertion is wrong. wrong assertion for font-size that it should be numeric --- Key: TRINIDAD-2423 URL: https://issues.apache.org/jira/browse/TRINIDAD-2423 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.1.0-core Reporter: Anand V Nath Priority: Minor -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TRINIDAD-2423) wrong assertion for font-size that it should be numeric
[ https://issues.apache.org/jira/browse/TRINIDAD-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13814317#comment-13814317 ] Jeanne Waldman commented on TRINIDAD-2423: -- Sending content:trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\style\xml\parse\StyleSheetDocument.java Completed: At revision: 1539162 wrong assertion for font-size that it should be numeric --- Key: TRINIDAD-2423 URL: https://issues.apache.org/jira/browse/TRINIDAD-2423 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.1.0-core Reporter: Anand V Nath Priority: Minor Attachments: jira-2423.patch -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TRINIDAD-2423) wrong assertion for font-size that it should be numeric
[ https://issues.apache.org/jira/browse/TRINIDAD-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman updated TRINIDAD-2423: - Resolution: Fixed Status: Resolved (was: Patch Available) wrong assertion for font-size that it should be numeric --- Key: TRINIDAD-2423 URL: https://issues.apache.org/jira/browse/TRINIDAD-2423 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.1.0-core Reporter: Anand V Nath Priority: Minor Attachments: jira-2423.patch -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TRINIDAD-2406) externalize skin repositories by using SkinProvider SPI
[ https://issues.apache.org/jira/browse/TRINIDAD-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13804318#comment-13804318 ] Jeanne Waldman commented on TRINIDAD-2406: -- Sending content: C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\skin\provider\TrinidadSkinProvider.java Sending content: C:\Trinidad\Trunk3\trinidad-api\src\main\java\org\apache\myfaces\trinidad\skin\SkinAddition.java Sending content: C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\skin\provider\ExternalSkinProvider.java Sending content: C:\Trinidad\Trunk3\trinidad-impl\src\test\java\org\apache\myfaces\trinidadinternal\ui\laf\base\xhtml\XhtmlLafUtilsTest.java Sending content: C:\Trinidad\Trunk3\trinidad-impl\src\test\java\org\apache\myfaces\trinidadinternal\renderkit\RenderKitTestCase.java Sending content: C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\skin\provider\SkinProviderRegistry.java Sending content: C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\skin\SkinUtils.java Sending content: C:\Trinidad\Trunk3\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\config\GlobalConfiguratorImpl.java Completed: At revision: 1535415 externalize skin repositories by using SkinProvider SPI --- Key: TRINIDAD-2406 URL: https://issues.apache.org/jira/browse/TRINIDAD-2406 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Affects Versions: 2.1.0-core Reporter: Anand V Nath Attachments: er-skin-provider-ver7.patch, er-skin-provider-ver8.patch, skin-addition-bug-trinidad.patch, spr-bugfix.patch Introduce SkinProvider SPI. Users can use this to create their own skip repositories and expose their skins to the skinning framework. Provide an API to query skin using skin family, skin id, render kit - This will make use of the existing SkinFactory APIs. Only change here is that it should go over all the available SkinProvider SPIs to find a match. Create internal SkinProvider SPIs to handle the Trinidad and RCF skins (or skins defined using trinidad-skins.xml). Provide an API to list all the available skins from all SkinProvider SPIs and make the skin metadata thus available. Make SkinExtension part of public API so that users can use this class to create the Skin objects which they expose through their SkinProvider SPIs -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TRINIDAD-2406) externalize skin repositories by using SkinProvider SPI
[ https://issues.apache.org/jira/browse/TRINIDAD-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801958#comment-13801958 ] Jeanne Waldman commented on TRINIDAD-2406: -- Sending content: trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\skin\provider\SkinProviderRegistry.java Completed: At revision: 1534684 externalize skin repositories by using SkinProvider SPI --- Key: TRINIDAD-2406 URL: https://issues.apache.org/jira/browse/TRINIDAD-2406 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Affects Versions: 2.1.0-core Reporter: Anand V Nath Attachments: er-skin-provider-ver7.patch, er-skin-provider-ver8.patch, spr-bugfix.patch Introduce SkinProvider SPI. Users can use this to create their own skip repositories and expose their skins to the skinning framework. Provide an API to query skin using skin family, skin id, render kit - This will make use of the existing SkinFactory APIs. Only change here is that it should go over all the available SkinProvider SPIs to find a match. Create internal SkinProvider SPIs to handle the Trinidad and RCF skins (or skins defined using trinidad-skins.xml). Provide an API to list all the available skins from all SkinProvider SPIs and make the skin metadata thus available. Make SkinExtension part of public API so that users can use this class to create the Skin objects which they expose through their SkinProvider SPIs -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TRINIDAD-2421) NullPointerException when property not resolvable through -tr-property-ref
[
https://issues.apache.org/jira/browse/TRINIDAD-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeanne Waldman updated TRINIDAD-2421:
-
Resolution: Fixed
Status: Resolved (was: Patch Available)
NullPointerException when property not resolvable through -tr-property-ref
--
Key: TRINIDAD-2421
URL: https://issues.apache.org/jira/browse/TRINIDAD-2421
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Affects Versions: 2.0.1-core
Reporter: Prakash Udupa
Attachments: TRINIDAD-2421_over_trunk.patch
Original Estimate: 2h
Remaining Estimate: 2h
The bug:
---
Suppose in an application's skin file there is a selector definition with a
custom skin property '-tr-cjk-font-family' like the following:
tr|mySelectorInternal::title{
-tr-cjk-font-family: -tr-property-ref(tr|mySelector,font-family);
}
...and then font-family is not defined anywhere for the selector
tr|mySelector. This will lead to the following NPE...
java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)
at
org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache._getStyleContextResolvedSkinProperties(FileSystemStyleCache.java:790)
at
org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache._createEntry(FileSystemStyleCache.java:605)
at
org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache._getEntry(FileSystemStyleCache.java:465)
at
org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache.getStyleSheetURIs(FileSystemStyleCache.java:183)...
And when this NPE happens, applications are completely broken.
It is perfectly fine for a property to not resolve through tr-property-ref
due to missing dependencies, it is the skinning framework code that should
handle this case gracefully. We should just not try to add a null value to
ConcurrentHashMap in the above code path.
I'll attach a patch with simple code addition that does a not-null check to
cover this case.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TRINIDAD-2421) NullPointerException when property not resolvable through -tr-property-ref
[
https://issues.apache.org/jira/browse/TRINIDAD-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800818#comment-13800818
]
Jeanne Waldman commented on TRINIDAD-2421:
--
Completed: At revision: 1534278
NullPointerException when property not resolvable through -tr-property-ref
--
Key: TRINIDAD-2421
URL: https://issues.apache.org/jira/browse/TRINIDAD-2421
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Affects Versions: 2.0.1-core
Reporter: Prakash Udupa
Attachments: TRINIDAD-2421_over_trunk.patch
Original Estimate: 2h
Remaining Estimate: 2h
The bug:
---
Suppose in an application's skin file there is a selector definition with a
custom skin property '-tr-cjk-font-family' like the following:
tr|mySelectorInternal::title{
-tr-cjk-font-family: -tr-property-ref(tr|mySelector,font-family);
}
...and then font-family is not defined anywhere for the selector
tr|mySelector. This will lead to the following NPE...
java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)
at
org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache._getStyleContextResolvedSkinProperties(FileSystemStyleCache.java:790)
at
org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache._createEntry(FileSystemStyleCache.java:605)
at
org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache._getEntry(FileSystemStyleCache.java:465)
at
org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache.getStyleSheetURIs(FileSystemStyleCache.java:183)...
And when this NPE happens, applications are completely broken.
It is perfectly fine for a property to not resolve through tr-property-ref
due to missing dependencies, it is the skinning framework code that should
handle this case gracefully. We should just not try to add a null value to
ConcurrentHashMap in the above code path.
I'll attach a patch with simple code addition that does a not-null check to
cover this case.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TRINIDAD-2406) externalize skin repositories by using SkinProvider SPI
[ https://issues.apache.org/jira/browse/TRINIDAD-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798005#comment-13798005 ] Jeanne Waldman commented on TRINIDAD-2406: -- Completed: At revision: 1533115 externalize skin repositories by using SkinProvider SPI --- Key: TRINIDAD-2406 URL: https://issues.apache.org/jira/browse/TRINIDAD-2406 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Affects Versions: 2.1.0-core Reporter: Anand V Nath Attachments: er-skin-provider-ver7.patch, er-skin-provider-ver8.patch Introduce SkinProvider SPI. Users can use this to create their own skip repositories and expose their skins to the skinning framework. Provide an API to query skin using skin family, skin id, render kit - This will make use of the existing SkinFactory APIs. Only change here is that it should go over all the available SkinProvider SPIs to find a match. Create internal SkinProvider SPIs to handle the Trinidad and RCF skins (or skins defined using trinidad-skins.xml). Provide an API to list all the available skins from all SkinProvider SPIs and make the skin metadata thus available. Make SkinExtension part of public API so that users can use this class to create the Skin objects which they expose through their SkinProvider SPIs -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TRINIDAD-2406) externalize skin repositories by using SkinProvider SPI
[ https://issues.apache.org/jira/browse/TRINIDAD-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798075#comment-13798075 ] Jeanne Waldman commented on TRINIDAD-2406: -- forgot to add BaseSkinProvider.java in previous commit. Completed: At revision: 1533151 externalize skin repositories by using SkinProvider SPI --- Key: TRINIDAD-2406 URL: https://issues.apache.org/jira/browse/TRINIDAD-2406 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Affects Versions: 2.1.0-core Reporter: Anand V Nath Attachments: er-skin-provider-ver7.patch, er-skin-provider-ver8.patch Introduce SkinProvider SPI. Users can use this to create their own skip repositories and expose their skins to the skinning framework. Provide an API to query skin using skin family, skin id, render kit - This will make use of the existing SkinFactory APIs. Only change here is that it should go over all the available SkinProvider SPIs to find a match. Create internal SkinProvider SPIs to handle the Trinidad and RCF skins (or skins defined using trinidad-skins.xml). Provide an API to list all the available skins from all SkinProvider SPIs and make the skin metadata thus available. Make SkinExtension part of public API so that users can use this class to create the Skin objects which they expose through their SkinProvider SPIs -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TRINIDAD-2398) add component tracking ability to RequestContext
[ https://issues.apache.org/jira/browse/TRINIDAD-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13769739#comment-13769739 ] Jeanne Waldman commented on TRINIDAD-2398: -- Sending content: C:\Trinidad\Trunk\trinidad-api\src\main\java\org\apache\myfaces\trinidad\component\UIXCollection.java Sending content: C:\Trinidad\Trunk\trinidad-api\src\main\java\org\apache\myfaces\trinidad\component\UIXComponentBase.java Sending content: C:\Trinidad\Trunk\trinidad-api\src\main\java\org\apache\myfaces\trinidad\component\ComponentProcessingContext.java Sending content: C:\Trinidad\Trunk\trinidad-api\src\main\java-templates\org\apache\myfaces\trinidad\component\UIXEditableValueTemplate.java Sending content: C:\Trinidad\Trunk\trinidad-api\src\main\java-templates\org\apache\myfaces\trinidad\component\UIXIteratorTemplate.java Sending content: C:\Trinidad\Trunk\trinidad-api\src\main\java\org\apache\myfaces\trinidad\component\UIXComponent.java Completed: At revision: 1524142 add component tracking ability to RequestContext Key: TRINIDAD-2398 URL: https://issues.apache.org/jira/browse/TRINIDAD-2398 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.1-core Environment: this is environment independent. Reporter: Jing Wu Attachments: JIRA-2398-main-fix.patch, JIRA-2398-main.patch, JIRA-2398-main-sept17.patch Original Estimate: 72h Remaining Estimate: 72h there are cases where we need to know which component is under processing. This can be achieved if we can maintain component stack in RequestContext and provide API to push/pop/peek the component stack. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2415) nested selectors not generated correctly when used with icon selectors
[ https://issues.apache.org/jira/browse/TRINIDAD-2415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13764644#comment-13764644 ] Jeanne Waldman commented on TRINIDAD-2415: -- Anand, Could you give me more information -- What is the content of this selector? Is it an 'icon' selector (this turns into an Icon skinning framework object), or is it meant to be a style selector (one that gets written out to the css file). It sounds like it is a style selector that gets written out to the css file. The user should be using icon-style instead of -icon. You should see a warning on the console if you end with -icon. .AFSomeAlias af|style-icon-style or .AFSomeAlias af|style-icon-style:hover Do you get the error if the user uses the -icon-style? If the user can change his selector name, then he should. I agree that you should still fix this issue for those who used -icon as a style selector (even though they shouldn't have, but that isn't super clear to a user they shouldn't - except the warning on the console). nested selectors not generated correctly when used with icon selectors -- Key: TRINIDAD-2415 URL: https://issues.apache.org/jira/browse/TRINIDAD-2415 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.1.0-core Reporter: Anand V Nath Attachments: jira-2415.patch This bug is about a nested selector specified with an -icon selector. Eg: .AFSomeAlias af|style-icon or .AFSomeAlias af|style-icon:hover This gets rendered as AFSomeAlias af_style-icon AFSomeAlias af_style-icon:hover The reason why this happens is that we strip out the leading dot for the icon styles. But it is required only for the icon alias cases. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2397) Provide API to discover location of document that contains tag definition for a given component
[ https://issues.apache.org/jira/browse/TRINIDAD-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13763146#comment-13763146 ] Jeanne Waldman commented on TRINIDAD-2397: -- Sending content: C:\Trinidad\Trunk\trinidad-api\src\main\java\org\apache\myfaces\trinidad\util\ComponentUtils.java Completed: At revision: 1521532 Provide API to discover location of document that contains tag definition for a given component --- Key: TRINIDAD-2397 URL: https://issues.apache.org/jira/browse/TRINIDAD-2397 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Reporter: Prakash Udupa Fix For: 2.1.0-core Attachments: TRINIDAD-2397_improvement_over_trunk_using_pageresolver.patch, TRINIDAD-2397_patch_over_trunk.patch There are custom tags and components that insert other dynamic contents (i.e subtree of components) into the component tree. The tags for such dynamically added components come from a document fragment that is different from where the inserting component / tags come from. For example in Oracle's ADF component library, there are region, pageTemplates and declarativeComponent that does such dynamic includes. There is often a need to know the document where the corresponding tag is defined for a given component. A couple of usecases are: 1. Browser based page editor or Designtime @ Runtime kind of products where they will need to change the tags in the document when a component is customized / edited at runtime. 2. Ability to store any runtime customizations for components against the document where its tag belongs. (For example. when the columns of dynamically added table is reordered) The inserting tags / components and the inserted components would be used best to determine the location of the fragment document that they include / or where they came from. We need to provide some hooks where the authors of such tags / component are able to provide the URL for the documents given the components. This enhancement asks for providing an API that provides URL for such documents, and also to publish the necessary hooks that tag / component authors can implement when then the URL providing API can use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2409) improve diagnostics during tag execution component binding failures
[ https://issues.apache.org/jira/browse/TRINIDAD-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13745131#comment-13745131 ] Jeanne Waldman commented on TRINIDAD-2409: -- Sending content: C:\Trinidad\Trunk\trinidad-api\src\main\java\org\apache\myfaces\trinidad\webapp\UIXComponentELTag.java Sending content: C:\Trinidad\Trunk\trinidad-api\src\main\xrts\org\apache\myfaces\trinidad\resource\LoggerBundle.xrts Completed: At revision: 1515879 improve diagnostics during tag execution component binding failures --- Key: TRINIDAD-2409 URL: https://issues.apache.org/jira/browse/TRINIDAD-2409 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.1-core Reporter: Pavitra Subramaniam Attachments: jira-2409.patch 2 places where error reporting can be improved is in 1. UIXComponentELTag.doStartTag() We could add a try/catch around the super.doStartTag(), do some severe logging (eg.log a scoped id) in response to exceptions, and re-throw. 2. UIXComponentELTag.createComponent() This might be a reasonable place to detect the cases where a component that you pull out of a component binding during createComponent() is already attached to some component tree- and thus the (severe) error is justified. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2409) improve diagnostics during tag execution component binding failures
[ https://issues.apache.org/jira/browse/TRINIDAD-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman updated TRINIDAD-2409: - Resolution: Fixed Status: Resolved (was: Patch Available) improve diagnostics during tag execution component binding failures --- Key: TRINIDAD-2409 URL: https://issues.apache.org/jira/browse/TRINIDAD-2409 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.1-core Reporter: Pavitra Subramaniam Attachments: jira-2409.patch 2 places where error reporting can be improved is in 1. UIXComponentELTag.doStartTag() We could add a try/catch around the super.doStartTag(), do some severe logging (eg.log a scoped id) in response to exceptions, and re-throw. 2. UIXComponentELTag.createComponent() This might be a reasonable place to detect the cases where a component that you pull out of a component binding during createComponent() is already attached to some component tree- and thus the (severe) error is justified. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2397) Provide API to discover location of document that contains tag definition for a given component
[ https://issues.apache.org/jira/browse/TRINIDAD-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13735219#comment-13735219 ] Jeanne Waldman commented on TRINIDAD-2397: -- /myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/util/ClassLoaderUtils.java /myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/util/ComponentUtils.java svn 1507065 Provide API to discover location of document that contains tag definition for a given component --- Key: TRINIDAD-2397 URL: https://issues.apache.org/jira/browse/TRINIDAD-2397 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Reporter: Prakash Udupa Attachments: TRINIDAD-2397_patch_over_trunk.patch There are custom tags and components that insert other dynamic contents (i.e subtree of components) into the component tree. The tags for such dynamically added components come from a document fragment that is different from where the inserting component / tags come from. For example in Oracle's ADF component library, there are region, pageTemplates and declarativeComponent that does such dynamic includes. There is often a need to know the document where the corresponding tag is defined for a given component. A couple of usecases are: 1. Browser based page editor or Designtime @ Runtime kind of products where they will need to change the tags in the document when a component is customized / edited at runtime. 2. Ability to store any runtime customizations for components against the document where its tag belongs. (For example. when the columns of dynamically added table is reordered) The inserting tags / components and the inserted components would be used best to determine the location of the fragment document that they include / or where they came from. We need to provide some hooks where the authors of such tags / component are able to provide the URL for the documents given the components. This enhancement asks for providing an API that provides URL for such documents, and also to publish the necessary hooks that tag / component authors can implement when then the URL providing API can use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2397) Provide API to discover location of document that contains tag definition for a given component
[ https://issues.apache.org/jira/browse/TRINIDAD-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman updated TRINIDAD-2397: - Resolution: Fixed Fix Version/s: 2.1.0-core Status: Resolved (was: Patch Available) Provide API to discover location of document that contains tag definition for a given component --- Key: TRINIDAD-2397 URL: https://issues.apache.org/jira/browse/TRINIDAD-2397 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Reporter: Prakash Udupa Fix For: 2.1.0-core Attachments: TRINIDAD-2397_patch_over_trunk.patch There are custom tags and components that insert other dynamic contents (i.e subtree of components) into the component tree. The tags for such dynamically added components come from a document fragment that is different from where the inserting component / tags come from. For example in Oracle's ADF component library, there are region, pageTemplates and declarativeComponent that does such dynamic includes. There is often a need to know the document where the corresponding tag is defined for a given component. A couple of usecases are: 1. Browser based page editor or Designtime @ Runtime kind of products where they will need to change the tags in the document when a component is customized / edited at runtime. 2. Ability to store any runtime customizations for components against the document where its tag belongs. (For example. when the columns of dynamically added table is reordered) The inserting tags / components and the inserted components would be used best to determine the location of the fragment document that they include / or where they came from. We need to provide some hooks where the authors of such tags / component are able to provide the URL for the documents given the components. This enhancement asks for providing an API that provides URL for such documents, and also to publish the necessary hooks that tag / component authors can implement when then the URL providing API can use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2405) Allow numberConverter to specify roundingmode
[ https://issues.apache.org/jira/browse/TRINIDAD-2405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13733662#comment-13733662 ] Jeanne Waldman commented on TRINIDAD-2405: -- Sending content: C:\Trinidad\trinidad-maven\maven-javascript-plugin\pom.xml Sending content: C:\Trinidad\trinidad-maven\maven-javacc-plugin\pom.xml Sending content: C:\Trinidad\trinidad-maven\maven-jdev-plugin\pom.xml Sending content: C:\Trinidad\trinidad-maven\maven-faces-plugin\src\main\java\org\apache\myfaces\trinidadbuild\plugin\faces\util\ClassLoaderUtils.java Sending content: C:\Trinidad\trinidad-maven\maven-faces-plugin\src\main\java\org\apache\myfaces\trinidadbuild\plugin\faces\generator\taglib\AbstractTagGenerator.java Sending content: C:\Trinidad\trinidad-maven\maven-i18n-plugin\pom.xml Sending content: C:\Trinidad\trinidad-maven\maven-faces-plugin\src\main\java\org\apache\myfaces\trinidadbuild\plugin\faces\generator\taglib\TrinidadConverterTagGenerator.java Sending content: C:\Trinidad\trinidad-maven\maven-xrts-plugin\pom.xml Sending content: C:\Trinidad\trinidad-maven\pom.xml Sending content: C:\Trinidad\trinidad-maven\maven-faces-plugin\pom.xml Sending content: C:\Trinidad\trinidad-maven\maven-tagdoc-plugin\pom.xml Completed: At revision: 1511859 Allow numberConverter to specify roundingmode - Key: TRINIDAD-2405 URL: https://issues.apache.org/jira/browse/TRINIDAD-2405 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Yee-Wah Lee Priority: Minor Attachments: TrinPlugin_2405_numberConverterRoundingCode.diff, TrinPlugin_2405_numberConverterRoundingPOM.diff, TrinTrunk_2405_numberConverterRounding.diff, TrinTrunk_2405_numberConverterRoundingPOM.diff NumberFormat has a method setRoundingMode() which controls how numbers are rounded. The JDK default is RoundingMode.HALF_EVEN. This tracks adding an attribute to the numberConverter so that the rounding mode can be set, instead of always using JDK defaults. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2405) Allow numberConverter to specify roundingmode
[ https://issues.apache.org/jira/browse/TRINIDAD-2405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13733677#comment-13733677 ] Jeanne Waldman commented on TRINIDAD-2405: -- Sending content: C:\Trinidad\Trunk\trinidad-build\src\main\resources\META-INF\maven-faces-plugin\converters\trinidad\Number.xml Sending content: C:\Trinidad\Trunk\trinidad-examples\trinidad-demo\pom.xml Sending content: C:\Trinidad\Trunk\trinidad-build\pom.xml Sending content: C:\Trinidad\Trunk\trinidad-impl\pom.xml Sending content: C:\Trinidad\Trunk\trinidad-examples\trinidad-blank\pom.xml Sending content: C:\Trinidad\Trunk\trinidad-api\src\main\resources\trinidad-config.xsd Sending content: C:\Trinidad\Trunk\trinidad-examples\trinidad-demo\src\main\webapp\convertValidate\convertValidate.jspx Sending content: C:\Trinidad\Trunk\pom.xml Sending content: C:\Trinidad\Trunk\trinidad-examples\trinidad-components-showcase\pom.xml Sending content: C:\Trinidad\Trunk\trinidad-api\src\main\java\org\apache\myfaces\trinidad\context\RequestContext.java Sending content: C:\Trinidad\Trunk\trinidad-api\pom.xml Sending content: C:\Trinidad\Trunk\trinidad-examples\pom.xml Sending content: C:\Trinidad\Trunk\trinidad-assembly\pom.xml Sending content: C:\Trinidad\Trunk\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\context\RequestContextImpl.java Sending content: C:\Trinidad\Trunk\trinidad-examples\trinidad-example-assembly\pom.xml Sending content: C:\Trinidad\Trunk\trinidad-impl\src\main\java\org\apache\myfaces\trinidadinternal\context\RequestContextBean.java Sending content: C:\Trinidad\Trunk\trinidad-api\src\main\xrts\org\apache\myfaces\trinidad\resource\LoggerBundle.xrts Sending content: C:\Trinidad\Trunk\trinidad-api\src\main\java\org\apache\myfaces\trinidad\convert\NumberConverter.java Completed: At revision: 1511870 Allow numberConverter to specify roundingmode - Key: TRINIDAD-2405 URL: https://issues.apache.org/jira/browse/TRINIDAD-2405 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Yee-Wah Lee Priority: Minor Attachments: TrinPlugin_2405_numberConverterRoundingCode.diff, TrinPlugin_2405_numberConverterRoundingPOM.diff, TrinTrunk_2405_numberConverterRounding.diff, TrinTrunk_2405_numberConverterRoundingPOM.diff NumberFormat has a method setRoundingMode() which controls how numbers are rounded. The JDK default is RoundingMode.HALF_EVEN. This tracks adding an attribute to the numberConverter so that the rounding mode can be set, instead of always using JDK defaults. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2402) mechanism to setup a new component binding context
[
https://issues.apache.org/jira/browse/TRINIDAD-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13720140#comment-13720140
]
Jeanne Waldman commented on TRINIDAD-2402:
--
Revision: 1507045
Author: jwaldman
Date: 9:11:10 AM, Thursday, July 25, 2013
Message:
TRINIDAD-2402 mechanism to setup a new component binding context
thanks to Pavitra Subramaniam for the patch
Modified :
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/context/RequestContext.java
Modified :
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/webapp/UIXComponentELTag.java
Modified :
/myfaces/trinidad/trunk/trinidad-api/src/main/xrts/org/apache/myfaces/trinidad/resource/LoggerBundle.xrts
mechanism to setup a new component binding context
--
Key: TRINIDAD-2402
URL: https://issues.apache.org/jira/browse/TRINIDAD-2402
Project: MyFaces Trinidad
Issue Type: Improvement
Affects Versions: 2.0.1-core
Reporter: Pavitra Subramaniam
Attachments: trinidad-2402.patch
There are usecases where a custom tag that provides the ability to load
dynamic layouts (or page fragments) based on app flow, requiring that new
components be re-created when the tag is executed and a new layout different
from the current one needs to be loaded.
Merely deleting the component sub-trees in the tag handler does not entirely
address the issue because when the tag is re-executed today, if a binding EL
is set on the component, then the component instance held by the backing bean
instance (typically a reuqest scoped bean) get reused instead of a new
component being created.
In order to force create the component instance, this new API will allow tag
handlers to notify the framework by starting a new component binding
context. Between a pair of push and pop calls, component bindings will be
cleared allowing for new component instances to be created and pushed to the
backing bean.
/**
* Starts a new component binding context. Typically called from tag
handlers when component
* bindings in its subtree needs to be cleared, forcing the creation of new
components.
*
* @param context FacesContext instance
* @see RequestContext#popComponentBindingContext
* @see RequestContext#isInComponentBindingContext
*/
public static void pushComponentBindingContext(FacesContext context)
{
}
/**
* Pops out of the last pushed component binding context. Component binding
instances will not be
* cleared after popping out the outermost context.
*
* @param context FacesContext instance
* @see RequestContext#pushComponentBindingContext
* @see RequestContext#isInComponentBindingContext
*/
public static void popComponentBindingContext(FacesContext context)
{
}
/**
* Returns true if we are currently within a component binding context.
*
* @see RequestContext#pushComponentBindingContext
* @see RequestContext#popComponentBindingContext
*/
public static boolean isInComponentBindingContext(FacesContext context)
{
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2398) add component tracking ability to RequestContext
[ https://issues.apache.org/jira/browse/TRINIDAD-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13720160#comment-13720160 ] Jeanne Waldman commented on TRINIDAD-2398: -- Revision: 1507147 Author: jwaldman Date: 3:39:25 PM, Thursday, July 25, 2013 Message: TRINIDAD-2398 add component tracking ability to RequestContext Thanks to Jing Wu for the patch Modified : /myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/component/UIXComponent.java Modified : /myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/component/UIXComponentBase.java Modified : /myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/context/RequestContext.java Modified : /myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/render/CoreRenderer.java Modified : /myfaces/trinidad/trunk/trinidad-api/src/test/java/org/apache/myfaces/trinidad/component/UIComponentTestCase.java Modified : /myfaces/trinidad/trunk/trinidad-api/src/test/java/org/apache/myfaces/trinidad/context/MockRequestContext.java Modified : /myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/config/GlobalConfiguratorImpl.java Modified : /myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/context/RequestContextFactoryImpl.java Modified : /myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/context/RequestContextImpl.java Modified : /myfaces/trinidad/trunk/trinidad-impl/src/test/java/org/apache/myfaces/trinidadinternal/renderkit/MRequestContext.java Modified : /myfaces/trinidad/trunk/trinidad-impl/src/test/java/org/apache/myfaces/trinidadinternal/renderkit/RenderKitPerfTestCase.java Modified : /myfaces/trinidad/trunk/trinidad-impl/src/test/java/org/apache/myfaces/trinidadinternal/renderkit/RenderKitTestCase.java add component tracking ability to RequestContext Key: TRINIDAD-2398 URL: https://issues.apache.org/jira/browse/TRINIDAD-2398 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.1-core Environment: this is environment independent. Reporter: Jing Wu Attachments: JIRA-2398-main.patch Original Estimate: 72h Remaining Estimate: 72h there are cases where we need to know which component is under processing. This can be achieved if we can maintain component stack in RequestContext and provide API to push/pop/peek the component stack. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2383) issue with table stamp state
[ https://issues.apache.org/jira/browse/TRINIDAD-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13670600#comment-13670600 ] Jeanne Waldman commented on TRINIDAD-2383: -- Completed: At revision: 1487973 issue with table stamp state Key: TRINIDAD-2383 URL: https://issues.apache.org/jira/browse/TRINIDAD-2383 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Environment: This issue is environment independent. Reporter: Jing Wu Attachments: stampstate-16632043-main.patch Original Estimate: 48h Remaining Estimate: 48h A component's stamp state contains 3 parts: the stamp state of itself, the stamp state of its children (if there's any), the stamp state of its facets (if there's any). We use array to store stamp state of its children, and facets. But if somehow between stamp saving and restoring, the child components are changed in position, we would run into classcastexception since we expect one component but encounter a different one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2389) review and fix values for @platform in skinning documentation
[ https://issues.apache.org/jira/browse/TRINIDAD-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13665434#comment-13665434 ] Jeanne Waldman commented on TRINIDAD-2389: -- SVN revision 1485788 review and fix values for @platform in skinning documentation - Key: TRINIDAD-2389 URL: https://issues.apache.org/jira/browse/TRINIDAD-2389 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.1.0-core Reporter: Anand V Nath Priority: Minor Fix For: 2.1.0-core Attachments: jira-2389.patch This bug is for reviewing and fixing the valid values for @platform mentioned in the skinning documentation: http://myfaces.apache.org/trinidad/devguide/skinning.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2385) trinidad-config documentation wrong for time-zone parameter defaulting
[ https://issues.apache.org/jira/browse/TRINIDAD-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13658687#comment-13658687 ] Jeanne Waldman commented on TRINIDAD-2385: -- Sending content: C:\Trinidad\Trunk\src\site\xdoc\devguide\configuration.xml Completed: At revision: 1483020 trinidad-config documentation wrong for time-zone parameter defaulting -- Key: TRINIDAD-2385 URL: https://issues.apache.org/jira/browse/TRINIDAD-2385 Project: MyFaces Trinidad Issue Type: Bug Reporter: Yee-Wah Lee Priority: Minor Attachments: trunk_2385_timezoneConfigDoc.diff The documentation for time-zone defaulting in this link is incorrect: http://myfaces.apache.org/trinidad/devguide/configuration.html#trinidad-config.xml The code does not attempt to guess the user's timezone. Instead, it defaults to the value returned by JDK TimeZone.getDefault -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2380) Collection Component's internal state is not initialized properly in some cases.
[ https://issues.apache.org/jira/browse/TRINIDAD-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman updated TRINIDAD-2380: - Resolution: Fixed Status: Resolved (was: Patch Available) Collection Component's internal state is not initialized properly in some cases. Key: TRINIDAD-2380 URL: https://issues.apache.org/jira/browse/TRINIDAD-2380 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Environment: generic issue, environment independent. Reporter: Jing Wu Attachments: JIRA-2380-main.patch Original Estimate: 24h Remaining Estimate: 24h UIXCollection's internal state sometimes is not initialized properly. This could happen is backing bean calls UIXTable.getSelectedRowKey() at the time table is just initialized. Calling UIXTable.getSelectedRowKey() will force table to flush its model, i.e. make sure internal state cached model is up to date. So this will setup internal state's model reference, but not other variables, causing silent functional failure later on. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2382) review and fix values for @agent in skinning documentation
[ https://issues.apache.org/jira/browse/TRINIDAD-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman updated TRINIDAD-2382: - Resolution: Fixed Status: Resolved (was: Patch Available) review and fix values for @agent in skinning documentation -- Key: TRINIDAD-2382 URL: https://issues.apache.org/jira/browse/TRINIDAD-2382 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.1.0-core Reporter: Anand V Nath Priority: Minor Fix For: 2.1.0-core Attachments: bug-14617103.patch This bug is for reviewing and fixing the values for @agent rule in skinning documentation published at: http://myfaces.apache.org/trinidad/devguide/skinning.html Currently the document is outdated and does not contain all valid values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (TRINIDAD-2377) surrogate characters in outputFormatted throws IllegalArgumentException
[
https://issues.apache.org/jira/browse/TRINIDAD-2377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13629749#comment-13629749
]
Jeanne Waldman edited comment on TRINIDAD-2377 at 4/16/13 5:48 PM:
---
outputFormatted splits the characters, so we are getting the high surrogate,
but not the low surrogate in HTMLEscapes. See FormattedTextParser.
I have a patch where I remove the IllegalArgumentException in HTMLEscapes and
only increase 'i' if the surrogate is valid. I still write out the character.
The remaining issue is surrogate chars still shown as garbled in Firefox but
only in outputFormatted. It should be good in IE. So there is no regression. We
will need to log a new issue for this remaining issue.
was (Author: jeanne.wald...@oracle.com):
outputFormatted splits the characters, so we are getting the high
surrogate, but not the low surrogate in HTMLEscapes. See FormattedTextParser.
I have a patch where I remove the IllegalArgumentException in HTMLEscapes, and
in this case
I log a fine message, and continue parsing as it used to do.
The remaining issue is surrogate chars still shown as garbled in Firefox but
only in outputFormatted. It should be good in IE. So there is no regression.
surrogate characters in outputFormatted throws IllegalArgumentException
---
Key: TRINIDAD-2377
URL: https://issues.apache.org/jira/browse/TRINIDAD-2377
Project: MyFaces Trinidad
Issue Type: Bug
Reporter: Jeanne Waldman
Assignee: Jeanne Waldman
af:outputFormatted value=#{TestInput.surrogateVal} id=of1/
where
TestInput.surrogateValue is a surrogateValue, like
private String surrogateVal = \ud840\udc00;
public void setSurrogateVal(String surrogateVal) {
this.surrogateVal = surrogateVal;
}
public String getSurrogateVal() {
return surrogateVal;
The page shows up blank, and you get an IllegalArgumentException from
HTMLEscapes. outputText works fine. This is a regression caused by
MYFACES-3690 Trinidad doesn't support surrogate characters
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2377) surrogate characters in outputFormatted throws IllegalArgumentException
Jeanne Waldman created TRINIDAD-2377:
Summary: surrogate characters in outputFormatted throws
IllegalArgumentException
Key: TRINIDAD-2377
URL: https://issues.apache.org/jira/browse/TRINIDAD-2377
Project: MyFaces Trinidad
Issue Type: Bug
Reporter: Jeanne Waldman
Assignee: Jeanne Waldman
af:outputFormatted value=#{TestInput.surrogateVal} id=of1/
where
TestInput.surrogateValue is a surrogateValue, like
private String surrogateVal = \ud840\udc00;
public void setSurrogateVal(String surrogateVal) {
this.surrogateVal = surrogateVal;
}
public String getSurrogateVal() {
return surrogateVal;
The page shows up blank, and you get an IllegalArgumentException from
HTMLEscapes. outputText works fine. This is a regression caused by MYFACES-3690
Trinidad doesn't support surrogate characters
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2377) surrogate characters in outputFormatted throws IllegalArgumentException
[
https://issues.apache.org/jira/browse/TRINIDAD-2377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeanne Waldman updated TRINIDAD-2377:
-
Status: Patch Available (was: Open)
surrogate characters in outputFormatted throws IllegalArgumentException
---
Key: TRINIDAD-2377
URL: https://issues.apache.org/jira/browse/TRINIDAD-2377
Project: MyFaces Trinidad
Issue Type: Bug
Reporter: Jeanne Waldman
Assignee: Jeanne Waldman
af:outputFormatted value=#{TestInput.surrogateVal} id=of1/
where
TestInput.surrogateValue is a surrogateValue, like
private String surrogateVal = \ud840\udc00;
public void setSurrogateVal(String surrogateVal) {
this.surrogateVal = surrogateVal;
}
public String getSurrogateVal() {
return surrogateVal;
The page shows up blank, and you get an IllegalArgumentException from
HTMLEscapes. outputText works fine. This is a regression caused by
MYFACES-3690 Trinidad doesn't support surrogate characters
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2377) surrogate characters in outputFormatted throws IllegalArgumentException
[
https://issues.apache.org/jira/browse/TRINIDAD-2377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13629797#comment-13629797
]
Jeanne Waldman commented on TRINIDAD-2377:
--
Changed code from
// only increase i if a valid surrogate code point is returned
if (Character.isSupplementaryCodePoint(surrogateCodePoint))
{
buffIndex =
_writeDecRef(out, buff, buffIndex, surrogateCodePoint);
i++;
}
else
{
throw new IllegalArgumentException(
_LOG.getMessage(INVALID_SURROGATE_CHAR, new Object[] { ch,
surrogateCodePoint, i }));
}
to
buffIndex =
_writeDecRef(out, buff, buffIndex, surrogateCodePoint);
// only increase i if a valid surrogate code point is returned
if (Character.isSupplementaryCodePoint(surrogateCodePoint))
{
i++;
}
else
{
// DO NOT BLOW UP. We have a bug in outputFormatted+surrogates, and
we don't want to blow up.
// blow up if invalid utf-16 characters encountered
//throw new IllegalArgumentException(
// _LOG.getMessage(INVALID_SURROGATE_CHAR, new Object[] { ch,
surrogateCodePoint, i }));
}
surrogate characters in outputFormatted throws IllegalArgumentException
---
Key: TRINIDAD-2377
URL: https://issues.apache.org/jira/browse/TRINIDAD-2377
Project: MyFaces Trinidad
Issue Type: Bug
Reporter: Jeanne Waldman
Assignee: Jeanne Waldman
Attachments: TRINIDAD-SurrogateOutputFormattedPatch.patch
af:outputFormatted value=#{TestInput.surrogateVal} id=of1/
where
TestInput.surrogateValue is a surrogateValue, like
private String surrogateVal = \ud840\udc00;
public void setSurrogateVal(String surrogateVal) {
this.surrogateVal = surrogateVal;
}
public String getSurrogateVal() {
return surrogateVal;
The page shows up blank, and you get an IllegalArgumentException from
HTMLEscapes. outputText works fine. This is a regression caused by
MYFACES-3690 Trinidad doesn't support surrogate characters
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3690) Trinidad doesn't support surrogate characters
Jeanne Waldman created MYFACES-3690: --- Summary: Trinidad doesn't support surrogate characters Key: MYFACES-3690 URL: https://issues.apache.org/jira/browse/MYFACES-3690 Project: MyFaces Core Issue Type: Bug Reporter: Jeanne Waldman Assignee: Jeanne Waldman [Problem Description:] Create a simple jsf page as below: tr:inputText label=Label 1 id=it1/ tr:commandButton text=commandButton 1 id=cb1/ In IE7, when we enter a surrogate character, then click submit button, surrogate character can be correctly displayed when page rendered. While in FF3, the surrogate character are displayed as 2 characters after clicked the submit button. NOTE: If using pre 7 jetty, the surrogate char will disappear (bug in jetty). I had to use JDeveloper to reproduce. [Test Data:] You can copy a sample surrogate character from: http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=%F0%A0%80%80 Note: You must install surrogate font in your env to display the surrogate characters. [Analysis:] Check the html source of generated page, the surrogate character is written into 2 decimal value '#55360;#56320;', and Firefox can't recognize these 2 Decimal value as a single surrogate character. While in IE, it can recognize these 2 decimal value represent a single surrogate character. According to http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=%F0%A0%80%80, the decimal value for this surrogate character is 131072, if in html source code, we write #131072; instead of '#55360;#56320;', the surrogate character can display well in both IE7 and FF3. Fix: The fix is to HTMLEscapes and XMLEscapes. if char is high-surrogate, use Character.getCodePoint and encode that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2322) Need to update the fileUpload.xml xdoc so to provide a missing configuration
[ https://issues.apache.org/jira/browse/TRINIDAD-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13469494#comment-13469494 ] Jeanne Waldman commented on TRINIDAD-2322: -- This is the configuration that was added org.apache.myfaces.trinidad.UPLOAD_MAX_FILE_SIZ Need to update the fileUpload.xml xdoc so to provide a missing configuration Key: TRINIDAD-2322 URL: https://issues.apache.org/jira/browse/TRINIDAD-2322 Project: MyFaces Trinidad Issue Type: Bug Components: Documentation Affects Versions: 2.0.1-core Reporter: Ji Kim Priority: Minor Attachments: fileUpload.xml.patch, updatedFileUpload.png Currently there exists a missing configuration within http://myfaces.apache.org/trinidad/devguide/fileUpload.html, the configuration documentation requires an update. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (TRINIDAD-2322) Need to update the fileUpload.xml xdoc so to provide a missing configuration
[ https://issues.apache.org/jira/browse/TRINIDAD-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13469494#comment-13469494 ] Jeanne Waldman edited comment on TRINIDAD-2322 at 10/5/12 3:43 AM: --- This is the configuration that was added org.apache.myfaces.trinidad.UPLOAD_MAX_FILE_SIZE was (Author: jeanne.wald...@oracle.com): This is the configuration that was added org.apache.myfaces.trinidad.UPLOAD_MAX_FILE_SIZ Need to update the fileUpload.xml xdoc so to provide a missing configuration Key: TRINIDAD-2322 URL: https://issues.apache.org/jira/browse/TRINIDAD-2322 Project: MyFaces Trinidad Issue Type: Bug Components: Documentation Affects Versions: 2.0.1-core Reporter: Ji Kim Priority: Minor Attachments: fileUpload.xml.patch, updatedFileUpload.png Currently there exists a missing configuration within http://myfaces.apache.org/trinidad/devguide/fileUpload.html, the configuration documentation requires an update. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2290) Need to log the exception in each catch block of ResourceServlet._getResourceLoader()
[ https://issues.apache.org/jira/browse/TRINIDAD-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman updated TRINIDAD-2290: - Resolution: Fixed Fix Version/s: 2.1.0-core Assignee: Jeanne Waldman Status: Resolved (was: Patch Available) fixed in Trunk Need to log the exception in each catch block of ResourceServlet._getResourceLoader() - Key: TRINIDAD-2290 URL: https://issues.apache.org/jira/browse/TRINIDAD-2290 Project: MyFaces Trinidad Issue Type: Bug Components: Infrastructure Affects Versions: 1.2.12-core, 2.0.0-core Reporter: Mark Yvanovich Assignee: Jeanne Waldman Fix For: 2.1.0-core Attachments: jira2290-trunk.patch Original Estimate: 24h Remaining Estimate: 24h We are currently silently ignoring the exceptions that occur when looking up the class loaders in ResourceServlet_getResourceLoader(). We need to log the exception and also log the cause if there is one so that we get a good stack trace of the actual source of the exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2286) alias wrongly specified in base-desktop.css
[ https://issues.apache.org/jira/browse/TRINIDAD-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13410586#comment-13410586 ] Jeanne Waldman commented on TRINIDAD-2286: -- Anand tested the generated css files both in trinidad and ADF Rich Client (fusion and fusion-simple) before and after the change to check regressions. alias wrongly specified in base-desktop.css --- Key: TRINIDAD-2286 URL: https://issues.apache.org/jira/browse/TRINIDAD-2286 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.0.1-core Reporter: Anand V Nath Priority: Minor Attachments: jira-2286.patch Many alias references in base-desktop.css misses the leading dot. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2286) alias wrongly specified in base-desktop.css
[ https://issues.apache.org/jira/browse/TRINIDAD-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13410608#comment-13410608 ] Jeanne Waldman commented on TRINIDAD-2286: -- I searched for VeryDarkExtraAccentForeground and found that it wasn't being used anywhere. I vote for deleting these aliases instead of fixing them. alias wrongly specified in base-desktop.css --- Key: TRINIDAD-2286 URL: https://issues.apache.org/jira/browse/TRINIDAD-2286 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.0.1-core Reporter: Anand V Nath Priority: Minor Attachments: jira-2286.patch Many alias references in base-desktop.css misses the leading dot. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Move Trinidad Trunk to JSF 2.1
+1 Prakash Udupa wrote, On 3/26/2012 8:14 AM PT: +1 On 3/26/2012 9:45 AM, Matt Cooper wrote: +1 On Mon, Mar 26, 2012 at 8:42 AM, gabrielle.crawf...@oracle.com wrote: +1 On Mar 25, 2012, at 9:17 AM, Scott O'Bryan darkar...@gmail.com wrote: Hey all, Currently the Trinidad Trunk is set to JSF 2.0. There have been a number of blocker bugs recently (namely some issues with the ViewDeclarationLanguages and composite components) which have generated some blocking bugs. These problems were cause by additional methods in the ViewDeclarationLanguage syntax which we have to wrap for some of the functionality in Trinidad to be complete. At this time I propose the following: 1. Copy the current Trinidad Trunk to be branches/trinidad-2.0.x 2. Change the version of Trinidad Trunk to be 2.1.0-SNAPSHOT 3. Change the JSF dependency for trunk to be MyFaces 2.1 4. Change the trinidad plugins trunk to be 2.1.0 for consistency. 5. Change both branches/trinidad-2.0.x and trunk to use the new trinidad plugins snapshot. I'm hoping everyone will agree to this so that we can fix some of the blocker issues we've had show up after the the last Trinidad release. Many of which seem to be JSF 2.1 related. Please respond to this email with a +1 or a -1 and don't forget to include any any reasons why you do not wish to support the move. Thanks, Scott
[jira] [Commented] (TRINIDAD-2141) add a new 'browser-generic' agent
[ https://issues.apache.org/jira/browse/TRINIDAD-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13119549#comment-13119549 ] Jeanne Waldman commented on TRINIDAD-2141: -- For now, if you would like to create a genericDesktop agent, you can simply call new AgentImpl() and set the intended values for platform/agentType/version etc. There is no request param to create the genericDesktop agent. add a new 'browser-generic' agent -- Key: TRINIDAD-2141 URL: https://issues.apache.org/jira/browse/TRINIDAD-2141 Project: MyFaces Trinidad Issue Type: Improvement Components: Infrastructure Affects Versions: 1.2.15-core , 2.0.1-core Reporter: Pavitra Subramaniam Attachments: JIRA2141 - 09282011.patch, JIRA2141 - 10032011.patch, JIRA2141.patch It would be very useful to have an agent called - 'browser-generic', which represents the lowest common denominator agent for all browsers. We also would want this to have its own capabilities that any generic browser agent supports today. This agent would be very useful in usecases where the user agent cannot be determined at the time of rendering. For example when rendering content for a page to be used as a file attachment in an email, this could be very useful. CSS rules with @agent keyword would be ignored. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2141) add a new 'browser-generic' agent
[ https://issues.apache.org/jira/browse/TRINIDAD-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13116655#comment-13116655 ] Jeanne Waldman commented on TRINIDAD-2141: -- +1 for genericDesktop add a new 'browser-generic' agent -- Key: TRINIDAD-2141 URL: https://issues.apache.org/jira/browse/TRINIDAD-2141 Project: MyFaces Trinidad Issue Type: Improvement Components: Infrastructure Affects Versions: 1.2.15-core , 2.0.1-core Reporter: Pavitra Subramaniam Attachments: JIRA2141.patch It would be very useful to have an agent called - 'browser-generic', which represents the lowest common denominator agent for all browsers. We also would want this to have its own capabilities that any generic browser agent supports today. This agent would be very useful in usecases where the user agent cannot be determined at the time of rendering. For example when rendering content for a page to be used as a file attachment in an email, this could be very useful. CSS rules with @agent keyword would be ignored. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Trinidad] File upload issue
Hi Jason,
Did you create a JIRA issue for this yet along with your use case?
Thanks,
Jeanne
Jason Lee wrote, On 8/23/2011 8:42 AM PT:
I have been trying to get tr:inputFile to work, but I keep getting
EOFExceptions. I traced it down to MultipartFormHandler._skipBoundary(). The
first issue is the EOFException, as noted in the comment, is a horribly
misleading exception. :) The reason the exception was thrown, though, seems to
be a problem with the boundary handling.
In _parseBoundary(), contentType might be passed something like multipart/form-data;
boundary=---135858097916243791492128236579;charset=UTF-8. However, when _skipBoundary() is
called, _readLine() returns -135858097916243791492128236579. Note that the first
string has ;charset=UTF-8 at the end, while the second does not. It seems that ExternalContext.getContentType()
appends that for reason (I'm posting from a Facelets page with the encoding set to UTF-8 (?xml version='1.0'
encoding='UTF-8' ?), so that might be the case.
At any rate, I made the following changes that seems to allow the uploads to
work as expected (as well as throwing what seems to me be a more reasonable
Exception, though it could use i18n help).
Is there a chance we could get this change reviewed and committed? Or perhaps a
better explanation of/fix for what we're seeing?
Thanks! :)
Index:
trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/share/util/MultipartFormHandler.java
===
---
trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/share/util/MultipartFormHandler.java
(revision 1160712)
+++
trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/share/util/MultipartFormHandler.java
(working copy)
@@ -225,7 +225,7 @@
if (!line.startsWith(_boundary))
{
// A better exception would be nice.
- throw new EOFException();
+ throw new IllegalStateException(Boundary information not found. Unable to
process upload.);
}
}
@@ -388,9 +388,14 @@
{
return null;
}
+String boundary = contentType.substring(boundaryStart +
_BOUNDARY_PARAMETER.length());
+final int semicolonIndex = boundary.indexOf(;);
+if (semicolonIndex -1) {
+boundary = boundary.substring(0, semicolonIndex);
+}
// Boundary always starts with --
-return -- + contentType.substring(boundaryStart +
_BOUNDARY_PARAMETER.length());
+return -- + boundary;
}
//Reads the ContentType string out of a line of the incoming request
[jira] [Commented] (TRINIDAD-1988) do not show the entire stack when the trinidad-skin's stylesheet file cannot be found
[ https://issues.apache.org/jira/browse/TRINIDAD-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13052776#comment-13052776 ] Jeanne Waldman commented on TRINIDAD-1988: -- also checked in to the 1.2.12.6.0-branch in revision 1137848. do not show the entire stack when the trinidad-skin's stylesheet file cannot be found - Key: TRINIDAD-1988 URL: https://issues.apache.org/jira/browse/TRINIDAD-1988 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Jeanne Waldman Assignee: Jeanne Waldman Fix For: 2.0.0-beta-1 When the skinning framework uses a skin with a stylesheet-name that cannot be found, it writes out a SEVERE error and shows the entire stack. This should be changed to write out a warning, and do not show the FileNotFoundException/stack. It's annoying to the user to see the stack when the error is really a warning, and the code didn't blow up. Feb 15, 2010 10:31:56 AM org.apache.myfaces.trinidadinternal.skin.StyleSheetEnt ry SEVERE: java.io.FileNotFoundException: Unable to locate style sheet css/IDM.css in lo cal styles directory (/scratch/abc/view_storage/abcnewhost/xyz/xyz-p roduct/consoles/rolemgmt/idX_RoleManagment/RoleMgmtUI/public_html/WEB-INF/temp/ abc/styles), or on the class path. Please be sure that this style sheet is installed. at org.apache.myfaces.trinidadinternal.skin.StyleSheetNameResolver.getProvider (StyleSheetNameResolver.java:117) at org.apache.myfaces.trinidadinternal.share.io.CachingNameResolver.getProvide r(CachingNameResolver.java:97) at org.apache.myfaces.trinidadinternal.skin.SkinStyleSheetParserUtils.parseCSS Source(SkinStyleSheetParserUtils.java:91) at org.apache.myfaces.trinidadinternal.skin.StyleSheetEntry._createSkinStyleSh eetFromCSS(StyleSheetEntry.java:204) at org.apache.myfaces.trinidadinternal.skin.StyleSheetEntry._createSkinStyleSh eet(StyleSheetEntry.java:182) at org.apache.myfaces.trinidadinternal.skin.StyleSheetEntry.createEntry(StyleS heetEntry.java:70) at org.apache.myfaces.trinidadinternal.skin.SkinImpl._createStyleSheetDocument (SkinImpl.java:537) at org.apache.myfaces.trinidadinternal.skin.SkinImpl.getStyleSheetDocument(Ski nImpl.java:346) at org.apache.myfaces.trinidadinternal.skin.SkinExtension.getStyleSheetDocumen t(SkinExtension.java:527) at org.apache.myfaces.trinidadinternal.skin.SkinStyleProvider.createStyleSheet Document(SkinStyleProvider.java:158) at org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache._getSt yleSheetDocument(FileSystemStyleCache.java:638) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-1866) -tr-inhibit does not work with icon skinning selectors
[
https://issues.apache.org/jira/browse/TRINIDAD-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13025934#comment-13025934
]
Jeanne Waldman commented on TRINIDAD-1866:
--
I just tested -tr-inhibit with skin properties. This works now with skinning
properties, too.
Skin A:
af|breadCrumbs {
-tr-show-last-item: false;
Skin B extends Skin A:
af|breadCrumbs
{
-tr-inhibit: -tr-show-last-item;
}
I don't see the last item with Skin A, and I do see it with Skin B. If I remove
the SkinB's definition, then I don't see it since it inherits 'false' from Skin
A.
-tr-inhibit does not work with icon skinning selectors
--
Key: TRINIDAD-1866
URL: https://issues.apache.org/jira/browse/TRINIDAD-1866
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Skinning
Affects Versions: 2.0.0-alpha
Reporter: Jeanne Waldman
Assignee: Jeanne Waldman
Fix For: 2.0.0-beta-1
related to https://issues.apache.org/jira/browse/TRINIDAD-636 and
https://issues.apache.org/jira/browse/TRINIDAD-17
The -tr-inhibit feature does not work for Icon selectors. They do work for
style selectors.
Use case:
purpleSkin.css
af|selectOrderShuttle::reorder-up-icon {
content: url(/skins/purple/images/prev.png);
-tr-rule-ref: selector(.AFDefaultFont:alias);
border: 2px solid purple;
}
purpleBigFont.css (purpleBigFont skin extends purple skin)
af|selectOrderShuttle::reorder-up-icon {
content: url(/skins/purple/images/prev.png);
-tr-rule-ref: selector(.AFDefaultFont:alias);
-tr-inhibit: border;
}
Run the selectOrderShuttle.jspx page demo in purpleBigFont skin.
EXPECTED:
I expect to NOT see a border attribute around the reorder-up-icon.
ACTUAL:
I see a border around the reorder-up-icon because the -tr-inhibit:border does
not work for icons. They do work for style selectors.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2026) memory leak in skinstyleprovider
[ https://issues.apache.org/jira/browse/TRINIDAD-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020357#comment-13020357 ] Jeanne Waldman commented on TRINIDAD-2026: -- We voted via email and the consensus is: org.apache.myfaces.trinidad.skin.MAX_SKINS_CACHED memory leak in skinstyleprovider Key: TRINIDAD-2026 URL: https://issues.apache.org/jira/browse/TRINIDAD-2026 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Jeanne Waldman Attachments: LRUCache.patch There is no limit to the size of the providers cache in SkinStyleProvider.java. Every time we ask for a new skin, we add to the provider cache. A skin has StyleSheetDocument and StyleSheetDocument has StyleSheetNodes. If we remove a skin from the cache, we will need to clear out its _document, which in turn will clear out the StyleSheetNodes. StyleSheetNodes are the parsed representation of the skin css file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Trinidad][API] web.xml context-param for skin cache size
Here are some more options combined with the old top vote getters (1) MAX_CACHED_SKINS (2) MAX_SKINS_CACHED (3) MAX_SKINS_IN_CACHE (4) SKIN_MAX_CACHE_SIZE Still, my vote is Pavitra's take on Blake's, (2). It is the maximum number of skins that we cache, hence MAX_SKINS_CACHED Jeanne Pavitra Subramaniam wrote, On 4/13/2011 3:37 PM PT: On 4/13/2011 2:46 PM, Jeanne Waldman wrote: I like it too. It doesn't roll of the tongue, but I can't think of something simpler and better. You could try a slight variation "MAX_SKINS_CACHED". Prakash Udupa wrote, On 4/13/2011 2:36 PM PT: I think configurators are less likely to understand what a 'STYLE PROVIDER' means. So I like the simpler name Blake proposed 'org.apache.myfaces.trinidad.skin.MAX_CACHED_SKINS'. Thanks, Prakash On 4/13/2011 3:52 PM, Blake Sullivan wrote: On 4/13/11 1:13 PM, Jeanne Waldman wrote: Hi, For this issue, TRINIDAD-2026 memory leak in skinstyleprovider, I use a least-recently-used-map instead of a HashMap so I can limit the number of skins that I cache. This is useful if an application is built so that they have many skins, like if they have a skin per user, so that the numbe of cached skins doesn't keep growing and growing. I default to size 20, but this is also configurable via a web.xml context-parameter. Here are some proposed names: org.apache.myfaces.trinidad.skin.NUMBER_OF_SKINS_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_LRU_CACHE_SIZE in the patch it is org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE, so if I don't hear any objections, this is what I will use. Thanks, Jeanne How about org.apache.myfaces.trinidad.skin.MAX_CACHED_SKINS? SKIN_STYLE_PROVIDER_CACHE_SIZE is more specific and more technically correct, though. -- Blake Sullivan
[jira] [Commented] (TRINIDAD-1985) High live memory usage from SkinStyleProvider
[ https://issues.apache.org/jira/browse/TRINIDAD-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019442#comment-13019442 ] Jeanne Waldman commented on TRINIDAD-1985: -- The LRUCache.patch should be for the related issue TRINIDAD-2026 memory leak in skinstyleprovider. This occurs if one application uses a bunch of different skins. High live memory usage from SkinStyleProvider - Key: TRINIDAD-1985 URL: https://issues.apache.org/jira/browse/TRINIDAD-1985 Project: MyFaces Trinidad Issue Type: Bug Components: Archetype Affects Versions: 1.2.12-core Reporter: Stevan Malesevic Assignee: Jeanne Waldman Attachments: LRUCache.patch We were checking a live memory usage in one app and noticed that some 83MB of heap is pinned under SkinStyleProvider. This is under 14 instances of FileSystemStyleCache$Entry each with about 6MB of memory Heap shows these keys for styles LocaleVersion enMozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7 koMozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.11) Gecko/20100701 Firefox/3.5.11 ( .NET CLR 3.5.30729) enMozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.11) Gecko/20100701 Firefox/3.5.11 ( .NET CLR 3.5.30729) koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.18) Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729) koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.18) Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729) enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100315 Firefox/3.5.9 (.NET CLR 3.5.30729) koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100315 Firefox/3.5.9 (.NET CLR 3.5.30729) enMozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729) enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.15) Gecko/20101026 Firefox/3.5.15 ( .NET CLR 3.5.30729) enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 (.NET CLR 3.5.30729) koMozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2) enMozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2) enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729) enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.16) Gecko/20101130 Firefox/3.5.16 ( .NET CLR 3.5.30729) koMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.16) Gecko/20101130 Firefox/3.5.16 ( .NET CLR 3.5.30729) enMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 Now beside the amount of memory pinned by single FileSystemStyleCache$Entry the issue is that we apparently create too many different versions and there is no restriction to the size of cache leaving open door for memory leak Two questions 1. Do we really have different styles for FF on 3.5 or 3.6 or so? If not why do we key by it? 2. Given different browsers and locales having cache as plain concurrent hash map is actually a source of leak as over time it can accumulate more and more. Do we have any restriction there? Should the entries by LRU or have exparation -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2026) memory leak in skinstyleprovider
[ https://issues.apache.org/jira/browse/TRINIDAD-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019444#comment-13019444 ] Jeanne Waldman commented on TRINIDAD-2026: -- initial patch. Need to discuss the (1) default size and (2) the web.xml parameter name. Let's say one skin takes 1M of SkinStyleProvider. What should the default size (number of skins in the LRUCache) be? memory leak in skinstyleprovider Key: TRINIDAD-2026 URL: https://issues.apache.org/jira/browse/TRINIDAD-2026 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Jeanne Waldman Attachments: LRUCache.patch There is no limit to the size of the providers cache in SkinStyleProvider.java. Every time we ask for a new skin, we add to the provider cache. A skin has StyleSheetDocument and StyleSheetDocument has StyleSheetNodes. If we remove a skin from the cache, we will need to clear out its _document, which in turn will clear out the StyleSheetNodes. StyleSheetNodes are the parsed representation of the skin css file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2087) memory leak skinfactories hold on to skin which holds on to stylesheetnodes
memory leak skinfactories hold on to skin which holds on to stylesheetnodes --- Key: TRINIDAD-2087 URL: https://issues.apache.org/jira/browse/TRINIDAD-2087 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Reporter: Jeanne Waldman related to TRINIDAD-2026. SkinFactory#_FACTORIES is holding on to StyleSheetNodes. We register all skins with the SkinFactory. Once a skin has been requested by the user, we parse the stylesheet and store the stylesheetnodes with the skin. To see in the memory profiler tool, first set the LRUCache for SkinStyleProvider to 1. This will only keep around one SkinStyleProvider at a time. Run the rich client app (or trinidad's panelPageSkinDemo). Change the skin to about 6 different skins. Stop the memory profiler. You will see that even though we limit the SkinStyleProvider to 1, we still see StyleSheetNodes growing. See attached image showing the profiler results. Think about using SoftReferences to the Skin -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2026) memory leak in skinstyleprovider
[ https://issues.apache.org/jira/browse/TRINIDAD-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019448#comment-13019448 ] Jeanne Waldman commented on TRINIDAD-2026: -- This patch does not clear out _document off the Skin. SkinFactory#_FACTORIES is holding on to StyleSheetNodes. We register all skins with the SkinFactory. Once a skin has been requested by the user, we parse the stylesheet and store the stylesheetnodes with the skin. This is TRINIDAD-2087 memory leak in skinstyleprovider Key: TRINIDAD-2026 URL: https://issues.apache.org/jira/browse/TRINIDAD-2026 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Jeanne Waldman Attachments: LRUCache.patch There is no limit to the size of the providers cache in SkinStyleProvider.java. Every time we ask for a new skin, we add to the provider cache. A skin has StyleSheetDocument and StyleSheetDocument has StyleSheetNodes. If we remove a skin from the cache, we will need to clear out its _document, which in turn will clear out the StyleSheetNodes. StyleSheetNodes are the parsed representation of the skin css file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2026) memory leak in skinstyleprovider
[ https://issues.apache.org/jira/browse/TRINIDAD-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019526#comment-13019526 ] Jeanne Waldman commented on TRINIDAD-2026: -- I discussed this with our performance expert, and we decided to limit it to around 20M. A complex skin for many components (like adf faces's skins) will take about 1M per skin, so the default size will be 20. This leaves the decision for what should the web.xml parameter be called? ideas: org.apache.myfaces.trinidad.skin.NUMBER_OF_SKINS_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_LRU_CACHE_SIZE in the patch it is org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE memory leak in skinstyleprovider Key: TRINIDAD-2026 URL: https://issues.apache.org/jira/browse/TRINIDAD-2026 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Jeanne Waldman Attachments: LRUCache.patch There is no limit to the size of the providers cache in SkinStyleProvider.java. Every time we ask for a new skin, we add to the provider cache. A skin has StyleSheetDocument and StyleSheetDocument has StyleSheetNodes. If we remove a skin from the cache, we will need to clear out its _document, which in turn will clear out the StyleSheetNodes. StyleSheetNodes are the parsed representation of the skin css file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[Trinidad][API] web.xml context-param for skin cache size
Hi, For this issue, TRINIDAD-2026 memory leak in skinstyleprovider, I use a least-recently-used-map instead of a HashMap so I can limit the number of skins that I cache. This is useful if an application is built so that they have many skins, like if they have a skin per user, so that the numbe of cached skins doesn't keep growing and growing. I default to size 20, but this is also configurable via a web.xml context-parameter. Here are some proposed names: org.apache.myfaces.trinidad.skin.NUMBER_OF_SKINS_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_LRU_CACHE_SIZE in the patch it is org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE, so if I don't hear any objections, this is what I will use. Thanks, Jeanne
Re: [Trinidad][API] web.xml context-param for skin cache size
That's a good one, too. SKIN_STYLE_PROVIDER_CACHE_SIZE is specific, but then SkinStyleProvider (and StyleProvider for that matter) are in the impl package. Blake Sullivan wrote, On 4/13/2011 1:52 PM PT: On 4/13/11 1:13 PM, Jeanne Waldman wrote: Hi, For this issue, TRINIDAD-2026 memory leak in skinstyleprovider, I use a least-recently-used-map instead of a HashMap so I can limit the number of skins that I cache. This is useful if an application is built so that they have many skins, like if they have a skin per user, so that the numbe of cached skins doesn't keep growing and growing. I default to size 20, but this is also configurable via a web.xml context-parameter. Here are some proposed names: org.apache.myfaces.trinidad.skin.NUMBER_OF_SKINS_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_LRU_CACHE_SIZE in the patch it is org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE, so if I don't hear any objections, this is what I will use. Thanks, Jeanne How about org.apache.myfaces.trinidad.skin.MAX_CACHED_SKINS? SKIN_STYLE_PROVIDER_CACHE_SIZE is more specific and more technically correct, though. -- Blake Sullivan
Re: [Trinidad][API] web.xml context-param for skin cache size
I like it too. It doesn't roll of the tongue, but I can't think of something simpler and better. Prakash Udupa wrote, On 4/13/2011 2:36 PM PT: I think configurators are less likely to understand what a 'STYLE PROVIDER' means. So I like the simpler name Blake proposed 'org.apache.myfaces.trinidad.skin.MAX_CACHED_SKINS'. Thanks, Prakash On 4/13/2011 3:52 PM, Blake Sullivan wrote: On 4/13/11 1:13 PM, Jeanne Waldman wrote: Hi, For this issue, TRINIDAD-2026 memory leak in skinstyleprovider, I use a least-recently-used-map instead of a HashMap so I can limit the number of skins that I cache. This is useful if an application is built so that they have many skins, like if they have a skin per user, so that the numbe of cached skins doesn't keep growing and growing. I default to size 20, but this is also configurable via a web.xml context-parameter. Here are some proposed names: org.apache.myfaces.trinidad.skin.NUMBER_OF_SKINS_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_LRU_CACHE_SIZE in the patch it is org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE, so if I don't hear any objections, this is what I will use. Thanks, Jeanne How about org.apache.myfaces.trinidad.skin.MAX_CACHED_SKINS? SKIN_STYLE_PROVIDER_CACHE_SIZE is more specific and more technically correct, though. -- Blake Sullivan
[jira] [Resolved] (TRINIDAD-2085) absolute urls for icon selectors preprends context-root when it shouldn't
[
https://issues.apache.org/jira/browse/TRINIDAD-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeanne Waldman resolved TRINIDAD-2085.
--
Resolution: Fixed
Fix Version/s: 2.0.0-beta-3
Assignee: Jeanne Waldman
absolute urls for icon selectors preprends context-root when it shouldn't
-
Key: TRINIDAD-2085
URL: https://issues.apache.org/jira/browse/TRINIDAD-2085
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Reporter: Jeanne Waldman
Assignee: Jeanne Waldman
Fix For: 2.0.0-beta-3
Attachments: isAbsoluteURIPatch.patch
In the trinidad demo purple.css skin file, type an absolute url like
this one:
.AFErrorIcon:alias { content:
url('http://127.0.0.1:7101/trinidad-demo-context-root/faces/afr/skins/purple/images/info.png');
}
set trinidad-config.xml to use the purple skin
run af:icon demo
Type in 'error' for the type
Use firebug and hover on the Error text. You will see that the url has the
context-root prepended to it, when it shouldn't.
ACTUAL
img width=16 height=16 border=0 alt=Error title=Error
class=AFErrorIconStyle
src=/trinidad-demo-context-root/http://127.0.0.1:7101/trinidad-demo-context-root/faces/afr/skins/purple/images/info.png;
EXPECTED
img width=16 height=16 border=0 alt=Error title=Error
class=AFErrorIconStyle
src=http://127.0.0.1:7101/trinidadt-demo-context-root/faces/afr/skins/purple/images/info.png;
absolute urls work fine for background-images that are written to the css
file. This is strictly a Skinning Framework Icon issue. Possibly we are
creating the wrong type of Icon (ContextImageIcon instead of URIIIcon) when
we create Icons in StyleSheetDocument or SkinStyleSheetParserUtils.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2085) absolute urls for icon selectors preprends context-root when it shouldn't
absolute urls for icon selectors preprends context-root when it shouldn't
-
Key: TRINIDAD-2085
URL: https://issues.apache.org/jira/browse/TRINIDAD-2085
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Reporter: Jeanne Waldman
In the trinidad demo purple.css skin file, type an absolute url like
this one:
.AFErrorIcon:alias { content:
url('http://127.0.0.1:7101/trinidad-demo-context-root/faces/afr/skins/purple/images/info.png');
}
set trinidad-config.xml to use the purple skin
run af:icon demo
Type in 'error' for the type
Use firebug and hover on the Error text. You will see that the url has the
context-root prepended to it, when it shouldn't.
ACTUAL
img width=16 height=16 border=0 alt=Error title=Error
class=AFErrorIconStyle
src=/trinidad-demo-context-root/http://127.0.0.1:7101/trinidad-demo-context-root/faces/afr/skins/purple/images/info.png;
EXPECTED
img width=16 height=16 border=0 alt=Error title=Error
class=AFErrorIconStyle
src=http://127.0.0.1:7101/trinidadt-demo-context-root/faces/afr/skins/purple/images/info.png;
absolute urls work fine for background-images that are written to the css
file. This is strictly a Skinning Framework Icon issue. Possibly we are
creating the wrong type of Icon (ContextImageIcon instead of URIIIcon) when
we create Icons in StyleSheetDocument or SkinStyleSheetParserUtils.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2080) NullPointerException from skinning framework code (SkinUtils)
[
https://issues.apache.org/jira/browse/TRINIDAD-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeanne Waldman updated TRINIDAD-2080:
-
Resolution: Fixed
Fix Version/s: 2.0.0-beta-3
Status: Resolved (was: Patch Available)
NullPointerException from skinning framework code (SkinUtils)
-
Key: TRINIDAD-2080
URL: https://issues.apache.org/jira/browse/TRINIDAD-2080
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Affects Versions: 2.0.0-beta-2
Environment: n/a
Reporter: Prakash Udupa
Assignee: Jeanne Waldman
Fix For: 2.0.0-beta-3
Attachments: npe_JIRA-2080.patch
Original Estimate: 1h
Remaining Estimate: 1h
In our application, where we use Trinidad, we hit on the following
exception...
Mar 10, 2011 1:25:33 PM org.apache.myfaces.trinidad.webapp.TrinidadFilter
SEVERE:
java.lang.NullPointerException
at org.apache.myfaces.trinidadinternal.skin.SkinUtils._registerSkinExtensionsA
ndAdditions(SkinUtils.java:379)
at org.apache.myfaces.trinidadinternal.skin.SkinUtils.registerSkinExtensions(S
kinUtils.java:129)
at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.init(Glob
alConfiguratorImpl.java:406)
at oracle.adfinternal.view.faces.webapp.rich.RegistrationFilter.init(Registrat
ionFilter.java:53)
at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.init(Trinidad
FilterImpl.java:110)
at org.apache.myfaces.trinidad.webapp.TrinidadFilter.init(TrinidadFilter.java:
54)
The culprit code is here...
private static void _registerSkinExtensionsAndAdditions(
ExternalContext context,
SkinFactory skinFactory)
{
if (context == null)
return;
// Add META-INF/trinidad-skins.xml skins to skin factory. (sorted first
to make sure
// we register the most 'base' skins first)
if (_LOG.isFine()) _LOG.fine(Parse META-INF/trinidad-skins.xml files);
ListSkinsNode metaInfSkinsNodeList = _getMetaInfSkinsNodeList();
// Go through each SkinsNode object
// (contains List of SkinNodes and List of SkinAdditionNodes)
// and return a List of the SkinNodes.
ListSkinNode metaInfSkinNodes = new ArrayListSkinNode();
for (SkinsNode skinsNode : metaInfSkinsNodeList)
{
metaInfSkinNodes.addAll(skinsNode.getSkinNodes());
}
addAll (from its doc) assumes that supplied collection is non-null. The
supplier does not guarantee this, so we will need some defensive code here to
avoid the NPE.
Will provide a patch.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-1496) Need org.apache.myfaces.trinidad.skin.Icon to expose the raw content value instead of just getImageURI
[ https://issues.apache.org/jira/browse/TRINIDAD-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman updated TRINIDAD-1496: - Status: Patch Available (was: Open) Need org.apache.myfaces.trinidad.skin.Icon to expose the raw content value instead of just getImageURI -- Key: TRINIDAD-1496 URL: https://issues.apache.org/jira/browse/TRINIDAD-1496 Project: MyFaces Trinidad Issue Type: New Feature Components: Components Affects Versions: 1.2.11-core Reporter: Matt Cooper Priority: Minor In skinning, you can define image icons in 4 different ways: 1.) Absolute URLs specify the complete URL to the resource, including the protocol (e.g. http://). Example: content: url(http://incubator.apache.org/images/asf_logo_wide.gif); 2.) Relative URLs are used if the specified URL does not start with a slash (/) and if there's no protocol present. A relative URL is based on the skin's CSS file location. For instance, if the CSS is located in MyWebApp/skins/mySkin/ and the specified url is skinImages/myImage.gif, then the final URL will be /MyWebApp/skins/mySkin/skinImages/myImage.gif. Example: content: url(skin_images/ObjectIconError.gif); 3.) Context relative URLs are resolved relatively to the context root of the web application. To use them, you simply have to make it start with a single slash (/). For instance, if the context root is /MyWebApp and the specified URL is /images/myImage.jpeg, the resulting URL will be /MyWebApp/images/myImage.jpeg. Example: content: url(/skins/mySkin/skin_images/ObjectIconError.gif); 4.) Server relative URLs are resolved relatively to the web server as opposed to the context root. This allow to easily refer to resources located on another application on the same server. To use this type of URL, the specified URL must starts with two slashes (//). Example: content: url(//MyOtherWebApp/images/myCalendar.gif); The org.apache.myfaces.trinidad.skin.Icon class currently provides a getImageURI() method. This method returns a value that has the context path built-in. If a component exposes an icon attribute (there are a handful in Apache MyFaces Trinidad and also in another framework that has components built upon Trinidad), that icon String supports these same alternative mechanisms for referring to the icon image. Let's say you have a component that you want to keep abstract but might want it to reuse existing components (e.g. a rich text editor with a toolbar containing buttons that you want to reuse an existing toolbar button component so you can have consistency in button styling). For that publicly-exposed component, you will want to allow people to customize in skinning what the icons are for its toolbar. These icons must be defined in that publicly-exposed component but then converted into a String that can be passed into the toolbar button component. With the current Icon.getImageURI(), if a user skinned the icon image using some of the 4 above paths, either the icon would have 2 context paths added to it (one from the skin framework and one from the toolbar button resource encoding) or it would have a context path when it should not be including the local context path (image definition option #4). For the public component's renderer to support all 4 of these image definition options, the org.apache.myfaces.trinidad.skin.Icon needs to expose some mechanism to either let it have access to the raw content value so that raw value can be passed along to the button or at least some kind of mechanism to let the public component's renderer know that it is not safe to let the button add its own copy of the context path (e.g. add another leading / to the result). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-1496) Need org.apache.myfaces.trinidad.skin.Icon to expose the raw content value instead of just getImageURI
[ https://issues.apache.org/jira/browse/TRINIDAD-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13016643#comment-13016643 ] Jeanne Waldman commented on TRINIDAD-1496: -- This is not as simple as I first thought because the Icon object is built with pre-processed URIs ready to be output to the css or html. They do not have the raw uris, and the raw uris cannot be determined from the regular uris, since for css relative urls, we would need to know where the css file was. We parse each css files in SkinStyleSheetParserUtils. here we configure the url. Then in StyleSheetDocument, when we do all the property merging, we create the Icon objects. At this point the css file information is long gone. We do not even know all the skins that were merged together to form this one StyleSheetDocument. I've attached a patch for an idea for a fix. That is to pass in a dummy property into the IconNodes (raw-url), then in StyleSheetDocument we can read this, and use it to create the Icon. The Icon constructors will have to change. Also note, that we will have to check the code carefully for right-to-left icons. I did not in this patch. It's simply an idea. Need org.apache.myfaces.trinidad.skin.Icon to expose the raw content value instead of just getImageURI -- Key: TRINIDAD-1496 URL: https://issues.apache.org/jira/browse/TRINIDAD-1496 Project: MyFaces Trinidad Issue Type: New Feature Components: Components Affects Versions: 1.2.11-core Reporter: Matt Cooper Priority: Minor In skinning, you can define image icons in 4 different ways: 1.) Absolute URLs specify the complete URL to the resource, including the protocol (e.g. http://). Example: content: url(http://incubator.apache.org/images/asf_logo_wide.gif); 2.) Relative URLs are used if the specified URL does not start with a slash (/) and if there's no protocol present. A relative URL is based on the skin's CSS file location. For instance, if the CSS is located in MyWebApp/skins/mySkin/ and the specified url is skinImages/myImage.gif, then the final URL will be /MyWebApp/skins/mySkin/skinImages/myImage.gif. Example: content: url(skin_images/ObjectIconError.gif); 3.) Context relative URLs are resolved relatively to the context root of the web application. To use them, you simply have to make it start with a single slash (/). For instance, if the context root is /MyWebApp and the specified URL is /images/myImage.jpeg, the resulting URL will be /MyWebApp/images/myImage.jpeg. Example: content: url(/skins/mySkin/skin_images/ObjectIconError.gif); 4.) Server relative URLs are resolved relatively to the web server as opposed to the context root. This allow to easily refer to resources located on another application on the same server. To use this type of URL, the specified URL must starts with two slashes (//). Example: content: url(//MyOtherWebApp/images/myCalendar.gif); The org.apache.myfaces.trinidad.skin.Icon class currently provides a getImageURI() method. This method returns a value that has the context path built-in. If a component exposes an icon attribute (there are a handful in Apache MyFaces Trinidad and also in another framework that has components built upon Trinidad), that icon String supports these same alternative mechanisms for referring to the icon image. Let's say you have a component that you want to keep abstract but might want it to reuse existing components (e.g. a rich text editor with a toolbar containing buttons that you want to reuse an existing toolbar button component so you can have consistency in button styling). For that publicly-exposed component, you will want to allow people to customize in skinning what the icons are for its toolbar. These icons must be defined in that publicly-exposed component but then converted into a String that can be passed into the toolbar button component. With the current Icon.getImageURI(), if a user skinned the icon image using some of the 4 above paths, either the icon would have 2 context paths added to it (one from the skin framework and one from the toolbar button resource encoding) or it would have a context path when it should not be including the local context path (image definition option #4). For the public component's renderer to support all 4 of these image definition options, the org.apache.myfaces.trinidad.skin.Icon needs to expose some mechanism to either let it have access to the raw content value so that raw value can be passed along to the button or at least some kind of mechanism to let the public component's renderer know that it is not safe to let the button add its own copy of the context path (e.g. add another
[jira] [Commented] (TRINIDAD-1496) Need org.apache.myfaces.trinidad.skin.Icon to expose the raw content value instead of just getImageURI
[
https://issues.apache.org/jira/browse/TRINIDAD-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13015629#comment-13015629
]
Jeanne Waldman commented on TRINIDAD-1496:
--
We have a specific example. Our panelCollection component has a
af|panelCollection::freeze-icon selector. If the user types in
af|panelCollection::freeze-icon {content: url(//afr/freeze_ena.png);}, then
this means 'server-relative url'. If the user types in {content:
url(//afr/freeze_ena.png);},, then this means a 'context-relative url.
The renderer code calls
String skinIcon = String.valueOf(icon.getImageURI(context, rc));
getImageURI returns the uri that is meant to be written out directly into the
html page or css file. It already has prepended the context, if it is a
context-relative url, or it has already stripped the first '/' if it is
server-relative url.
In this case, the renderer wants to build up a toolbar button component, and
call toolbarbutton.setIcon(). setIcon requires a URL in the same format as the
af|panelCollection::freeze-icon content URL. Not the processed url ready for
output.
The code does some kludgy things to get around this. Ideally, the code would
call icon.getRawURI(context, rc), and it can directly pass this result to
toolbarButton.setIcon().
What do people think?
Need org.apache.myfaces.trinidad.skin.Icon to expose the raw content value
instead of just getImageURI
--
Key: TRINIDAD-1496
URL: https://issues.apache.org/jira/browse/TRINIDAD-1496
Project: MyFaces Trinidad
Issue Type: New Feature
Components: Components
Affects Versions: 1.2.11-core
Reporter: Matt Cooper
Priority: Minor
In skinning, you can define image icons in 4 different ways:
1.) Absolute URLs specify the complete URL to the resource, including the
protocol (e.g. http://). Example:
content: url(http://incubator.apache.org/images/asf_logo_wide.gif);
2.) Relative URLs are used if the specified URL does not start with a slash
(/) and if there's no protocol present. A relative URL is based on the
skin's CSS file location. For instance, if the CSS is located in
MyWebApp/skins/mySkin/ and the specified url is skinImages/myImage.gif, then
the final URL will be /MyWebApp/skins/mySkin/skinImages/myImage.gif. Example:
content: url(skin_images/ObjectIconError.gif);
3.) Context relative URLs are resolved relatively to the context root of the
web application. To use them, you simply have to make it start with a single
slash (/). For instance, if the context root is /MyWebApp and the specified
URL is /images/myImage.jpeg, the resulting URL will be
/MyWebApp/images/myImage.jpeg. Example:
content: url(/skins/mySkin/skin_images/ObjectIconError.gif);
4.) Server relative URLs are resolved relatively to the web server as opposed
to the context root. This allow to easily refer to resources located on
another application on the same server. To use this type of URL, the
specified URL must starts with two slashes (//). Example:
content: url(//MyOtherWebApp/images/myCalendar.gif);
The org.apache.myfaces.trinidad.skin.Icon class currently provides a
getImageURI() method. This method returns a value that has the context path
built-in. If a component exposes an icon attribute (there are a handful in
Apache MyFaces Trinidad and also in another framework that has components
built upon Trinidad), that icon String supports these same alternative
mechanisms for referring to the icon image. Let's say you have a component
that you want to keep abstract but might want it to reuse existing components
(e.g. a rich text editor with a toolbar containing buttons that you want to
reuse an existing toolbar button component so you can have consistency in
button styling). For that publicly-exposed component, you will want to allow
people to customize in skinning what the icons are for its toolbar. These
icons must be defined in that publicly-exposed component but then converted
into a String that can be passed into the toolbar button component. With the
current Icon.getImageURI(), if a user skinned the icon image using some of
the 4 above paths, either the icon would have 2 context paths added to it
(one from the skin framework and one from the toolbar button resource
encoding) or it would have a context path when it should not be including the
local context path (image definition option #4). For the public component's
renderer to support all 4 of these image definition options, the
org.apache.myfaces.trinidad.skin.Icon needs to expose some mechanism to
either let it have access to the raw content value so that raw value can be
passed along to the button or at least some kind of mechanism
[jira] [Commented] (TRINIDAD-1496) Need org.apache.myfaces.trinidad.skin.Icon to expose the raw content value instead of just getImageURI
[ https://issues.apache.org/jira/browse/TRINIDAD-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13015635#comment-13015635 ] Jeanne Waldman commented on TRINIDAD-1496: -- Make sure to document that css-relative URIs make no sense for 'icon' selectors. Need org.apache.myfaces.trinidad.skin.Icon to expose the raw content value instead of just getImageURI -- Key: TRINIDAD-1496 URL: https://issues.apache.org/jira/browse/TRINIDAD-1496 Project: MyFaces Trinidad Issue Type: New Feature Components: Components Affects Versions: 1.2.11-core Reporter: Matt Cooper Priority: Minor In skinning, you can define image icons in 4 different ways: 1.) Absolute URLs specify the complete URL to the resource, including the protocol (e.g. http://). Example: content: url(http://incubator.apache.org/images/asf_logo_wide.gif); 2.) Relative URLs are used if the specified URL does not start with a slash (/) and if there's no protocol present. A relative URL is based on the skin's CSS file location. For instance, if the CSS is located in MyWebApp/skins/mySkin/ and the specified url is skinImages/myImage.gif, then the final URL will be /MyWebApp/skins/mySkin/skinImages/myImage.gif. Example: content: url(skin_images/ObjectIconError.gif); 3.) Context relative URLs are resolved relatively to the context root of the web application. To use them, you simply have to make it start with a single slash (/). For instance, if the context root is /MyWebApp and the specified URL is /images/myImage.jpeg, the resulting URL will be /MyWebApp/images/myImage.jpeg. Example: content: url(/skins/mySkin/skin_images/ObjectIconError.gif); 4.) Server relative URLs are resolved relatively to the web server as opposed to the context root. This allow to easily refer to resources located on another application on the same server. To use this type of URL, the specified URL must starts with two slashes (//). Example: content: url(//MyOtherWebApp/images/myCalendar.gif); The org.apache.myfaces.trinidad.skin.Icon class currently provides a getImageURI() method. This method returns a value that has the context path built-in. If a component exposes an icon attribute (there are a handful in Apache MyFaces Trinidad and also in another framework that has components built upon Trinidad), that icon String supports these same alternative mechanisms for referring to the icon image. Let's say you have a component that you want to keep abstract but might want it to reuse existing components (e.g. a rich text editor with a toolbar containing buttons that you want to reuse an existing toolbar button component so you can have consistency in button styling). For that publicly-exposed component, you will want to allow people to customize in skinning what the icons are for its toolbar. These icons must be defined in that publicly-exposed component but then converted into a String that can be passed into the toolbar button component. With the current Icon.getImageURI(), if a user skinned the icon image using some of the 4 above paths, either the icon would have 2 context paths added to it (one from the skin framework and one from the toolbar button resource encoding) or it would have a context path when it should not be including the local context path (image definition option #4). For the public component's renderer to support all 4 of these image definition options, the org.apache.myfaces.trinidad.skin.Icon needs to expose some mechanism to either let it have access to the raw content value so that raw value can be passed along to the button or at least some kind of mechanism to let the public component's renderer know that it is not safe to let the button add its own copy of the context path (e.g. add another leading / to the result). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2055) Introduce ChangeManager wrapper class
[ https://issues.apache.org/jira/browse/TRINIDAD-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011648#comment-13011648 ] Jeanne Waldman commented on TRINIDAD-2055: -- Answer from Andy to Prakash's question -- Let's take a closer look at the use case that I am hoping to address... I want to write a ChangeManager implementation that: 1. Delegates all of the real work to some other ChangeManager. 2. Examines ComponentChanges as they are added and drops certain changes that I do not want to save. I can do this today by writing my own wrapper class that extends ChangeManager directly and provides delegating implementations of all of the ChangeManager methods. However, if we later add some new method to the ChangeManager contract (as we did with applySimpleComponentChanges()), my wrapper class would need to be updated - ie. I would need to add yet another delegating method implementation for the new API. This is annoying and fragile. On the other hand, if we introduce a base wrapper class in Trinidad, my concrete wrapper subclass is not impacted by new additions to the ChangeManager API. Any time we add a new method to the ChangeManager, we would add an equivalent implementation to the ChangeManagerWrapper base class. In addition to reducing the amount of work to implement a ChangeManager wrapper class (no longer need to re-implement every ChangeManager method), we have significantly reduced the risk of breaking such classes as the API evolves. FWIW, this approach of providing a base wrapper class is a very common pattern. (As Pavitra hinted at this, is used all over the place in JSF.) Andy Introduce ChangeManager wrapper class - Key: TRINIDAD-2055 URL: https://issues.apache.org/jira/browse/TRINIDAD-2055 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.0-beta-2 Reporter: Andy Schwartz Assignee: Andy Schwartz Priority: Minor Fix For: 2.0.0-beta-3 Attachments: ChangeManagerWrapper.java One way that users might customize change management behavior is to create a proxy ChangeManager that delegates through to an underlying ChangeManager (eg. to SessionChangeManager) for most operations after performing filtering of the incoming changes. It is possible to implement such proxy ChangeManager classes today. However, without a wrapper base class, these implementations are fragile - ie. they will break if we ever introduce a new method to the ChangeManager API. A more robust solution would be to introduce a base wrapper class for proxy ChangeManager implementations to extend. That way, in the event that we do introduce new ChangeManager methods, the base wrapper class can be updated in parallel, protecting subclasses from the change. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2066) do not cache url connections for trinidad-skins.xml or for skinning's css files in design time mode
do not cache url connections for trinidad-skins.xml or for skinning's css files
in design time mode
---
Key: TRINIDAD-2066
URL: https://issues.apache.org/jira/browse/TRINIDAD-2066
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Skinning
Reporter: Jeanne Waldman
Assignee: Jeanne Waldman
Our skinning editor deploys a jar with the user's custom skin. The user adds
this jar to the classpath, and the user views the page in design time mode. The
user goes back to the skinning editor, changes the custom skin, redeploys the
jar, but does not see the changes in the design time mode without restarting
the server.
The fix is to call setUseCaches(false) when in design time mode:
// prevent caching during DT where the source may change...
if (Beans.isDesignTime())
{
connection.setUseCaches(false);
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TRINIDAD-2066) do not cache url connections for trinidad-skins.xml or for skinning's css files in design time mode
[
https://issues.apache.org/jira/browse/TRINIDAD-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeanne Waldman resolved TRINIDAD-2066.
--
Resolution: Fixed
Fix Version/s: 2.0.0-beta-3
do not cache url connections for trinidad-skins.xml or for skinning's css
files in design time mode
---
Key: TRINIDAD-2066
URL: https://issues.apache.org/jira/browse/TRINIDAD-2066
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Skinning
Reporter: Jeanne Waldman
Assignee: Jeanne Waldman
Fix For: 2.0.0-beta-3
Our skinning editor deploys a jar with the user's custom skin. The user adds
this jar to the classpath, and the user views the page in design time mode.
The user goes back to the skinning editor, changes the custom skin, redeploys
the jar, but does not see the changes in the design time mode without
restarting the server.
The fix is to call setUseCaches(false) when in design time mode:
// prevent caching during DT where the source may change...
if (Beans.isDesignTime())
{
connection.setUseCaches(false);
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2063) generated css file includes selectors with {}
generated css file includes selectors with {}
-
Key: TRINIDAD-2063
URL: https://issues.apache.org/jira/browse/TRINIDAD-2063
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Affects Versions: 2.0.0-beta-2
Reporter: Jeanne Waldman
Assignee: Jeanne Waldman
If a selector has skinning properties only, like af|foo {-tr-some-property:
true}, then this gets placed into the css file like
af|foo {}.
And if it is compact mode, it will get into the css file like:
. {} It won't have a compressed value, like .x10, because it is considered
empty and the skinning framework does not give a compressed value to empty keys.
If you have a css file with a lot of selectors that have only skin-properties,
then your generated css file could look like:
., ., ., ., ., ., ., ., ., {}
--
The fix is in CSSGenerationUtils.java do not output selectors with an empty
property string.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TRINIDAD-2063) generated css file includes selectors with {}
[
https://issues.apache.org/jira/browse/TRINIDAD-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeanne Waldman resolved TRINIDAD-2063.
--
Resolution: Fixed
Fix Version/s: 2.0.0-beta-3
generated css file includes selectors with {}
-
Key: TRINIDAD-2063
URL: https://issues.apache.org/jira/browse/TRINIDAD-2063
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Affects Versions: 2.0.0-beta-2
Reporter: Jeanne Waldman
Assignee: Jeanne Waldman
Fix For: 2.0.0-beta-3
If a selector has skinning properties only, like af|foo {-tr-some-property:
true}, then this gets placed into the css file like
af|foo {}.
And if it is compact mode, it will get into the css file like:
. {} It won't have a compressed value, like .x10, because it is considered
empty and the skinning framework does not give a compressed value to empty
keys.
If you have a css file with a lot of selectors that have only
skin-properties, then your generated css file could look like:
., ., ., ., ., ., ., ., ., {}
--
The fix is in CSSGenerationUtils.java do not output selectors with an empty
property string.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2050) NO GOOD DIAGNOSTIC MESSAGE FROM SKINNING FRAMEWORK FOR CASE OF BLANK TRINIDAD-SKINS.XML
[ https://issues.apache.org/jira/browse/TRINIDAD-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004301#comment-13004301 ] Jeanne Waldman commented on TRINIDAD-2050: -- ok. this looks good. I will commit. NO GOOD DIAGNOSTIC MESSAGE FROM SKINNING FRAMEWORK FOR CASE OF BLANK TRINIDAD-SKINS.XML --- Key: TRINIDAD-2050 URL: https://issues.apache.org/jira/browse/TRINIDAD-2050 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.0.0-beta-3 Reporter: Prakash Udupa Assignee: Jeanne Waldman Attachments: JIRA_2050_empty_skin_config_issue.patch Original Estimate: 24h Remaining Estimate: 24h There is possibility of a trinidad-skin.xml in the class path being without any content, mostly due to packaging errrors. In this circumstance, the XML parser callback and error handler implementations in Trinidad just logs the entire stack trace of the SAXException, with no indication of the xml file that fails, this makes it hard to diagnose given that there could be multiple config files that get merged. We need a more informative log message, even better if the message contained the complete path to the specific trinidad-skins.xml file that has the issue. Here is a sample exception logged that does not provide much useful information: - TreeBuilder$Handler _logError Parsing error, line 1, column 1: org.xml.sax.SAXParseException: Premature end of file. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:174) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:388) at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1414) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:1059) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) at weblogic.xml.jaxp.WebLogicXMLReader.parse(WebLogicXMLReader.java:133) at weblogic.xml.jaxp.RegistryXMLReader.parse(RegistryXMLReader.java:173) at org.apache.myfaces.trinidadinternal.share.xml.TreeBuilder.parse(TreeBuilder.java:169) at org.apache.myfaces.trinidadinternal.share.xml.TreeBuilder.parse(TreeBuilder.java:120) at org.apache.myfaces.trinidadinternal.skin.SkinUtils._getSkinsNodeFromInputStream(SkinUtils.java:256) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2050) NO GOOD DIAGNOSTIC MESSAGE FROM SKINNING FRAMEWORK FOR CASE OF BLANK TRINIDAD-SKINS.XML
[ https://issues.apache.org/jira/browse/TRINIDAD-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003496#comment-13003496 ] Jeanne Waldman commented on TRINIDAD-2050: -- Prakash, Why did you change line 995 from _META_INF_CONFIG_FILE to url.toString()? It doesn't seem necessary as part of the blank trinidad-skins.xml issue. Was it simply code cleanup? If so, can you please comment? NO GOOD DIAGNOSTIC MESSAGE FROM SKINNING FRAMEWORK FOR CASE OF BLANK TRINIDAD-SKINS.XML --- Key: TRINIDAD-2050 URL: https://issues.apache.org/jira/browse/TRINIDAD-2050 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.0.0-beta-3 Reporter: Prakash Udupa Assignee: Jeanne Waldman Attachments: JIRA_2050_empty_skin_config_issue.patch Original Estimate: 24h Remaining Estimate: 24h There is possibility of a trinidad-skin.xml in the class path being without any content, mostly due to packaging errrors. In this circumstance, the XML parser callback and error handler implementations in Trinidad just logs the entire stack trace of the SAXException, with no indication of the xml file that fails, this makes it hard to diagnose given that there could be multiple config files that get merged. We need a more informative log message, even better if the message contained the complete path to the specific trinidad-skins.xml file that has the issue. Here is a sample exception logged that does not provide much useful information: - TreeBuilder$Handler _logError Parsing error, line 1, column 1: org.xml.sax.SAXParseException: Premature end of file. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:174) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:388) at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1414) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:1059) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) at weblogic.xml.jaxp.WebLogicXMLReader.parse(WebLogicXMLReader.java:133) at weblogic.xml.jaxp.RegistryXMLReader.parse(RegistryXMLReader.java:173) at org.apache.myfaces.trinidadinternal.share.xml.TreeBuilder.parse(TreeBuilder.java:169) at org.apache.myfaces.trinidadinternal.share.xml.TreeBuilder.parse(TreeBuilder.java:120) at org.apache.myfaces.trinidadinternal.skin.SkinUtils._getSkinsNodeFromInputStream(SkinUtils.java:256) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TRINIDAD-2025) move _styleNodeToStyleMap to FileSystemStyleCache to take advantage of same entires on the higher, browser or version or platform layer
[ https://issues.apache.org/jira/browse/TRINIDAD-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman updated TRINIDAD-2025: - Resolution: Fixed Fix Version/s: 2.0.0-beta-2 Status: Resolved (was: Patch Available) move _styleNodeToStyleMap to FileSystemStyleCache to take advantage of same entires on the higher, browser or version or platform layer --- Key: TRINIDAD-2025 URL: https://issues.apache.org/jira/browse/TRINIDAD-2025 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Affects Versions: 2.0.0-beta-1 Reporter: Jeanne Waldman Assignee: Jeanne Waldman Fix For: 2.0.0-beta-2 Attachments: UnmodifiableStyleAndSelectorMemoryFixes.patch We still have too many CSSStyle objects after we implemented #1 and #2 from TRINIDAD-1782. Implement #3 from TRINIDAD-1782 to reduce the number of Style objects. That is, move the _styleNodeToStyleMap out of StylesImpl up to FileSystemStyleCache. In our Rich Client app, one FileSystemStyleCache$StylesImpl was using around 2.5M. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TRINIDAD-2032) perf: save memory by sharing selector objects in filesystemstylecache
[ https://issues.apache.org/jira/browse/TRINIDAD-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman resolved TRINIDAD-2032. -- Resolution: Fixed Fix Version/s: 2.0.0-beta-2 perf: save memory by sharing selector objects in filesystemstylecache - Key: TRINIDAD-2032 URL: https://issues.apache.org/jira/browse/TRINIDAD-2032 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Reporter: Jeanne Waldman Assignee: Jeanne Waldman Fix For: 2.0.0-beta-2 We can save memory if we store Selectors in a Selector, Selector map at the FileSystemStyleCache level, and reuse where we can. The implementation will be similar to what we did in TRINIDAD-2025 where we reused Style objects. Selector objects are only 16 bytes each, but each FileSystemStyleCache$StylesImpl instance creates about 4500 of them for our complicated skin. Before Selector sharing: FSSC$Entry about 335K each of retained size. FSSC$StylesImpl about 214K each of retained size run a page in 3 diff browsers, and we have 13402 Selector objects, total 214K retained size After Selector sharing: FSSC$Entry about 263K each of retained size. FSSC$StylesImpl about 142K each of retained size run a page in 3 diff browsers, and we have 4533 Selector objects using 72.5K Retained Size -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TRINIDAD-1729) provide a hook for for an external decorator of Skin InputStreamProvider
[ https://issues.apache.org/jira/browse/TRINIDAD-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman resolved TRINIDAD-1729. -- Resolution: Fixed Fix Version/s: 2.0.0-beta-1 provide a hook for for an external decorator of Skin InputStreamProvider Key: TRINIDAD-1729 URL: https://issues.apache.org/jira/browse/TRINIDAD-1729 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Reporter: Jeanne Waldman Assignee: Jeanne Waldman Fix For: 1.2.15-core , 2.0.0-beta-1 Attachments: MDSNameResolver.jar, NameResolverPatch1212.patch, patch1.2.12.3ForJIRA1729 A third party (Oracle MDS) would like to use their own InputStreamProvider to find skinning css files (like purple-desktop.css) in their own system. The current ways to find css files do not work for them. 1. We first discussed decorating ExternalContext.getResource(), since in Trinidad we create the URL by calling FacesContext's ExternalContext's getResource(style-sheet-name). For an example, see http://insights2jsf.wordpress.com/2009/07/03/using-custom-factories-or-howto-wrap-facescontext/ 2. This won't work for them because it returns an URL object 3. using ExternalContext's getResourceAsStream won't work because you can't find out if the file has been modified. 4. What would work is if they decorate or extend the InputStreamProvider, and we check this if none of the other means finds the .css file. The other means are those found in SkinStyleSheetProvider.java 5. To allow them to plugin their InputStreamProvider we can do this with a service provider interface where we open up META-INF/services/fully qualified classname of service and load all of the services that way. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TRINIDAD-1775) for design time support, provide a request parameter to set skin to dirty
[ https://issues.apache.org/jira/browse/TRINIDAD-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman resolved TRINIDAD-1775. -- Resolution: Fixed Fix Version/s: 2.0.0-beta-1 for design time support, provide a request parameter to set skin to dirty - Key: TRINIDAD-1775 URL: https://issues.apache.org/jira/browse/TRINIDAD-1775 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Reporter: Jeanne Waldman Assignee: Jeanne Waldman Fix For: 2.0.0-beta-1 This is a spin-off of TRINIDAD-1714 Mark the skin as dirty if DesignTime mode and org.apache.myfaces.trinidad.skin.id is set. This proved to be too slow for the Design Time since they were setting skin.id on every render, and therefore setting the skin to be dirty on every render, and this caused the skin to be reparsed/regenered . They instead want to have a separate flag to set the skin to be dirty. Then the skin.id flag will only be used to pick the skin, not also set the skin to be dirty. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TRINIDAD-928) Skinning developer guide needs to be update about how to put a skin into a JAR file
[ https://issues.apache.org/jira/browse/TRINIDAD-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman resolved TRINIDAD-928. - Resolution: Duplicate Assignee: Jeanne Waldman duplicate of TRINIDAD-1875. This has been fixed. Skinning developer guide needs to be update about how to put a skin into a JAR file --- Key: TRINIDAD-928 URL: https://issues.apache.org/jira/browse/TRINIDAD-928 Project: MyFaces Trinidad Issue Type: Improvement Components: Documentation Affects Versions: 1.2.5-core Reporter: Frank Nimphius Assignee: Jeanne Waldman According to the current developer guide. the trinidad-skin.xml file and its associated skin resources can go into a JAR file for deployment. I searched in Google but couldn't find any good hint on what exactly the configuration steps are (e.g. if I need to add extra tags into the trinidad-skin.xml file or if there is anything to keep in mind when referenceing images. Also, where in relation to trinidad-skin.xml do the CSS and image file have to be located -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TRINIDAD-1592) skin selectors rendered for selectOrderShuttle don't match documented in skin-selectors.html
[
https://issues.apache.org/jira/browse/TRINIDAD-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeanne Waldman resolved TRINIDAD-1592.
--
Resolution: Not A Problem
This is not a bug. By default, we render our style classes in a compressed
mode. This is 'xi'. If you want to see the uncompressed style class name, then
you need to set the org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION
flag to true in web.xml. See the Trinidad Skinning documentation for details.
skin selectors rendered for selectOrderShuttle don't match documented in
skin-selectors.html
---
Key: TRINIDAD-1592
URL: https://issues.apache.org/jira/browse/TRINIDAD-1592
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.12-core
Environment: Browser: FF
OS: windows xp
Reporter: Kai Xu
Both in my code and live demo the html code rendered as:
td valign=middle nowrap= align=center style=padding: 5px;
a
href=javascript:TrShuttleProxy._moveItems('_idJsp2:leading','_idJsp2:trailing');/
a class=xi title=Move selected items to other list
href=javascript:TrShuttleProxy._moveItems('_idJsp2:leading','_idJsp2:trailing');Move/a
div style=margin-top: 5px;/
a
href=javascript:TrShuttleProxy._moveAllItems('_idJsp2:leading','_idJsp2:trailing');/
a class=xi title=Move all items to other list
href=javascript:TrShuttleProxy._moveAllItems('_idJsp2:leading','_idJsp2:trailing');Move
All/a
div style=margin-top: 5px;/
a
href=javascript:TrShuttleProxy._moveItems('_idJsp2:trailing','_idJsp2:leading');/
a class=xi title=Remove selected items from list
href=javascript:TrShuttleProxy._moveItems('_idJsp2:trailing','_idJsp2:leading');Remove/a
div style=margin-top: 5px;/
a
href=javascript:TrShuttleProxy._moveAllItems('_idJsp2:trailing','_idJsp2:leading');/
a class=xi title=Remove all items from list
href=javascript:TrShuttleProxy._moveAllItems('_idJsp2:trailing','_idJsp2:leading');Remove
All/a
/td
td valign=middle align=center
a title=Move selected items to top of list
href=javascript:TrShuttleProxy._orderTopBottomList(0,'_idJsp2:trailing');Top/a
br/
a title=Move selected items up one in list
href=javascript:TrShuttleProxy._orderList(0,'_idJsp2:trailing');Up/a
img width=1 height=15 alt= src=/CommandCenter/adf/images/t.gif/
br/
a title=Move selected items down one in list
href=javascript:TrShuttleProxy._orderList(1,'_idJsp2:trailing');Down/a
br/
a title=Move selected items to bottom of list
href=javascript:TrShuttleProxy._orderTopBottomList(1,'_idJsp2:trailing');Bottom/a
/td
Should they be: something like: .AFShuttleMoveIcon, AFShuttleMoveAllIcon
instead of xi, and at trailing side: there is no class defined at all.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TRINIDAD-2043) af|separator:alias should be af|separator in base-desktop.css
[
https://issues.apache.org/jira/browse/TRINIDAD-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeanne Waldman resolved TRINIDAD-2043.
--
Resolution: Fixed
Fix Version/s: 2.0.0-beta-3
af|separator:alias should be af|separator in base-desktop.css
-
Key: TRINIDAD-2043
URL: https://issues.apache.org/jira/browse/TRINIDAD-2043
Project: MyFaces Trinidad
Issue Type: Bug
Reporter: Jeanne Waldman
Assignee: Jeanne Waldman
Fix For: 2.0.0-beta-3
In base-desktop.css, we have af|separator:alias {}. The selector should be
af|separator {}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TRINIDAD-2041) the design time tool needs browser supported pseudo-classes to be converted like non-browser-supported pseudo-classes
[ https://issues.apache.org/jira/browse/TRINIDAD-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman resolved TRINIDAD-2041. -- Resolution: Fixed Fix Version/s: 2.0.0-beta-3 the design time tool needs browser supported pseudo-classes to be converted like non-browser-supported pseudo-classes - Key: TRINIDAD-2041 URL: https://issues.apache.org/jira/browse/TRINIDAD-2041 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Jeanne Waldman Assignee: Jeanne Waldman Fix For: 2.0.0-beta-3 We have an internal team creating a Skin Editor for JDeveloper. It renders a preview of the component you are skinning in its different states: read-only, visited, hover, active, etc. Some of the states are browser-supported states (hover, visited, active), and some are not (read-only). The Skinning Framework processes the skin file and generates a CSS-2 browser-supported css file. If it sees a browser-supported pseudo-class in the selector, it passes it through to the generated CSS file. If it sees other pseudo-classes, it converts it to 'p_AF*. So af|inputText:read-only becomes .af_inputText.p_AFReadOnly. In the rendered html, you'll see something like div class=af_inputText p_AFReadOnly. af|commandButton:active becomes .af_commandButton:active. There is no need to convert :active because the browser knows what to do with it. For the Design Time Skin Editor, they render a sample of the component in the different states. It isn't a real browser, so the browser-supported states are no supported, like :hover. They need us to convert the browser supported pseudo-clases the same as other pseudo-classes when in Design Time Mode. This is a very simple fix in CSSGenerationUtils.java in static private String _convertPseudoClass(String pseudoClass) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
