[jira] [Created] (TRINIDAD-2368) getFacets().values().remove(component) does not fire REVOVE component system event
Max Starets created TRINIDAD-2368: - Summary: getFacets().values().remove(component) does not fire REVOVE component system event Key: TRINIDAD-2368 URL: https://issues.apache.org/jira/browse/TRINIDAD-2368 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets getFacets().values().remove(component) does not fire the REMOVE event, but getFacets().remove(key) does. This is happening because FacetHashMap in Trinidad only overrides remove() and clear(), but provides no hooks for removal via an entry set or an iterator. Note that Mojarra's UIComponentBase does the right thing -- 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-2369) Mojarra 2.1.18 partial state saving incompatibility when moving a facet
Max Starets created TRINIDAD-2369: - Summary: Mojarra 2.1.18 partial state saving incompatibility when moving a facet Key: TRINIDAD-2369 URL: https://issues.apache.org/jira/browse/TRINIDAD-2369 Project: MyFaces Trinidad Issue Type: Bug Environment: Mojarra 2.1.18 Reporter: Max Starets To reproduce the issue, create a test application doing the following during invoke_application: 1) Move a component to be a facet of some other component: newParent.getFacets().put(center, component1); 2) Move the component to its original parent: originalParent.getChildren().add(component1); Note that the following exception will be thrown by Mojarra: javax.faces.FacesException: Cannot add the same component twice: o1 at com.sun.faces.context.StateContext$AddRemoveListener.handleAddRemoveWithAutoPrune(StateContext.java:528) at com.sun.faces.context.StateContext$AddRemoveListener.handleAdd(StateContext.java:437) at com.sun.faces.context.StateContext$AddRemoveListener.processEvent(StateContext.java:359) at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106) at com.sun.faces.application.ApplicationImpl.processListenersAccountingForAdds(ApplicationImpl.java:2210) at com.sun.faces.application.ApplicationImpl.invokeViewListenersFor(ApplicationImpl.java:2031) at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:292) at org.apache.myfaces.trinidad.component.UIXComponentBase._publishPostAddToViewEvent(UIXComponentBase.java:1597) at org.apache.myfaces.trinidad.component.UIXComponentBase.setParent(UIXComponentBase.java:701) at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:66) at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:73) at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:36) -- 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-2369) Mojarra 2.1.18 partial state saving incompatibility when moving a facet
[ https://issues.apache.org/jira/browse/TRINIDAD-2369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13589932#comment-13589932 ] Max Starets commented on TRINIDAD-2369: --- This issue is a manifestation of TRINIDAD-2368. Because teh REMOVE event is not fired when the component is moved out of the facet, Mojarra's partial code sees two consequitive ADD events for the same component. Mojarra 2.1.18 partial state saving incompatibility when moving a facet --- Key: TRINIDAD-2369 URL: https://issues.apache.org/jira/browse/TRINIDAD-2369 Project: MyFaces Trinidad Issue Type: Bug Environment: Mojarra 2.1.18 Reporter: Max Starets To reproduce the issue, create a test application doing the following during invoke_application: 1) Move a component to be a facet of some other component: newParent.getFacets().put(center, component1); 2) Move the component to its original parent: originalParent.getChildren().add(component1); Note that the following exception will be thrown by Mojarra: javax.faces.FacesException: Cannot add the same component twice: o1 at com.sun.faces.context.StateContext$AddRemoveListener.handleAddRemoveWithAutoPrune(StateContext.java:528) at com.sun.faces.context.StateContext$AddRemoveListener.handleAdd(StateContext.java:437) at com.sun.faces.context.StateContext$AddRemoveListener.processEvent(StateContext.java:359) at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106) at com.sun.faces.application.ApplicationImpl.processListenersAccountingForAdds(ApplicationImpl.java:2210) at com.sun.faces.application.ApplicationImpl.invokeViewListenersFor(ApplicationImpl.java:2031) at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:292) at org.apache.myfaces.trinidad.component.UIXComponentBase._publishPostAddToViewEvent(UIXComponentBase.java:1597) at org.apache.myfaces.trinidad.component.UIXComponentBase.setParent(UIXComponentBase.java:701) at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:66) at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:73) at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:36) -- 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-2369) Mojarra 2.1.18 partial state saving incompatibility when moving a facet
[ https://issues.apache.org/jira/browse/TRINIDAD-2369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2369: -- Status: Patch Available (was: Open) Mojarra 2.1.18 partial state saving incompatibility when moving a facet --- Key: TRINIDAD-2369 URL: https://issues.apache.org/jira/browse/TRINIDAD-2369 Project: MyFaces Trinidad Issue Type: Bug Environment: Mojarra 2.1.18 Reporter: Max Starets Attachments: TRINIDAD-2369.patch To reproduce the issue, create a test application doing the following during invoke_application: 1) Move a component to be a facet of some other component: newParent.getFacets().put(center, component1); 2) Move the component to its original parent: originalParent.getChildren().add(component1); Note that the following exception will be thrown by Mojarra: javax.faces.FacesException: Cannot add the same component twice: o1 at com.sun.faces.context.StateContext$AddRemoveListener.handleAddRemoveWithAutoPrune(StateContext.java:528) at com.sun.faces.context.StateContext$AddRemoveListener.handleAdd(StateContext.java:437) at com.sun.faces.context.StateContext$AddRemoveListener.processEvent(StateContext.java:359) at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106) at com.sun.faces.application.ApplicationImpl.processListenersAccountingForAdds(ApplicationImpl.java:2210) at com.sun.faces.application.ApplicationImpl.invokeViewListenersFor(ApplicationImpl.java:2031) at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:292) at org.apache.myfaces.trinidad.component.UIXComponentBase._publishPostAddToViewEvent(UIXComponentBase.java:1597) at org.apache.myfaces.trinidad.component.UIXComponentBase.setParent(UIXComponentBase.java:701) at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:66) at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:73) at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:36) -- 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] [Resolved] (TRINIDAD-2347) JSESSIONID is not send with the first response
[ https://issues.apache.org/jira/browse/TRINIDAD-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets resolved TRINIDAD-2347. --- Resolution: Fixed JSESSIONID is not send with the first response -- Key: TRINIDAD-2347 URL: https://issues.apache.org/jira/browse/TRINIDAD-2347 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.1-core Reporter: Max Starets Assignee: Max Starets To reproduce the issue, create a Facelets page with a form producing fairly large (~50K) HTML content. Notice that the response for the initial GET does not send JSESSIONID to the client. This is happening because the session is 'touched' by the state saving code after the response headers have been committed to the client. The fix would be to 'touch' the session before rendering begins -- 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-2216) The partialSubmit does not work with JSF 2 RI
[
https://issues.apache.org/jira/browse/TRINIDAD-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Starets updated TRINIDAD-2216:
--
Resolution: Fixed
Fix Version/s: 2.1.0-core
Status: Resolved (was: Patch Available)
The partialSubmit does not work with JSF 2 RI
-
Key: TRINIDAD-2216
URL: https://issues.apache.org/jira/browse/TRINIDAD-2216
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0-core
Environment: Mojarra 2.1.6 (SNAPSHOT 20111206)
Glassfish 3.1.1
Trinidad 2.0.0
Reporter: Tomas Havelka
Fix For: 2.1.0-core
Attachments: TRINIDAD-2216-2259-2302.patch, TRINIDAD-2216.patch
Trinidad's partialSubmit does not work because the source parameter passed in
the jsf.ajax.request call is null. See XMLRequest.js on the line 358. The
source is part of the payload but is not assigned to the source parameter
itself. It causes the RI implementation of jsf.ajax.request throws an error
because of this code in it:
if (typeof source === 'undefined' || source === null) {
throw new Error(jsf.ajax.request: source not set);
}
--
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-2259) Serious problem with Facelets - launchDialog.xhtml from examples doesn't work as facelet - problem with partialSubmit=true
[ https://issues.apache.org/jira/browse/TRINIDAD-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2259: -- Resolution: Fixed Fix Version/s: 2.1.0-core Status: Resolved (was: Patch Available) Fixed by TRINIDAD-2216 Serious problem with Facelets - launchDialog.xhtml from examples doesn't work as facelet - problem with partialSubmit=true -- Key: TRINIDAD-2259 URL: https://issues.apache.org/jira/browse/TRINIDAD-2259 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.1-core Environment: mojarra 2.0.9 Reporter: Daniel Charczynski Assignee: Max Starets Priority: Critical Fix For: 2.0.2-core, 2.1.0-core launchDialog.xhtml from examples doesn't work as facelet problem with ReturnEvent There is simple way to reproduce this issue 1 download trinidad 2.0.1 examples http://www.apache.org/dyn/closer.cgi/myfaces/binaries/trinidad-2.0.1-example.zip 2. download and extract tomcat 6.x 3. put mojarra 2.0.9 into tomcat libs 4. put jstl 1.2.1 api and impl libs into tomcat libs do some changes in trinidad-demo.war 5. copy launchDialog.jspx to launchDialog.xhtml 6 change jsp:root tag of launchDialog.xhtml to ui:composition xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; xmlns:trd=http://myfaces.apache.org/trinidad/demo; xmlns:trh=http://myfaces.apache.org/trinidad/html; and end jsp:root to ui:composition 7. deploy trinidad-demo.war and start server 8. go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml and clickAdd button - should not work :( IT WILL WORK WHEN - go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml - click (first ellipsis button) - close popup - Click Add button :) important thing is to go load http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml page directly from browser - every test - in order to clear all parameters simillar issue is when you change javax.faces.FACELETS_VIEW_MAPPINGS to *.jspx and go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.jspx -- 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-2334) Dialog popup returns with error, if called from commandButton with partial submit
[
https://issues.apache.org/jira/browse/TRINIDAD-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Starets updated TRINIDAD-2334:
--
Resolution: Fixed
Fix Version/s: (was: 2.0.2-core)
Status: Resolved (was: Patch Available)
Fixed by TRINIDAD-2216
Dialog popup returns with error, if called from commandButton with partial
submit
-
Key: TRINIDAD-2334
URL: https://issues.apache.org/jira/browse/TRINIDAD-2334
Project: MyFaces Trinidad
Issue Type: Bug
Components: Build
Affects Versions: 2.0.1-core
Environment: Tomcat 7.0.32, Mojarra 2.0.9, Trinidad 2.0.1, Internet
Explorer 8, FireFox 15
Reporter: Robert Schoch
Assignee: Max Starets
Priority: Blocker
Labels: patch
Fix For: 2.1.0-core
Attachments: patch-for-XMLRequest.diff
Dialog launch in XHTML pages works fine and the components with
partialTriggers are updated.
But after return from dialog the following error message appears:
Error calling TrPanelPopup callback function:
Error: jsf.ajax.request: source not set
Then nothing happens more, no components are updated and the page is blocked
for about 10 seconds.
This is a Sample for the dialog launch page:
tr:document xmlns=http://www.w3.org/1999/xhtml;
xmlns:tr=http://myfaces.apache.org/trinidad;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
id=HtmlDocument mode=strict title=Test Dialog Launcher
tr:form id=TestForm
tr:panelButtonBar id=ButtonBar
inlineStyle=margin-left:auto;margin-right:auto;
tr:commandButton id=launchButton text=Launch Dialog
action=dialog:confirm
useWindow=true windowWidth=280 windowHeight=120
partialSubmit=true
launchListener=#{dialogController.dialogLaunchListener}
returnListener=#{dialogController.dialogReturnListener} /
/tr:panelButtonBar
tr:panelBox id=infoPanel text=Last Action
partialTriggers=launchButton
inlineStyle=margin-left:auto;margin-right:auto;
tr:outputText id=lastAction value=#{dialogController.lastAction}
/
/tr:panelBox
/tr:form
/tr:document
This is the dialog page:
tr:document xmlns=http://www.w3.org/1999/xhtml;
xmlns:tr=http://myfaces.apache.org/trinidad;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
id=HtmlDocument mode=strict title=Test Dialog
tr:form id=DialogForm
tr:outputText id=dialogMessage value=hello from dialog /
tr:panelButtonBar id=buttonBar
inlineStyle=width:auto;margin-left:auto;margin-right:auto;
tr:commandButton id=okButton text=OK
actionListener=#{dialogController.dialogActionListener}/
tr:commandButton id=cancelButton text=Cancel
actionListener=#{dialogController.dialogActionListener}/
/tr:panelButtonBar
/tr:form
/tr:document
And this is the dialog controller:
package de.ospkdd.sample;
import java.io.Serializable;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
import javax.faces.event.ActionEvent;
import org.apache.myfaces.trinidad.context.RequestContext;
import org.apache.myfaces.trinidad.event.LaunchEvent;
import org.apache.myfaces.trinidad.event.ReturnEvent;
@ManagedBean
@SessionScoped
public class DialogController implements Serializable {
private static final long serialVersionUID = -23121260063689204L;
private String lastAction = ???;
public DialogController() {}
public void dialogLaunchListener(LaunchEvent event) {
lastAction = dialog launched...;
}
public void dialogActionListener(ActionEvent event) {
RequestContext.getCurrentInstance().returnFromDialog(
event.getComponent().getId(), null);
lastAction = button clicked...;
}
public void dialogReturnListener(ReturnEvent event) {
lastAction = dialog returned: + (String)event.getReturnValue();
}
public String getLastAction() {
return lastAction;
}
}
--
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-2347) JSESSIONID is not send with the first RESPONSE
Max Starets created TRINIDAD-2347: - Summary: JSESSIONID is not send with the first RESPONSE Key: TRINIDAD-2347 URL: https://issues.apache.org/jira/browse/TRINIDAD-2347 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.1-core Reporter: Max Starets Assignee: Max Starets To reproduce the issue, create a Facelets page with a form producing fairly large (~50K) HTML content. Notice that the response for the initial GET does not send JSESSIONID to the client. This is happening because the session is 'touched' by the state saving code after the response headers have been committed to the client. The fix would be to 'touch' the session before rendering begins -- 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-2259) Serious problem with Facelets - launchDialog.xhtml from examples doesn't work as facelet - problem with partialSubmit=true
[ https://issues.apache.org/jira/browse/TRINIDAD-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13512058#comment-13512058 ] Max Starets commented on TRINIDAD-2259: --- I will be working on TRINIDAD-2334 soon. Also filed a related issue TRINIDAD-2347 Serious problem with Facelets - launchDialog.xhtml from examples doesn't work as facelet - problem with partialSubmit=true -- Key: TRINIDAD-2259 URL: https://issues.apache.org/jira/browse/TRINIDAD-2259 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.1-core Environment: mojarra 2.0.9 Reporter: Daniel Charczynski Assignee: Max Starets Priority: Critical Fix For: 2.0.2-core launchDialog.xhtml from examples doesn't work as facelet problem with ReturnEvent There is simple way to reproduce this issue 1 download trinidad 2.0.1 examples http://www.apache.org/dyn/closer.cgi/myfaces/binaries/trinidad-2.0.1-example.zip 2. download and extract tomcat 6.x 3. put mojarra 2.0.9 into tomcat libs 4. put jstl 1.2.1 api and impl libs into tomcat libs do some changes in trinidad-demo.war 5. copy launchDialog.jspx to launchDialog.xhtml 6 change jsp:root tag of launchDialog.xhtml to ui:composition xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; xmlns:trd=http://myfaces.apache.org/trinidad/demo; xmlns:trh=http://myfaces.apache.org/trinidad/html; and end jsp:root to ui:composition 7. deploy trinidad-demo.war and start server 8. go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml and clickAdd button - should not work :( IT WILL WORK WHEN - go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml - click (first ellipsis button) - close popup - Click Add button :) important thing is to go load http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml page directly from browser - every test - in order to clear all parameters simillar issue is when you change javax.faces.FACELETS_VIEW_MAPPINGS to *.jspx and go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.jspx -- 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] [Reopened] (TRINIDAD-2259) Serious problem with Facelets - launchDialog.xhtml from examples doesn't work as facelet - problem with partialSubmit=true
[ https://issues.apache.org/jira/browse/TRINIDAD-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets reopened TRINIDAD-2259: --- Assignee: Max Starets Reopening this issue, since there are other problems with the dialog beyond the null source error in JSF Ajax implementation Serious problem with Facelets - launchDialog.xhtml from examples doesn't work as facelet - problem with partialSubmit=true -- Key: TRINIDAD-2259 URL: https://issues.apache.org/jira/browse/TRINIDAD-2259 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.1-core Environment: mojarra 2.0.9 Reporter: Daniel Charczynski Assignee: Max Starets Priority: Critical Fix For: 2.0.2-core launchDialog.xhtml from examples doesn't work as facelet problem with ReturnEvent There is simple way to reproduce this issue 1 download trinidad 2.0.1 examples http://www.apache.org/dyn/closer.cgi/myfaces/binaries/trinidad-2.0.1-example.zip 2. download and extract tomcat 6.x 3. put mojarra 2.0.9 into tomcat libs 4. put jstl 1.2.1 api and impl libs into tomcat libs do some changes in trinidad-demo.war 5. copy launchDialog.jspx to launchDialog.xhtml 6 change jsp:root tag of launchDialog.xhtml to ui:composition xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; xmlns:trd=http://myfaces.apache.org/trinidad/demo; xmlns:trh=http://myfaces.apache.org/trinidad/html; and end jsp:root to ui:composition 7. deploy trinidad-demo.war and start server 8. go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml and clickAdd button - should not work :( IT WILL WORK WHEN - go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml - click (first ellipsis button) - close popup - Click Add button :) important thing is to go load http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml page directly from browser - every test - in order to clear all parameters simillar issue is when you change javax.faces.FACELETS_VIEW_MAPPINGS to *.jspx and go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.jspx -- 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-2259) Serious problem with Facelets - launchDialog.xhtml from examples doesn't work as facelet - problem with partialSubmit=true
[ https://issues.apache.org/jira/browse/TRINIDAD-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505969#comment-13505969 ] Max Starets commented on TRINIDAD-2259: --- The org.apache.myfaces.trinidadinternal.PPR_OVER_JSF_AJAX workaround would still apply though Serious problem with Facelets - launchDialog.xhtml from examples doesn't work as facelet - problem with partialSubmit=true -- Key: TRINIDAD-2259 URL: https://issues.apache.org/jira/browse/TRINIDAD-2259 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.1-core Environment: mojarra 2.0.9 Reporter: Daniel Charczynski Assignee: Max Starets Priority: Critical Fix For: 2.0.2-core launchDialog.xhtml from examples doesn't work as facelet problem with ReturnEvent There is simple way to reproduce this issue 1 download trinidad 2.0.1 examples http://www.apache.org/dyn/closer.cgi/myfaces/binaries/trinidad-2.0.1-example.zip 2. download and extract tomcat 6.x 3. put mojarra 2.0.9 into tomcat libs 4. put jstl 1.2.1 api and impl libs into tomcat libs do some changes in trinidad-demo.war 5. copy launchDialog.jspx to launchDialog.xhtml 6 change jsp:root tag of launchDialog.xhtml to ui:composition xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; xmlns:trd=http://myfaces.apache.org/trinidad/demo; xmlns:trh=http://myfaces.apache.org/trinidad/html; and end jsp:root to ui:composition 7. deploy trinidad-demo.war and start server 8. go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml and clickAdd button - should not work :( IT WILL WORK WHEN - go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml - click (first ellipsis button) - close popup - Click Add button :) important thing is to go load http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml page directly from browser - every test - in order to clear all parameters simillar issue is when you change javax.faces.FACELETS_VIEW_MAPPINGS to *.jspx and go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.jspx -- 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-2129) Component showcase demo broken
[ https://issues.apache.org/jira/browse/TRINIDAD-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085964#comment-13085964 ] Max Starets commented on TRINIDAD-2129: --- The issue is that RI's BaseTableRenderer is using writeText(Object text, UIComponent component, String propertyName), which is not overridden in PPRResponseWriter (the method was added in JSF 1.2). This produces white space in PPR response, which is not tolerated by JSF Ajax response processing. The old legacy Trinidad PPR response processor was just skipping the white space, so we never ran into this problem. Introducing writeText override in PPRResponseWriter fixes the issue. Component showcase demo broken -- Key: TRINIDAD-2129 URL: https://issues.apache.org/jira/browse/TRINIDAD-2129 Project: MyFaces Trinidad Issue Type: Bug Environment: Tested on GlassFish v3.1, though not sure that is significant. Repros in various browsers (FF, Safari, Chrome). Reporter: Andy Schwartz The Browse Components accordion in the component showcase demo is not working. It is not possible to disclose any accordion pane. Interestingly, the standalone panelAccordion demo under the trinidad-demo example does work without problem. Specifying priority as major (and possibly should be higher) as it is possible that this is a symptom of a more fundamental problem. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TRINIDAD-2129) Component showcase demo broken
[ https://issues.apache.org/jira/browse/TRINIDAD-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets resolved TRINIDAD-2129. --- Resolution: Fixed Fix Version/s: 2.0.1 Component showcase demo broken -- Key: TRINIDAD-2129 URL: https://issues.apache.org/jira/browse/TRINIDAD-2129 Project: MyFaces Trinidad Issue Type: Bug Environment: Tested on GlassFish v3.1, though not sure that is significant. Repros in various browsers (FF, Safari, Chrome). Reporter: Andy Schwartz Assignee: Max Starets Fix For: 2.0.1 Attachments: TRINIDAD-2129.patch The Browse Components accordion in the component showcase demo is not working. It is not possible to disclose any accordion pane. Interestingly, the standalone panelAccordion demo under the trinidad-demo example does work without problem. Specifying priority as major (and possibly should be higher) as it is possible that this is a symptom of a more fundamental problem. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2124) TrinidadAgent Needs to Expose Browser Management History Capability
TrinidadAgent Needs to Expose Browser Management History Capability --- Key: TRINIDAD-2124 URL: https://issues.apache.org/jira/browse/TRINIDAD-2124 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.1 Reporter: Max Starets -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2124) TrinidadAgent Needs to Expose Browser Management History Capability
[ https://issues.apache.org/jira/browse/TRINIDAD-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2124: -- Status: Patch Available (was: Open) TrinidadAgent Needs to Expose Browser Management History Capability --- Key: TRINIDAD-2124 URL: https://issues.apache.org/jira/browse/TRINIDAD-2124 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.1 Reporter: Max Starets Assignee: Max Starets Attachments: trinidad-2124.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2123) tr:chart chartDrillDownListener method not called with facelets
[
https://issues.apache.org/jira/browse/TRINIDAD-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071240#comment-13071240
]
Max Starets commented on TRINIDAD-2123:
---
As a temporary workaround, you can use a component binding for your chart with
a request-scoped bean. In your bean's setter method (lets say it is called
setChart()) you can call addChartDrillDownListener programmatically to register
your listener.
tr:chart chartDrillDownListener method not called with facelets
---
Key: TRINIDAD-2123
URL: https://issues.apache.org/jira/browse/TRINIDAD-2123
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components, Facelets
Affects Versions: 2.0.0
Environment: Intel x64 platform, Windows 7, FireFox 5.0
Reporter: Kokavecz András
Original Estimate: 1h
Remaining Estimate: 1h
I'm trying to use Trinidad charts and I have problems with the chartDrillDown
listener and also with the binding of the chart component to an UIComponent.
1.)
If I use a JSPX page with jsp:root and f:view tags, so withOUT Facelets it
all works fine...the chartDrillDown fires up.
2.)
If inside ui:composition tags, so WITH facelets the problem is, that the API
tries to look up the chartDrillDownListener as a property not as a
MethodExpression.
This is also the case with bindig the tr:chart element to an UIComponent.
I debugged the class UIXChart, as the event travels throught its
broadcast(FacesEvent event) method.
// Deliver to the default ChartDrillDownEvent
if (event instanceof ChartDrillDownEvent) {
broadcastToMethodExpression(event,
getChartDrillDownListener());
}
super.broadcast(event);
In case of FACELETS the getChartDrillDownListener() method tries to call
getProperty() for UIXComponentBase and exits with a PropertyNotFoundException.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2100) Trinidad's Library Scriptlet Mechansim Should Support More Selective JS Inclusion
[ https://issues.apache.org/jira/browse/TRINIDAD-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031902#comment-13031902 ] Max Starets commented on TRINIDAD-2100: --- The basic idea of the patch is to separate Locale, CoreFormat, DateFormat and ColorFormat libraries from the common library. This will allow frameworks using Trinidad as a base to include libraries selectively. Trinidad's Library Scriptlet Mechansim Should Support More Selective JS Inclusion - Key: TRINIDAD-2100 URL: https://issues.apache.org/jira/browse/TRINIDAD-2100 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0 Reporter: Max Starets Assignee: Max Starets Attachments: trinidad-2100.patch Currently, most of Trinidad's JS libs go into the common js library. It makes sense to break out libraries dealing with client-side formatting since they are fairly large, and pulling them on demand is possible. It also makes sense to separate locale support from the rest of the common, so that other framework using Trinidad (namely ADF Faces) could avoid pulling in unnecessary functionality (PPR support, etc.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2100) Trinidad's Library Scriptlet Mechansim Should Support More Selective JS Inclusion
Trinidad's Library Scriptlet Mechansim Should Support More Selective JS Inclusion - Key: TRINIDAD-2100 URL: https://issues.apache.org/jira/browse/TRINIDAD-2100 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets Assignee: Max Starets Currently, most of Trinidad's JS libs go into the common js library. It makes sense to break out libraries dealing with client-side formatting since they are fairly large, and pulling them on demand is possible. It also makes sense to separate locale support from the rest of the common, so that other framework using Trinidad (namely ADF Faces) could avoid pulling in unnecessary functionality (PPR support, etc.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2100) Trinidad's Library Scriptlet Mechansim Should Support More Selective JS Inclusion
[ https://issues.apache.org/jira/browse/TRINIDAD-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2100: -- Status: Patch Available (was: Open) Trinidad's Library Scriptlet Mechansim Should Support More Selective JS Inclusion - Key: TRINIDAD-2100 URL: https://issues.apache.org/jira/browse/TRINIDAD-2100 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets Assignee: Max Starets Attachments: TRINIDAD-2002.patch Currently, most of Trinidad's JS libs go into the common js library. It makes sense to break out libraries dealing with client-side formatting since they are fairly large, and pulling them on demand is possible. It also makes sense to separate locale support from the rest of the common, so that other framework using Trinidad (namely ADF Faces) could avoid pulling in unnecessary functionality (PPR support, etc.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2073) Session based changes fail to apply for facelets VDL
[ https://issues.apache.org/jira/browse/TRINIDAD-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2073: -- Status: Open (was: Patch Available) Session based changes fail to apply for facelets VDL Key: TRINIDAD-2073 URL: https://issues.apache.org/jira/browse/TRINIDAD-2073 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.0-beta-2 Reporter: Prakash Udupa Attachments: TRINIDAD-2073.patch Original Estimate: 24h Remaining Estimate: 24h SessionChangeManager stored changes are not applied for Facelets pages. These work well for JSPs, where we invoke the change application methods in SessionChangeManager from the document tag handler. For facelets we need to call these methods similarly in a suitable point in the lifecycle, either in the document handler or soon after the view is built. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2073) Session based changes fail to apply for facelets VDL
[ https://issues.apache.org/jira/browse/TRINIDAD-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13017570#comment-13017570 ] Max Starets commented on TRINIDAD-2073: --- Reverted changes per Prakash's request Session based changes fail to apply for facelets VDL Key: TRINIDAD-2073 URL: https://issues.apache.org/jira/browse/TRINIDAD-2073 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.0-beta-2 Reporter: Prakash Udupa Attachments: TRINIDAD-2073.patch Original Estimate: 24h Remaining Estimate: 24h SessionChangeManager stored changes are not applied for Facelets pages. These work well for JSPs, where we invoke the change application methods in SessionChangeManager from the document tag handler. For facelets we need to call these methods similarly in a suitable point in the lifecycle, either in the document handler or soon after the view is built. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2068) Trinidad's faces-config.xml should have metadata-complete=true
Trinidad's faces-config.xml should have metadata-complete=true -- Key: TRINIDAD-2068 URL: https://issues.apache.org/jira/browse/TRINIDAD-2068 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Reporter: Max Starets Assignee: Max Starets Since trinidad-impl.jar does not use configuration annotations, we should disable annotation scanning by setting metadata-complete to false in faces-config. This will improve deployment performance for applications using Trinidad. Note that the change will disable annotation scanning only for trinidad-impl.jar. Users will still be able to use annotations in their code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2068) Trinidad's faces-config.xml should have metadata-complete=true
[ https://issues.apache.org/jira/browse/TRINIDAD-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2068: -- Status: Patch Available (was: Open) Trinidad's faces-config.xml should have metadata-complete=true -- Key: TRINIDAD-2068 URL: https://issues.apache.org/jira/browse/TRINIDAD-2068 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Reporter: Max Starets Assignee: Max Starets Attachments: trinidad2068-pom.patch, trinidad2068.patch Since trinidad-impl.jar does not use configuration annotations, we should disable annotation scanning by setting metadata-complete to false in faces-config. This will improve deployment performance for applications using Trinidad. Note that the change will disable annotation scanning only for trinidad-impl.jar. Users will still be able to use annotations in their code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2068) Trinidad's faces-config.xml should have metadata-complete=true
[ https://issues.apache.org/jira/browse/TRINIDAD-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2068: -- Resolution: Fixed Fix Version/s: 2.0.5-plugins Status: Resolved (was: Patch Available) Trinidad's faces-config.xml should have metadata-complete=true -- Key: TRINIDAD-2068 URL: https://issues.apache.org/jira/browse/TRINIDAD-2068 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Reporter: Max Starets Assignee: Max Starets Fix For: 2.0.5-plugins Attachments: trinidad2068-pom.patch, trinidad2068.patch Since trinidad-impl.jar does not use configuration annotations, we should disable annotation scanning by setting metadata-complete to false in faces-config. This will improve deployment performance for applications using Trinidad. Note that the change will disable annotation scanning only for trinidad-impl.jar. Users will still be able to use annotations in their code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TRINIDAD-2048) ComponentUtils.getScopedIdForComponent() is not producing consistent scoped IDs for components relocated during tag execution
[ https://issues.apache.org/jira/browse/TRINIDAD-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets resolved TRINIDAD-2048. --- Resolution: Fixed ComponentUtils.getScopedIdForComponent() is not producing consistent scoped IDs for components relocated during tag execution - Key: TRINIDAD-2048 URL: https://issues.apache.org/jira/browse/TRINIDAD-2048 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets Assignee: Max Starets Attachments: trinidad2048-1.2.x.patch, trinidad2048.patch getScopedIdForComponent() simply walks the parent hierarchy to append naming container IDs. However, we have components that get relocated during tag execution, so their naming container hierarchy is different at tag execution time vs. the rest of the lifecycle. To solve this problem, we need to have getScopedIdForComponent return a scoped Id reflecting the original naming container hierarchy for the component, i.e. return its pre-relocation scoped ID. This will require API additions on UIXComponent to allow relocated components to provide their logical (original parent). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2048) ComponentUtils.getScopedIdForComponent() is not producing consistent scoped IDs for components relocated during tag execution
[
https://issues.apache.org/jira/browse/TRINIDAD-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13006083#comment-13006083
]
Max Starets commented on TRINIDAD-2048:
---
Minor modification on top of the deltas to handle null _insertBeforeId:
@Override
public boolean equals(Object o)
{
if (o == this)
return true;
if (!(o instanceof MoveChildComponentChange))
return false;
MoveChildComponentChange other = (MoveChildComponentChange)o;
return getSourceLogicalScopedId().equals(other.getSourceLogicalScopedId())
getDestinationLogicalScopedId().equals(other.getDestinationLogicalScopedId())
_equalsOrNull(_insertBeforeId, other._insertBeforeId);
}
@Override
public int hashCode()
{
int hashCode = getSourceLogicalScopedId().hashCode() + 37 *
getDestinationLogicalScopedId().hashCode();
if (_insertBeforeId != null)
{
hashCode = hashCode + 1369 * _insertBeforeId.hashCode();
}
return hashCode;
}
private boolean _equalsOrNull(Object obj1, Object obj2)
{
return (obj1 == null) ? (obj2 == null) : obj1.equals(obj2);
}
ComponentUtils.getScopedIdForComponent() is not producing consistent scoped
IDs for components relocated during tag execution
-
Key: TRINIDAD-2048
URL: https://issues.apache.org/jira/browse/TRINIDAD-2048
Project: MyFaces Trinidad
Issue Type: Bug
Reporter: Max Starets
Assignee: Max Starets
Attachments: trinidad2048-1.2.x.patch, trinidad2048.patch
getScopedIdForComponent() simply walks the parent hierarchy to append naming
container IDs. However, we have components that get relocated during tag
execution, so their naming container hierarchy is different at tag execution
time vs. the rest of the lifecycle. To solve this problem, we need to have
getScopedIdForComponent return a scoped Id reflecting the original naming
container hierarchy for the component, i.e. return its pre-relocation scoped
ID.
This will require API additions on UIXComponent to allow relocated components
to provide their logical (original parent).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2048) ComponentUtils.getScopedIdForComponent() is not producing consistent scoped IDs for components relocated during tag execution
ComponentUtils.getScopedIdForComponent() is not producing consistent scoped IDs for components relocated during tag execution - Key: TRINIDAD-2048 URL: https://issues.apache.org/jira/browse/TRINIDAD-2048 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets Assignee: Max Starets getScopedIdForComponent() simply walks the parent hierarchy to append naming container IDs. However, we have components that get relocated during tag execution, so their naming container hierarchy is different at tag execution time vs. the rest of the lifecycle. To solve this problem, we need to have getScopedIdForComponent return a scoped Id reflecting the original naming container hierarchy for the component, i.e. return its pre-relocation scoped ID. This will require API additions on UIXComponent to allow relocated components to provide their logical (original parent). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2040) Issue 2034 introduced regression in StringArrayPropertyTagRule
Issue 2034 introduced regression in StringArrayPropertyTagRule -- Key: TRINIDAD-2040 URL: https://issues.apache.org/jira/browse/TRINIDAD-2040 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets Assignee: Max Starets To reproduce, run any Facelets page that uses partialTrigger attribute. You will see the following exception: java.lang.IllegalArgumentException: argument type mismatch [echo] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [echo] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [echo] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [echo] at java.lang.reflect.Method.invoke(Method.java:597) [echo] at org.apache.myfaces.trinidadinternal.facelets.StringArrayPropertyTagRule$LiteralPropertyMetadata.applyMetadata(StringArrayPropertyTagRule.java:66) [echo] at -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2040) Issue 2034 introduced regression in StringArrayPropertyTagRule
[ https://issues.apache.org/jira/browse/TRINIDAD-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996575#comment-12996575 ] Max Starets commented on TRINIDAD-2040: --- The problem was that 'params; was declared as an Object, and not as an Onject[]. Issue 2034 introduced regression in StringArrayPropertyTagRule -- Key: TRINIDAD-2040 URL: https://issues.apache.org/jira/browse/TRINIDAD-2040 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets Assignee: Max Starets To reproduce, run any Facelets page that uses partialTrigger attribute. You will see the following exception: java.lang.IllegalArgumentException: argument type mismatch [echo] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [echo] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [echo] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [echo] at java.lang.reflect.Method.invoke(Method.java:597) [echo] at org.apache.myfaces.trinidadinternal.facelets.StringArrayPropertyTagRule$LiteralPropertyMetadata.applyMetadata(StringArrayPropertyTagRule.java:66) [echo] at -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TRINIDAD-2040) Issue 2034 introduced regression in StringArrayPropertyTagRule
[ https://issues.apache.org/jira/browse/TRINIDAD-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets resolved TRINIDAD-2040. --- Resolution: Fixed Issue 2034 introduced regression in StringArrayPropertyTagRule -- Key: TRINIDAD-2040 URL: https://issues.apache.org/jira/browse/TRINIDAD-2040 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets Assignee: Max Starets To reproduce, run any Facelets page that uses partialTrigger attribute. You will see the following exception: java.lang.IllegalArgumentException: argument type mismatch [echo] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [echo] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [echo] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [echo] at java.lang.reflect.Method.invoke(Method.java:597) [echo] at org.apache.myfaces.trinidadinternal.facelets.StringArrayPropertyTagRule$LiteralPropertyMetadata.applyMetadata(StringArrayPropertyTagRule.java:66) [echo] at -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TRINIDAD-2034) DatePropertyTagRule and StringArrayPropertyTagRule cache mutable objects
[ https://issues.apache.org/jira/browse/TRINIDAD-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2034: -- Status: Patch Available (was: Open) DatePropertyTagRule and StringArrayPropertyTagRule cache mutable objects Key: TRINIDAD-2034 URL: https://issues.apache.org/jira/browse/TRINIDAD-2034 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets Assignee: Max Starets When DatePropertyTagRule and StringArrayPropertyTagRule are applied to attributes specified as string literals, the parsing results are cached on the tag. The issue is that the parsing results are mutable (java.util.Date and String[]), so they a) cannot be shared; b) cannot be cached. The fix will be to clone a new object every time LiteralPropertyMetadata.applyMetadata() is called. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TRINIDAD-2034) DatePropertyTagRule and StringArrayPropertyTagRule cache mutable objects
[ https://issues.apache.org/jira/browse/TRINIDAD-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2034: -- Resolution: Fixed Status: Resolved (was: Patch Available) DatePropertyTagRule and StringArrayPropertyTagRule cache mutable objects Key: TRINIDAD-2034 URL: https://issues.apache.org/jira/browse/TRINIDAD-2034 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets Assignee: Max Starets Attachments: trinidad-2034.diff When DatePropertyTagRule and StringArrayPropertyTagRule are applied to attributes specified as string literals, the parsing results are cached on the tag. The issue is that the parsing results are mutable (java.util.Date and String[]), so they a) cannot be shared; b) cannot be cached. The fix will be to clone a new object every time LiteralPropertyMetadata.applyMetadata() is called. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2034) DatePropertyTagRule and StringArrayPropertyTagRule cache mutable objects
DatePropertyTagRule and StringArrayPropertyTagRule cache mutable objects Key: TRINIDAD-2034 URL: https://issues.apache.org/jira/browse/TRINIDAD-2034 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets Assignee: Max Starets When DatePropertyTagRule and StringArrayPropertyTagRule are applied to attributes specified as string literals, the parsing results are cached on the tag. The issue is that the parsing results are mutable (java.util.Date and String[]), so they a) cannot be shared; b) cannot be cached. The fix will be to clone a new object every time LiteralPropertyMetadata.applyMetadata() is called. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (TRINIDAD-1632) Trinidad 2 - exception thrown when partial state saving turned on
[ https://issues.apache.org/jira/browse/TRINIDAD-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets reopened TRINIDAD-1632: --- Assignee: Max Starets (was: Gabrielle Crawford) We are still seeing this issue when view root caching is enabled. Trinidad 2 - exception thrown when partial state saving turned on - Key: TRINIDAD-1632 URL: https://issues.apache.org/jira/browse/TRINIDAD-1632 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-alpha Reporter: Gabrielle Crawford Assignee: Max Starets Fix For: 2.0.0-alpha Set the following values in web.xml context-param param-namejavax.faces.PARTIAL_STATE_SAVING/param-name param-valuetrue/param-value /context-param context-param param-nameorg.apache.myfaces.trinidad.CHANGE_PERSISTENCE/param-name param-valueorg.apache.myfaces.trinidad.change.NullChangeManager/param-value /context-param context-param param-nameorg.apache.myfaces.trinidad.CACHE_VIEW_ROOT/param-name param-valuefalse/param-value /context-param context-param param-namejavax.faces.FACELETS_VIEW_MAPPINGS/param-name param-value*.xhtml;*.jspx/param-value /context-param Now render a page, initially it renders fine, but when you try to interact with the page, like click a command component, you get an exception java.lang.NullPointerException at org.apache.myfaces.trinidad.component.UIXComponentBase._getRendererImpl(UIXComponentBase.java:1145) at org.apache.myfaces.trinidad.component.UIXComponentBase._getLifecycleRendererImpl(UIXComponentBase.java:1159) at org.apache.myfaces.trinidad.component.UIXComponentBase.getLifecycleRenderer(UIXComponentBase.java:1184) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:978) at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes(UIXComponentBase.java:799) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1042) at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:940) at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:310) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292) at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at org.apache.myfaces.trinidaddemo.webapp.RedirectFilter.doFilter(RedirectFilter.java:97) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at oracle.dms.wls.DMSServletFilter.doFilter(DMSServletFilter.java:325) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3592) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2202) at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2108) at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1432) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1632) Trinidad 2 - exception thrown when partial state saving turned on
[ https://issues.apache.org/jira/browse/TRINIDAD-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1632: -- Status: Patch Available (was: Reopened) Trinidad 2 - exception thrown when partial state saving turned on - Key: TRINIDAD-1632 URL: https://issues.apache.org/jira/browse/TRINIDAD-1632 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-alpha Reporter: Gabrielle Crawford Assignee: Max Starets Fix For: 2.0.0-alpha Attachments: trinidad-1632.patch Set the following values in web.xml context-param param-namejavax.faces.PARTIAL_STATE_SAVING/param-name param-valuetrue/param-value /context-param context-param param-nameorg.apache.myfaces.trinidad.CHANGE_PERSISTENCE/param-name param-valueorg.apache.myfaces.trinidad.change.NullChangeManager/param-value /context-param context-param param-nameorg.apache.myfaces.trinidad.CACHE_VIEW_ROOT/param-name param-valuefalse/param-value /context-param context-param param-namejavax.faces.FACELETS_VIEW_MAPPINGS/param-name param-value*.xhtml;*.jspx/param-value /context-param Now render a page, initially it renders fine, but when you try to interact with the page, like click a command component, you get an exception java.lang.NullPointerException at org.apache.myfaces.trinidad.component.UIXComponentBase._getRendererImpl(UIXComponentBase.java:1145) at org.apache.myfaces.trinidad.component.UIXComponentBase._getLifecycleRendererImpl(UIXComponentBase.java:1159) at org.apache.myfaces.trinidad.component.UIXComponentBase.getLifecycleRenderer(UIXComponentBase.java:1184) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:978) at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes(UIXComponentBase.java:799) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1042) at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:940) at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:310) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292) at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at org.apache.myfaces.trinidaddemo.webapp.RedirectFilter.doFilter(RedirectFilter.java:97) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at oracle.dms.wls.DMSServletFilter.doFilter(DMSServletFilter.java:325) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3592) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2202) at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2108) at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1432) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1632) Trinidad 2 - exception thrown when partial state saving turned on
[ https://issues.apache.org/jira/browse/TRINIDAD-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1632: -- Resolution: Fixed Fix Version/s: (was: 2.0.0-alpha) 2.0.0-alpha-2 Status: Resolved (was: Patch Available) Force full state saving for the view root if view root caching is enabled. Trinidad 2 - exception thrown when partial state saving turned on - Key: TRINIDAD-1632 URL: https://issues.apache.org/jira/browse/TRINIDAD-1632 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-alpha Reporter: Gabrielle Crawford Assignee: Max Starets Fix For: 2.0.0-alpha-2 Attachments: trinidad-1632.patch Set the following values in web.xml context-param param-namejavax.faces.PARTIAL_STATE_SAVING/param-name param-valuetrue/param-value /context-param context-param param-nameorg.apache.myfaces.trinidad.CHANGE_PERSISTENCE/param-name param-valueorg.apache.myfaces.trinidad.change.NullChangeManager/param-value /context-param context-param param-nameorg.apache.myfaces.trinidad.CACHE_VIEW_ROOT/param-name param-valuefalse/param-value /context-param context-param param-namejavax.faces.FACELETS_VIEW_MAPPINGS/param-name param-value*.xhtml;*.jspx/param-value /context-param Now render a page, initially it renders fine, but when you try to interact with the page, like click a command component, you get an exception java.lang.NullPointerException at org.apache.myfaces.trinidad.component.UIXComponentBase._getRendererImpl(UIXComponentBase.java:1145) at org.apache.myfaces.trinidad.component.UIXComponentBase._getLifecycleRendererImpl(UIXComponentBase.java:1159) at org.apache.myfaces.trinidad.component.UIXComponentBase.getLifecycleRenderer(UIXComponentBase.java:1184) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:978) at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes(UIXComponentBase.java:799) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1042) at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:940) at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:310) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292) at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at org.apache.myfaces.trinidaddemo.webapp.RedirectFilter.doFilter(RedirectFilter.java:97) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at oracle.dms.wls.DMSServletFilter.doFilter(DMSServletFilter.java:325) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3592) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2202) at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2108) at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1432) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at
[jira] Created: (TRINIDAD-2010) Agent's support for web crawlers should include Oracle SES
Agent's support for web crawlers should include Oracle SES -- Key: TRINIDAD-2010 URL: https://issues.apache.org/jira/browse/TRINIDAD-2010 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha-2 Reporter: Max Starets Assignee: Max Starets -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-2010) Agent's support for web crawlers should include Oracle SES
[ https://issues.apache.org/jira/browse/TRINIDAD-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2010: -- Status: Patch Available (was: Open) Agent's support for web crawlers should include Oracle SES -- Key: TRINIDAD-2010 URL: https://issues.apache.org/jira/browse/TRINIDAD-2010 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha-2 Reporter: Max Starets Assignee: Max Starets Attachments: trinidad2010.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-2010) Agent's support for web crawlers should include Oracle SES
[ https://issues.apache.org/jira/browse/TRINIDAD-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2010: -- Resolution: Fixed Fix Version/s: 2.0.0-beta-1 Status: Resolved (was: Patch Available) Agent's support for web crawlers should include Oracle SES -- Key: TRINIDAD-2010 URL: https://issues.apache.org/jira/browse/TRINIDAD-2010 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha-2 Reporter: Max Starets Assignee: Max Starets Fix For: 2.0.0-beta-1 Attachments: trinidad2010.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-2008) tr:panelBorderLayout is throwing exception with Mojarra during tag execution
tr:panelBorderLayout is throwing exception with Mojarra during tag execution Key: TRINIDAD-2008 URL: https://issues.apache.org/jira/browse/TRINIDAD-2008 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha-2 Environment: Mojarra 2.0.4, WLS Reporter: Max Starets To reproduce the issue, try running the following test.xhtml page: f:view xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; tr:document tr:form tr:panelBorderLayout/ /tr:form /tr:document /f:view You will notice java.lang.ExceptionInInitializerError at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.clinit(PanelBorderLayoutRenderer.java:1102) The root cause is the following exception: java.lang.NullPointerException at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:171) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.init(NamedLocaleInfoScriptlet.java:62) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.registerNamedLocales(NamedLocaleInfoScriptlet.java:47) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.XhtmlScriptletFactory.registerAllScriptlets(XhtmlScriptletFactory.java:73) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlUtils.clinit(XhtmlUtils.java:825) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.clinit(PanelBorderLayoutRenderer.java:1102) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.apache.myfaces.trinidadinternal.renderkit.ClassRendererInstantiator.instantiate(ClassRendererInstantiator.java:49) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.findRenderer(RenderKitBase.java:167) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:104) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:114) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.getRenderer(RenderKitBase.java:129) at com.sun.faces.application.ApplicationImpl.applyAnnotations(ApplicationImpl.java:1915) at com.sun.faces.application.ApplicationImpl.createComponentApplyAnnotations(ApplicationImpl.java:1864) at com.sun.faces.application.ApplicationImpl.createComponent(ApplicationImpl.java:1125) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.createComponent(ComponentTagHandlerDelegateImpl.java:513) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:153) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:94) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:163) at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:89) at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:79) at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:148) at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:740) at
[jira] Reopened: (TRINIDAD-2008) tr:panelBorderLayout is throwing exception with Mojarra during tag execution
[ https://issues.apache.org/jira/browse/TRINIDAD-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets reopened TRINIDAD-2008: --- I am seeing it with the latest build tr:panelBorderLayout is throwing exception with Mojarra during tag execution Key: TRINIDAD-2008 URL: https://issues.apache.org/jira/browse/TRINIDAD-2008 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha-2 Environment: Mojarra 2.0.4, WLS Reporter: Max Starets To reproduce the issue, try running the following test.xhtml page: f:view xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; tr:document tr:form tr:panelBorderLayout/ /tr:form /tr:document /f:view You will notice java.lang.ExceptionInInitializerError at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.clinit(PanelBorderLayoutRenderer.java:1102) The root cause is the following exception: java.lang.NullPointerException at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:171) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.init(NamedLocaleInfoScriptlet.java:62) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.registerNamedLocales(NamedLocaleInfoScriptlet.java:47) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.XhtmlScriptletFactory.registerAllScriptlets(XhtmlScriptletFactory.java:73) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlUtils.clinit(XhtmlUtils.java:825) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.clinit(PanelBorderLayoutRenderer.java:1102) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.apache.myfaces.trinidadinternal.renderkit.ClassRendererInstantiator.instantiate(ClassRendererInstantiator.java:49) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.findRenderer(RenderKitBase.java:167) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:104) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:114) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.getRenderer(RenderKitBase.java:129) at com.sun.faces.application.ApplicationImpl.applyAnnotations(ApplicationImpl.java:1915) at com.sun.faces.application.ApplicationImpl.createComponentApplyAnnotations(ApplicationImpl.java:1864) at com.sun.faces.application.ApplicationImpl.createComponent(ApplicationImpl.java:1125) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.createComponent(ComponentTagHandlerDelegateImpl.java:513) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:153) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:94) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:163) at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:89) at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:79) at
[jira] Updated: (TRINIDAD-2008) tr:panelBorderLayout is throwing exception with Mojarra during tag execution
[ https://issues.apache.org/jira/browse/TRINIDAD-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2008: -- Status: Patch Available (was: Reopened) tr:panelBorderLayout is throwing exception with Mojarra during tag execution Key: TRINIDAD-2008 URL: https://issues.apache.org/jira/browse/TRINIDAD-2008 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha-2 Environment: Mojarra 2.0.4, WLS Reporter: Max Starets Assignee: Max Starets Attachments: TRINIDAD-2002.patch To reproduce the issue, try running the following test.xhtml page: f:view xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; tr:document tr:form tr:panelBorderLayout/ /tr:form /tr:document /f:view You will notice java.lang.ExceptionInInitializerError at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.clinit(PanelBorderLayoutRenderer.java:1102) The root cause is the following exception: java.lang.NullPointerException at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:171) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.init(NamedLocaleInfoScriptlet.java:62) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.registerNamedLocales(NamedLocaleInfoScriptlet.java:47) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.XhtmlScriptletFactory.registerAllScriptlets(XhtmlScriptletFactory.java:73) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlUtils.clinit(XhtmlUtils.java:825) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.clinit(PanelBorderLayoutRenderer.java:1102) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.apache.myfaces.trinidadinternal.renderkit.ClassRendererInstantiator.instantiate(ClassRendererInstantiator.java:49) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.findRenderer(RenderKitBase.java:167) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:104) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:114) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.getRenderer(RenderKitBase.java:129) at com.sun.faces.application.ApplicationImpl.applyAnnotations(ApplicationImpl.java:1915) at com.sun.faces.application.ApplicationImpl.createComponentApplyAnnotations(ApplicationImpl.java:1864) at com.sun.faces.application.ApplicationImpl.createComponent(ApplicationImpl.java:1125) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.createComponent(ComponentTagHandlerDelegateImpl.java:513) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:153) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:94) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:163) at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:89) at
[jira] Updated: (TRINIDAD-2008) tr:panelBorderLayout is throwing exception with Mojarra during tag execution
[ https://issues.apache.org/jira/browse/TRINIDAD-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2008: -- Resolution: Fixed Fix Version/s: 2.0.0-beta-1 Status: Resolved (was: Patch Available) tr:panelBorderLayout is throwing exception with Mojarra during tag execution Key: TRINIDAD-2008 URL: https://issues.apache.org/jira/browse/TRINIDAD-2008 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha-2 Environment: Mojarra 2.0.4, WLS Reporter: Max Starets Assignee: Max Starets Fix For: 2.0.0-beta-1 Attachments: TRINIDAD-2002.patch To reproduce the issue, try running the following test.xhtml page: f:view xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; tr:document tr:form tr:panelBorderLayout/ /tr:form /tr:document /f:view You will notice java.lang.ExceptionInInitializerError at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.clinit(PanelBorderLayoutRenderer.java:1102) The root cause is the following exception: java.lang.NullPointerException at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:171) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.init(NamedLocaleInfoScriptlet.java:62) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.registerNamedLocales(NamedLocaleInfoScriptlet.java:47) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.XhtmlScriptletFactory.registerAllScriptlets(XhtmlScriptletFactory.java:73) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlUtils.clinit(XhtmlUtils.java:825) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.clinit(PanelBorderLayoutRenderer.java:1102) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.apache.myfaces.trinidadinternal.renderkit.ClassRendererInstantiator.instantiate(ClassRendererInstantiator.java:49) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.findRenderer(RenderKitBase.java:167) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:104) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:114) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.getRenderer(RenderKitBase.java:129) at com.sun.faces.application.ApplicationImpl.applyAnnotations(ApplicationImpl.java:1915) at com.sun.faces.application.ApplicationImpl.createComponentApplyAnnotations(ApplicationImpl.java:1864) at com.sun.faces.application.ApplicationImpl.createComponent(ApplicationImpl.java:1125) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.createComponent(ComponentTagHandlerDelegateImpl.java:513) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:153) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:94) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:163) at
[jira] Commented: (TRINIDAD-1960) NullPointerException in LocaleInfoScriptlet.getSupportedLocaleVariant
[ https://issues.apache.org/jira/browse/TRINIDAD-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12981931#action_12981931 ] Max Starets commented on TRINIDAD-1960: --- The fix for TRINIDAD-2008 on the trunk would probably work here as well NullPointerException in LocaleInfoScriptlet.getSupportedLocaleVariant - Key: TRINIDAD-1960 URL: https://issues.apache.org/jira/browse/TRINIDAD-1960 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.14-core Environment: Mac OS X 10.6, Java 6, Glassfish 3.0.2 Reporter: Manuel Blechschmidt Attachments: PreventNullPointerInLocaleInfoScroptlet.patch Hi, I tried to deploy trinidad in a web app to my Glassfish Server. After reporting and fixing TRINIDAD-1959 I get the following problem: Caused by: java.lang.NullPointerException at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:171) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.init(NamedLocaleInfoScriptlet.java:62) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.registerNamedLocales(NamedLocaleInfoScriptlet.java:47) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.XhtmlScriptletFactory.registerAllScriptlets(XhtmlScriptletFactory.java:73) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlUtils.clinit(XhtmlUtils.java:598) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.clinit(PanelBorderLayoutRenderer.java:1050) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at org.apache.myfaces.extensions.validator.generic.renderkit.ExtValGenericRenderKit.intercept(ExtValGenericRenderKit.java:84) at org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit$$EnhancerByCGLIB$$30834978.addRenderer(generated) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase._loadRenderKitMap(RenderKitBase.java:258) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.init(RenderKitBase.java:56) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.init(RenderKitDecorator.java:39) at org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit.init(CoreRenderKit.java:168) at org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit$$EnhancerByCGLIB$$30834978.init(generated) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:228) at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:220) at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:216) at net.sf.cglib.proxy.Enhancer.createUsingReflection(Enhancer.java:640) at net.sf.cglib.proxy.Enhancer.firstInstance(Enhancer.java:538) at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:225) at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377) at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:285) at org.apache.myfaces.extensions.validator.generic.renderkit.ExtValGenericRenderKit.newInstance(ExtValGenericRenderKit.java:62) at org.apache.myfaces.extensions.validator.generic.renderkit.GenericRenderKitWrapperFactory.createWrapper(GenericRenderKitWrapperFactory.java:45) at org.apache.myfaces.extensions.validator.core.renderkit.DefaultRenderKitWrapperFactory.createWrapper(DefaultRenderKitWrapperFactory.java:54) at org.apache.myfaces.extensions.validator.core.renderkit.ExtValRenderKitFactory.getRenderKit(ExtValRenderKitFactory.java:84) at org.apache.myfaces.trinidadinternal.renderkit.CoreRenderKitFactory.getRenderKit(CoreRenderKitFactory.java:55) at com.sun.faces.config.processor.RenderKitConfigProcessor.process(RenderKitConfigProcessor.java:170) at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:114) at com.sun.faces.config.processor.ManagedBeanConfigProcessor.process(ManagedBeanConfigProcessor.java:270) at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:114) at
[jira] Updated: (TRINIDAD-2002) TrinidadFilterImpl FacesContext initialization
[ https://issues.apache.org/jira/browse/TRINIDAD-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2002: -- Resolution: Fixed Fix Version/s: 2.0.0.3-core Status: Resolved (was: Patch Available) patch committed. TrinidadFilterImpl FacesContext initialization -- Key: TRINIDAD-2002 URL: https://issues.apache.org/jira/browse/TRINIDAD-2002 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.0-alpha Reporter: Andy Schwartz Priority: Minor Fix For: 2.0.0.3-core Attachments: TRINIDAD-2002.patch ADF Faces hooks into Trinidad's TrinidadFilterImpl sub-filter service and uses this to perform early configuration/initialization work. In particular, we use the ApplicationFactory to get at the Application instance and then create/add converters to the Application. This works fine on Mojarra 2.0.x releases. However, this fails in both: - MyFaces 2.0.x - Mojarra 2.1.x In both cases, the reason for the failure is that access to the FacesContext is required but is not yet available. In MyFaces 2.0.x, the FacesContext/ExternalContext is required by Application.createConverter()/setConverterProperties() in order to determine the value of the javax.faces.DATETIMECONVERTER_DEFAULT_TIMEZONE_IS_SYSTEM_TIMEZONE context parameter. In Mojarra 2.1.x, the ApplicationFactory requires access to the FacesContext in order to create the Application instance. While we can work around this issue at the ADF Faces level, TrinidadFilterImpl is already well positioned to address this - ie. TrinidadFilterImpl has access to the PseudoFacesContext and already sets this up for other cases (eg. for Configurator.beginRequest()). I am logging this issue to request that we take advantage of the existing support that TrinidadFilterImpl/PseudoFacesContext provides for early FacesContext access and extend this to TrinidadFilterImpl.init(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1764) System event listener state saving
[ https://issues.apache.org/jira/browse/TRINIDAD-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1764: -- Resolution: Fixed Fix Version/s: 2.0.0.3-core Status: Resolved (was: Patch Available) System event listener state saving -- Key: TRINIDAD-1764 URL: https://issues.apache.org/jira/browse/TRINIDAD-1764 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-alpha Reporter: Andy Schwartz Assignee: Max Starets Fix For: 2.0.0.3-core Attachments: trinidad-1764.patch The JSF specification requires that UIComponent provide implementations for the following new system event-related methods: - subscribeToEvent() - unsubscribeFromEvent() - getListenersForEventClass() Both Mojarra and MyFaces provide implementations of these methods in UIComponent. However, UIComponent itself does not provide any state saving implementation. This is provided by UIComponentBase - ie. UIComponentBase handles state saving for system event listeners stored on the UIComponent instance. This approach is flawed in that it only provides correct behavior for component implementations that extend UIComponentBase. Components that extend UIComponent directly will be subtly broken in that system event listeners can be registered, but will not be state saved. Furthermore, since the system event listener storage in UIComponent is package-private, there is no way for components that extend UIComponent directly to handle state saving for registered listeners. The only option is for components that extend UIComponent directly to implement their own (redundant) storage for system event listeners so that the component implementation can provide its own state saving implementation. Since all of the Trinidad components extend UIComponent (not UIComponentBase), we'll need to implement such a solution in UIXComponentBase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1764) System event listener state saving
[ https://issues.apache.org/jira/browse/TRINIDAD-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969517#action_12969517 ] Max Starets commented on TRINIDAD-1764: --- Storing component's system event handlers and implementing their state management is extremely similar to dealing with ClientBehaviors. When we implemented storage and state management for ClientBehaviors, we added new ClientBehavior-specific methods to the FacesBean (addClientBehavior(), getClientBehaviors()). Rather than adding new methods on the FacesBean for dealing with SystemEventHandlers, I am proposing to generalize handling of the 'attached' objects in Trinidad components: - Methods specific to ClientBehaviors should be removed from FacesBean. We probably should not have put them their to begin with, since FacesBean is meant to be used for more than just components. - A new parametrized AttachedObject class will replace BehvaiorMap. AttachedObject will be managing both ClientBeahaviors and SystemEventListeners. - UIXComponentBase will be storing AttachedObject instances on the FacesBean as regular properties using indexed PropertyKeys. - Our PropertyMap implementations do not currently 'descend' into property values for markInitialState() and clearInitialState(). Since attached objects require PartialStateHolder processing, we actually need to process properties representing attached ClientBehaviors and SystemEventListeners. To deal with this case, I added CAP_PARTIAL_STATE_HOLDER capability. Rather then iterate over every property to check for the new capability, I am tracking properties with the CAP_PARTIAL_STATE_HOLDER capability in a bitmask (see the new PropertyTracker class). Note that the changes to FacesBean will be modifying our API. System event listener state saving -- Key: TRINIDAD-1764 URL: https://issues.apache.org/jira/browse/TRINIDAD-1764 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-alpha Reporter: Andy Schwartz Assignee: Max Starets Attachments: trinidad-1764.patch The JSF specification requires that UIComponent provide implementations for the following new system event-related methods: - subscribeToEvent() - unsubscribeFromEvent() - getListenersForEventClass() Both Mojarra and MyFaces provide implementations of these methods in UIComponent. However, UIComponent itself does not provide any state saving implementation. This is provided by UIComponentBase - ie. UIComponentBase handles state saving for system event listeners stored on the UIComponent instance. This approach is flawed in that it only provides correct behavior for component implementations that extend UIComponentBase. Components that extend UIComponent directly will be subtly broken in that system event listeners can be registered, but will not be state saved. Furthermore, since the system event listener storage in UIComponent is package-private, there is no way for components that extend UIComponent directly to handle state saving for registered listeners. The only option is for components that extend UIComponent directly to implement their own (redundant) storage for system event listeners so that the component implementation can provide its own state saving implementation. Since all of the Trinidad components extend UIComponent (not UIComponentBase), we'll need to implement such a solution in UIXComponentBase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1764) System event listener state saving
[ https://issues.apache.org/jira/browse/TRINIDAD-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1764: -- Status: Patch Available (was: Open) System event listener state saving -- Key: TRINIDAD-1764 URL: https://issues.apache.org/jira/browse/TRINIDAD-1764 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-alpha Reporter: Andy Schwartz Assignee: Max Starets Attachments: trinidad-1764.patch The JSF specification requires that UIComponent provide implementations for the following new system event-related methods: - subscribeToEvent() - unsubscribeFromEvent() - getListenersForEventClass() Both Mojarra and MyFaces provide implementations of these methods in UIComponent. However, UIComponent itself does not provide any state saving implementation. This is provided by UIComponentBase - ie. UIComponentBase handles state saving for system event listeners stored on the UIComponent instance. This approach is flawed in that it only provides correct behavior for component implementations that extend UIComponentBase. Components that extend UIComponent directly will be subtly broken in that system event listeners can be registered, but will not be state saved. Furthermore, since the system event listener storage in UIComponent is package-private, there is no way for components that extend UIComponent directly to handle state saving for registered listeners. The only option is for components that extend UIComponent directly to implement their own (redundant) storage for system event listeners so that the component implementation can provide its own state saving implementation. Since all of the Trinidad components extend UIComponent (not UIComponentBase), we'll need to implement such a solution in UIXComponentBase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2973) UIComponent.unsubscribeFromEvent calls getApplication().unsubscribeFromEvent() instead of modifying _systemEventListenerClassMap
UIComponent.unsubscribeFromEvent calls getApplication().unsubscribeFromEvent() instead of modifying _systemEventListenerClassMap Key: MYFACES-2973 URL: https://issues.apache.org/jira/browse/MYFACES-2973 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.3-SNAPSHOT Reporter: Max Starets UIComponent.unsubscribeFromEvent() calls getFacesContext().getApplication().unsubscribeFromEvent(), while the event listener added by subscribeToEvent() still remains in _systemEventListenerClassMap. This means that the component system event listener cannot be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1948) Trinidad's Agent API Should Support Detection of Web Crawlers
[ https://issues.apache.org/jira/browse/TRINIDAD-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1948: -- Resolution: Fixed Fix Version/s: 2.0.0.3-core Status: Resolved (was: Patch Available) Trinidad's Agent API Should Support Detection of Web Crawlers - Key: TRINIDAD-1948 URL: https://issues.apache.org/jira/browse/TRINIDAD-1948 Project: MyFaces Trinidad Issue Type: New Feature Affects Versions: 2.0.0.3-core Reporter: Max Starets Assignee: Max Starets Fix For: 2.0.0.3-core Attachments: trinidad-1948.patch We should add support for detecting web crawlers at runtime. This would allow page authors to generate special content for the search engines, and would enable us in the future to implement a special rendering mode if we choose to do so. Proposal: - Add new TYPE_WEBCRAWLER Agent type - Add AGENT_GOOGLEBOT and AGENT_MSNBOT agents - Use the desktop rendering kit and the default output mode when generating content for web crawlers (for now). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1948) Trinidad's Agent API Should Support Detection of Web Crawlers
Trinidad's Agent API Should Support Detection of Web Crawlers - Key: TRINIDAD-1948 URL: https://issues.apache.org/jira/browse/TRINIDAD-1948 Project: MyFaces Trinidad Issue Type: New Feature Affects Versions: 2.0.0.3-core Reporter: Max Starets Assignee: Max Starets We should add support for detecting web crawlers at runtime. This would allow page authors to generate special content for the search engines, and would enable us in the future to implement a special rendering mode if we choose to do so. Proposal: - Add new TYPE_WEBCRAWLER Agent type - Add AGENT_GOOGLEBOT and AGENT_MSNBOT agents - Use the desktop rendering kit and the default output mode when generating content for web crawlers (for now). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1948) Trinidad's Agent API Should Support Detection of Web Crawlers
[ https://issues.apache.org/jira/browse/TRINIDAD-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1948: -- Status: Patch Available (was: Open) Trinidad's Agent API Should Support Detection of Web Crawlers - Key: TRINIDAD-1948 URL: https://issues.apache.org/jira/browse/TRINIDAD-1948 Project: MyFaces Trinidad Issue Type: New Feature Affects Versions: 2.0.0.3-core Reporter: Max Starets Assignee: Max Starets We should add support for detecting web crawlers at runtime. This would allow page authors to generate special content for the search engines, and would enable us in the future to implement a special rendering mode if we choose to do so. Proposal: - Add new TYPE_WEBCRAWLER Agent type - Add AGENT_GOOGLEBOT and AGENT_MSNBOT agents - Use the desktop rendering kit and the default output mode when generating content for web crawlers (for now). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1942) ViewDeclarationLanguageFactoryImpl implementation should cache physical URI for the current viewId on the ViewMap
[ https://issues.apache.org/jira/browse/TRINIDAD-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1942: -- Resolution: Fixed Fix Version/s: 2.0.0.3-core Status: Resolved (was: Patch Available) ViewDeclarationLanguageFactoryImpl implementation should cache physical URI for the current viewId on the ViewMap - Key: TRINIDAD-1942 URL: https://issues.apache.org/jira/browse/TRINIDAD-1942 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-alpha-2 Reporter: Pavitra Subramaniam Fix For: 2.0.0.3-core Attachments: jira-1942-II.patch, jira-1942.patch In an included page (or fragment) if a composite component gets used, the CompositeComponentTagHandler retrieves the logical viewId (context.getViewRoot().getViewId()) first and then gets its physical URI in order to determine the VDL to use. This is usually not a problem in vanilla JSF applications or even vanilla Trinidad applications, but in frameworks (such as Oracle) where the viewId of an included fragment comes into play (iow, the fragment is in context and not the main page), the PageResolver implementation can no longer return the correct physical URI for the logical viewId. It merely returns the logical viewId. The problem is further exasperated if the logical viewId of the page does not contain an extension. As there is no extension available, the VDL returned is the JspViewHandlingStrategy always. This is disastrous when the page is being rendered using FaceletsVDL. One way to resolve this issue is to cache the physical URI of the page on the ViewRoot's viewMap and return the cached value whenever the VDLFactory.getVDL() is called for a viewId that matches the current viewRoot's viewId. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1942) ViewDeclarationLanguageFactoryImpl implementation should cache physical URI for the current viewId on the ViewMap
[ https://issues.apache.org/jira/browse/TRINIDAD-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12922970#action_12922970 ] Max Starets commented on TRINIDAD-1942: --- +1 for the patch, but the second FacesContext.getCurrentInstance() lookup in getViewDeclarationLanguage() should be removed. ViewDeclarationLanguageFactoryImpl implementation should cache physical URI for the current viewId on the ViewMap - Key: TRINIDAD-1942 URL: https://issues.apache.org/jira/browse/TRINIDAD-1942 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-alpha-2 Reporter: Pavitra Subramaniam Attachments: jira-1942.patch In an included page (or fragment) if a composite component gets used, the CompositeComponentTagHandler retrieves the logical viewId (context.getViewRoot().getViewId()) first and then gets its physical URI in order to determine the VDL to use. This is usually not a problem in vanilla JSF applications or even vanilla Trinidad applications, but in frameworks (such as Oracle) where the viewId of an included fragment comes into play (iow, the fragment is in context and not the main page), the PageResolver implementation can no longer return the correct physical URI for the logical viewId. It merely returns the logical viewId. The problem is further exasperated if the logical viewId of the page does not contain an extension. As there is no extension available, the VDL returned is the JspViewHandlingStrategy always. This is disastrous when the page is being rendered using FaceletsVDL. One way to resolve this issue is to cache the physical URI of the page on the ViewRoot's viewMap and return the cached value whenever the VDLFactory.getVDL() is called for a viewId that matches the current viewRoot's viewId. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1938) RowKeyPropertyModel and RowKeyPropertyTreeModel
[ https://issues.apache.org/jira/browse/TRINIDAD-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12922563#action_12922563 ] Max Starets commented on TRINIDAD-1938: --- +1 on promoting these classes to org.apache.myfaces.trinidad.model I think I would add asserts for (rowKeyProperty != null ) before each __resolveProperty call. RowKeyPropertyModel and RowKeyPropertyTreeModel --- Key: TRINIDAD-1938 URL: https://issues.apache.org/jira/browse/TRINIDAD-1938 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.0.3-core Environment: All Reporter: Kamran Kashanian Attachments: rowkeymodel.patch By default, when Java Lists/Arrays are used as models in Trinidad table/tree/treeTable components, they are wrapped in a SortableModel instance. The problem with SortableModel is that it uses row indexes as row keys. This makes SortableModel immutable and insert/delete operations in the underlying List/array can cause problems. For example, indexes shift after insert/delete operations and can cause problems if the component is holding on to row keys in SelectedRowKey/DisclosedRowKey sets. The proposal is to add row key based CollectionModel/TreeModels which avoid using indexes as row keys. Attaching a patch for a RowKeyPropertyModel and a RowKeyPropertyTreeModel. RowKeyPropertyModel takes a rowKeyProperty name which identifies the unique row key in each model row by name. The setRowKey/getRowKey etc APIs use the rowKeyProperty to reference the row key attribute. One drawback with the default implementation of setRowKey API in RowKeyPropertyModel is that it is inefficient and does a linear search through the model to find the row with the given row key. The search can be optimized in subclasses for specific model implementations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (TRINIDAD-1824) CollectionUtils._checkSerialization should not throw exceptions for null values
[ https://issues.apache.org/jira/browse/TRINIDAD-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets reopened TRINIDAD-1824: --- This change was inadvertently removed in revision 980996 CollectionUtils._checkSerialization should not throw exceptions for null values --- Key: TRINIDAD-1824 URL: https://issues.apache.org/jira/browse/TRINIDAD-1824 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Max Starets Assignee: Max Starets Priority: Minor Attachments: trinidad-1824.patch To reproduce the issue, enable serialization checking (-Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=all ), and store a null value on the session map (whcih is legal). We need to modify CollectionUtils._checkSerialization() to not throw exceptions for null values. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1911) partialTriggers are ignore when JSF2 issues an ajax request
[
https://issues.apache.org/jira/browse/TRINIDAD-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908803#action_12908803
]
Max Starets commented on TRINIDAD-1911:
---
I believe the plan was to do add the listeners when processEvent() is called
with a PostRestoreStateEvent
partialTriggers are ignore when JSF2 issues an ajax request
---
Key: TRINIDAD-1911
URL: https://issues.apache.org/jira/browse/TRINIDAD-1911
Project: MyFaces Trinidad
Issue Type: Bug
Reporter: Matthias Weßendorf
Take the following snippet:
as you type, you are issuing ajax requests. However the tr:outputText is
not getting updated:
?xml version=1.0 encoding=iso-8859-1 standalone=yes ?
ui:composition xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:tr=http://myfaces.apache.org/trinidad;
xmlns:trd=http://myfaces.apache.org/trinidad/demo;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
tr:document title=Partial Page Rendering Demos
tr:form partialTriggers=ifsbc1
tr:panelFormLayout
tr:inputText id=ajax label=Field 1:
f:ajax event=keyup /
/tr:inputText
p
tr:outputText id=foo partialTriggers=ajax
value=#{requestScope} /
/p
/tr:panelFormLayout
/tr:form
/tr:document
/ui:composition
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1911) partialTriggers are ignore when JSF2 issues an ajax request
[
https://issues.apache.org/jira/browse/TRINIDAD-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908138#action_12908138
]
Max Starets commented on TRINIDAD-1911:
---
This is a known issue. We add partial trigger listeners during decode, and
decode is not happening for outputText id=foo unless you use execute=@all
or execute=foo. The plan was to use PostRestoreViewEvent handling on the
component to add partial triggers. However, this got delayed due to
PostRestoreViewEvent issues. We need to re-evaluate it again now.
partialTriggers are ignore when JSF2 issues an ajax request
---
Key: TRINIDAD-1911
URL: https://issues.apache.org/jira/browse/TRINIDAD-1911
Project: MyFaces Trinidad
Issue Type: Bug
Reporter: Matthias Weßendorf
Take the following snippet:
as you type, you are issuing ajax requests. However the tr:outputText is
not getting updated:
?xml version=1.0 encoding=iso-8859-1 standalone=yes ?
ui:composition xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:tr=http://myfaces.apache.org/trinidad;
xmlns:trd=http://myfaces.apache.org/trinidad/demo;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
tr:document title=Partial Page Rendering Demos
tr:form partialTriggers=ifsbc1
tr:panelFormLayout
tr:inputText id=ajax label=Field 1:
f:ajax event=keyup /
/tr:inputText
p
tr:outputText id=foo partialTriggers=ajax
value=#{requestScope} /
/p
/tr:panelFormLayout
/tr:form
/tr:document
/ui:composition
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1847) processFlattenedChildren should treat UIPanel and UINamingContainer as FlattenedComponents
[ https://issues.apache.org/jira/browse/TRINIDAD-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1847: -- Status: Resolved (was: Patch Available) Fix Version/s: 2.0.0.3-core Resolution: Fixed processFlattenedChildren should treat UIPanel and UINamingContainer as FlattenedComponents -- Key: TRINIDAD-1847 URL: https://issues.apache.org/jira/browse/TRINIDAD-1847 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0.3-core Reporter: Max Starets Assignee: Max Starets Fix For: 2.0.0.3-core Attachments: trinidad-1847.patch Since UIPanel and UINaming container do not render any DOM, we should make it easy for renderers to retrieve flattened children wrapped by these components. This became more critical after JSF2 started supporting multiple components inside of f:facet bu wrapping them in a UIPanel. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1847) processFlattenedChildren should treat UIPanel and UINamingContainer as FlattenedComponents
processFlattenedChildren should treat UIPanel and UINamingContainer as FlattenedComponents -- Key: TRINIDAD-1847 URL: https://issues.apache.org/jira/browse/TRINIDAD-1847 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0.3-core Reporter: Max Starets Since UIPanel and UINaming container do not render any DOM, we should make it easy for renderers to retrieve flattened children wrapped by these components. This became more critical after JSF2 started supporting multiple components inside of f:facet bu wrapping them in a UIPanel. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1847) processFlattenedChildren should treat UIPanel and UINamingContainer as FlattenedComponents
[ https://issues.apache.org/jira/browse/TRINIDAD-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1847: -- Status: Patch Available (was: Open) processFlattenedChildren should treat UIPanel and UINamingContainer as FlattenedComponents -- Key: TRINIDAD-1847 URL: https://issues.apache.org/jira/browse/TRINIDAD-1847 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0.3-core Reporter: Max Starets Attachments: trinidad-1847.patch Since UIPanel and UINaming container do not render any DOM, we should make it easy for renderers to retrieve flattened children wrapped by these components. This became more critical after JSF2 started supporting multiple components inside of f:facet bu wrapping them in a UIPanel. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1833) IE + PPR causing Hour-glass
[ https://issues.apache.org/jira/browse/TRINIDAD-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1833: -- Status: Patch Available (was: Open) IE + PPR causing Hour-glass - Key: TRINIDAD-1833 URL: https://issues.apache.org/jira/browse/TRINIDAD-1833 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.13-core Environment: OS: WinXP Trinidad v1.2.13 + myfaces v1.2.8 Browser: IE 7 or 8 Web server: Tomcat 6.0.24 Reporter: Dmitry Barsukov Assignee: Max Starets Attachments: trinidad-1833.patch Here is the simplest form below which does cause hour-glass cursor appearing and a form freezing when rendered on IE. Rick then left-left mouse click may help to switch the form back into a normal state. f:view xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; xmlns:trh=http://myfaces.apache.org/trinidad/html; trh:html trh:headtitlehour glass issue/title /trh:head trh:body tr:panelGroupLayout layout=vertical tr:form id=frm_1 tr:inputText label=Surname: id=it_1/ tr:commandButton id=cb_1 text=Search partialSubmit=true/ /tr:form /tr:panelGroupLayout /trh:body /trh:html /f:view To catch an issue you need to click inputText element several times quickly then commandButton then inputText element again. With this simplest form the issue is not that apparent. However if the form becomes more complicated hour-glass cursors spoils the whole application because it may appear VERY often, for instance on each third click in the form. If partialSubmit attribute is removed from tr:commandButton the issue disappears. Further information is available in mailing list with subject [Trinidad] IE + PPR causing Hour-glass -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1833) IE + PPR causing Hour-glass
[ https://issues.apache.org/jira/browse/TRINIDAD-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1833: -- Status: Resolved (was: Patch Available) Fix Version/s: 1.2.14-core Resolution: Fixed IE + PPR causing Hour-glass - Key: TRINIDAD-1833 URL: https://issues.apache.org/jira/browse/TRINIDAD-1833 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.13-core Environment: OS: WinXP Trinidad v1.2.13 + myfaces v1.2.8 Browser: IE 7 or 8 Web server: Tomcat 6.0.24 Reporter: Dmitry Barsukov Assignee: Max Starets Fix For: 1.2.14-core Attachments: trinidad-1833.patch Here is the simplest form below which does cause hour-glass cursor appearing and a form freezing when rendered on IE. Rick then left-left mouse click may help to switch the form back into a normal state. f:view xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; xmlns:trh=http://myfaces.apache.org/trinidad/html; trh:html trh:headtitlehour glass issue/title /trh:head trh:body tr:panelGroupLayout layout=vertical tr:form id=frm_1 tr:inputText label=Surname: id=it_1/ tr:commandButton id=cb_1 text=Search partialSubmit=true/ /tr:form /tr:panelGroupLayout /trh:body /trh:html /f:view To catch an issue you need to click inputText element several times quickly then commandButton then inputText element again. With this simplest form the issue is not that apparent. However if the form becomes more complicated hour-glass cursors spoils the whole application because it may appear VERY often, for instance on each third click in the form. If partialSubmit attribute is removed from tr:commandButton the issue disappears. Further information is available in mailing list with subject [Trinidad] IE + PPR causing Hour-glass -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1827) UIXColumn shoould support being added as a partial target (the table should be PPR-ed in that case).
[ https://issues.apache.org/jira/browse/TRINIDAD-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1827: -- Status: Resolved (was: Patch Available) Fix Version/s: 2.0.0.3-core Resolution: Fixed UIXColumn shoould support being added as a partial target (the table should be PPR-ed in that case). Key: TRINIDAD-1827 URL: https://issues.apache.org/jira/browse/TRINIDAD-1827 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Max Starets Fix For: 2.0.0.3-core Attachments: trinidad-1827.patch If the column is being PPR-ed, we have to PPR the entire table. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1810) Flash component needs public version of NumberConverter.is[Min/Max][Fraction/Integer]DigitsSet() apis
[ https://issues.apache.org/jira/browse/TRINIDAD-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1810: -- Status: Resolved (was: Patch Available) Fix Version/s: 2.0.0.3-core Resolution: Fixed Submitted to the trunk and the 1.2.12.3 branch. Flash component needs public version of NumberConverter.is[Min/Max][Fraction/Integer]DigitsSet() apis - Key: TRINIDAD-1810 URL: https://issues.apache.org/jira/browse/TRINIDAD-1810 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 1.2.14-core Environment: All Reporter: Diar Ahmed Priority: Blocker Fix For: 2.0.0.3-core Attachments: 1.2.12.3.patch, trunk.patch Original Estimate: 24h Remaining Estimate: 24h ADF Faces has a number of components ( Graph, Gauge, ... ) that accept NumberConverters in order to support number formatting. These converters can be used on the middle tier to support PNG generation, but for Flash based rendering, the NumberConverter's properties are read in the middle tier and pass down to an existing ActionScript number formatting engine. This JIRA is to support the ability to determine whether the the following properties are set on the NumberConverter and should be transferred to Actionscript: MinimumFractionDigits MaximumFractionDigits MinimumIntegerDigits MaximumIntegerDigits since by default, if these properties are not set, they always return 0, which is not the correct min/max fraction/integer digits used by the NumberConverter. Currently, the NumberConverter has protected methods that provide access to whether these properties are set: - protected boolean isMaximumFractionDigitsSet() - protected boolean isMinimumFractionDigitsSet() - protected boolean isMaximumIntegerDigitsSet() - protected boolean isMinimumIntegerDigitsSet() This JIRA is requesting that these APIs ( or alternate APIs ) are made public, to allow us to determine if these attributes are set and should be used when we perform ActionScript based formatting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1827) UIXColumn shoould support being added as a partial target (the table should be PPR-ed in that case).
[ https://issues.apache.org/jira/browse/TRINIDAD-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1827: -- Status: Patch Available (was: Open) UIXColumn shoould support being added as a partial target (the table should be PPR-ed in that case). Key: TRINIDAD-1827 URL: https://issues.apache.org/jira/browse/TRINIDAD-1827 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Max Starets Attachments: trinidad-1827.patch If the column is being PPR-ed, we have to PPR the entire table. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1824) CollectionUtils._checkSerialization should not throw exceptions for null values
[ https://issues.apache.org/jira/browse/TRINIDAD-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1824: -- Status: Resolved (was: Patch Available) Resolution: Fixed CollectionUtils._checkSerialization should not throw exceptions for null values --- Key: TRINIDAD-1824 URL: https://issues.apache.org/jira/browse/TRINIDAD-1824 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Max Starets Assignee: Max Starets Priority: Minor Attachments: trinidad-1824.patch To reproduce the issue, enable serialization checking (-Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=all ), and store a null value on the session map (whcih is legal). We need to modify CollectionUtils._checkSerialization() to not throw exceptions for null values. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1824) CollectionUtils._checkSerialization should not throw exceptions for null values
CollectionUtils._checkSerialization should not throw exceptions for null values --- Key: TRINIDAD-1824 URL: https://issues.apache.org/jira/browse/TRINIDAD-1824 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Max Starets Assignee: Max Starets Priority: Minor To reproduce the issue, enable serialization checking (-Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=all ), and store a null value on the session map (whcih is legal). We need to modify CollectionUtils._checkSerialization() to not throw exceptions for null values. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1824) CollectionUtils._checkSerialization should not throw exceptions for null values
[ https://issues.apache.org/jira/browse/TRINIDAD-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1824: -- Status: Patch Available (was: Open) CollectionUtils._checkSerialization should not throw exceptions for null values --- Key: TRINIDAD-1824 URL: https://issues.apache.org/jira/browse/TRINIDAD-1824 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Max Starets Assignee: Max Starets Priority: Minor Attachments: trinidad-1824.patch To reproduce the issue, enable serialization checking (-Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=all ), and store a null value on the session map (whcih is legal). We need to modify CollectionUtils._checkSerialization() to not throw exceptions for null values. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1820) JSF2 Ajax: View State input field gets recreated on every Ajax request in IE7
JSF2 Ajax: View State input field gets recreated on every Ajax request in IE7 - Key: TRINIDAD-1820 URL: https://issues.apache.org/jira/browse/TRINIDAD-1820 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Max Starets Assignee: Max Starets This JIRA is to track fixes in Trinidad's legacy PPR implementation. I entered the following Mojarra issue to track work in the jsf.ajax implementation: https://mojarra.dev.java.net/issues/show_bug.cgi?id=3 To reproduce the problem, use ajaxPPRDemos.xhtml and force legacy PPR implementation in web.xml: context-param param-nameorg.apache.myfaces.trinidadinternal.PPR_OVER_JSF_AJAX/param-name param-valueoff/param-value /context-param Run the page in IE7. Set a breakpoint in TrPage.prototype._updateViewState() where we create the input field. Note that the field gets recreated every time. This happens due to an IE bug. If the name attribute is set programmatically on the newly created input field, the field is not reported in the form.elements collection and is not found by document.getElementsById(). The workaround is to set both the name and the id attributes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1820) JSF2 Ajax: View State input field gets recreated on every Ajax request in IE7
[ https://issues.apache.org/jira/browse/TRINIDAD-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1820: -- Status: Resolved (was: Patch Available) Resolution: Fixed JSF2 Ajax: View State input field gets recreated on every Ajax request in IE7 - Key: TRINIDAD-1820 URL: https://issues.apache.org/jira/browse/TRINIDAD-1820 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Max Starets Assignee: Max Starets Attachments: trinidad-1820.patch This JIRA is to track fixes in Trinidad's legacy PPR implementation. I entered the following Mojarra issue to track work in the jsf.ajax implementation: https://mojarra.dev.java.net/issues/show_bug.cgi?id=3 To reproduce the problem, use ajaxPPRDemos.xhtml and force legacy PPR implementation in web.xml: context-param param-nameorg.apache.myfaces.trinidadinternal.PPR_OVER_JSF_AJAX/param-name param-valueoff/param-value /context-param Run the page in IE7. Set a breakpoint in TrPage.prototype._updateViewState() where we create the input field. Note that the field gets recreated every time. This happens due to an IE bug. If the name attribute is set programmatically on the newly created input field, the field is not reported in the form.elements collection and is not found by document.getElementsById(). The workaround is to set both the name and the id attributes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1820) JSF2 Ajax: View State input field gets recreated on every Ajax request in IE7
[ https://issues.apache.org/jira/browse/TRINIDAD-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1820: -- Status: Patch Available (was: Open) JSF2 Ajax: View State input field gets recreated on every Ajax request in IE7 - Key: TRINIDAD-1820 URL: https://issues.apache.org/jira/browse/TRINIDAD-1820 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Max Starets Assignee: Max Starets Attachments: trinidad-1820.patch This JIRA is to track fixes in Trinidad's legacy PPR implementation. I entered the following Mojarra issue to track work in the jsf.ajax implementation: https://mojarra.dev.java.net/issues/show_bug.cgi?id=3 To reproduce the problem, use ajaxPPRDemos.xhtml and force legacy PPR implementation in web.xml: context-param param-nameorg.apache.myfaces.trinidadinternal.PPR_OVER_JSF_AJAX/param-name param-valueoff/param-value /context-param Run the page in IE7. Set a breakpoint in TrPage.prototype._updateViewState() where we create the input field. Note that the field gets recreated every time. This happens due to an IE bug. If the name attribute is set programmatically on the newly created input field, the field is not reported in the form.elements collection and is not found by document.getElementsById(). The workaround is to set both the name and the id attributes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1820) JSF2 Ajax: View State input field gets recreated on every Ajax request in IE7
[ https://issues.apache.org/jira/browse/TRINIDAD-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12874270#action_12874270 ] Max Starets commented on TRINIDAD-1820: --- The correct Mojarra issue is https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1695 JSF2 Ajax: View State input field gets recreated on every Ajax request in IE7 - Key: TRINIDAD-1820 URL: https://issues.apache.org/jira/browse/TRINIDAD-1820 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Max Starets Assignee: Max Starets Attachments: trinidad-1820.patch This JIRA is to track fixes in Trinidad's legacy PPR implementation. I entered the following Mojarra issue to track work in the jsf.ajax implementation: https://mojarra.dev.java.net/issues/show_bug.cgi?id=3 To reproduce the problem, use ajaxPPRDemos.xhtml and force legacy PPR implementation in web.xml: context-param param-nameorg.apache.myfaces.trinidadinternal.PPR_OVER_JSF_AJAX/param-name param-valueoff/param-value /context-param Run the page in IE7. Set a breakpoint in TrPage.prototype._updateViewState() where we create the input field. Note that the field gets recreated every time. This happens due to an IE bug. If the name attribute is set programmatically on the newly created input field, the field is not reported in the form.elements collection and is not found by document.getElementsById(). The workaround is to set both the name and the id attributes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1817) fileDownloadActionListeners needs to delay retrieving OutputStream from the response until something needs to be written to the stream
[ https://issues.apache.org/jira/browse/TRINIDAD-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1817: -- Status: Resolved (was: Patch Available) Resolution: Fixed Committed rev. 949196 fileDownloadActionListeners needs to delay retrieving OutputStream from the response until something needs to be written to the stream -- Key: TRINIDAD-1817 URL: https://issues.apache.org/jira/browse/TRINIDAD-1817 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Max Starets Assignee: Max Starets Attachments: trinidad-1817.patch The issue may be demonstrated by taking our fileDownloadActionListener demo and modifying it to run with Facelets. After you click on the 'Click for Error button, you will get an UnsupportedOperationException instead of the expected FacesMessage. The exception is thrown because we calling getOutputStream(), but not completing the response when we want to report an error. JSF later calls getWriter(), which is causing UnsupportedOperationException. This problem does not show up with JSPs because of the side effect of the JSP engine dispatch - getWriter() simply succeeds. The solution is to create a proxy OutputStream that retrieves the delegate stream only when it needs to write. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1817) fileDownloadActionListeners needs to delay retrieving OutputStream from the response until something needs to be written to the stream
fileDownloadActionListeners needs to delay retrieving OutputStream from the response until something needs to be written to the stream -- Key: TRINIDAD-1817 URL: https://issues.apache.org/jira/browse/TRINIDAD-1817 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Max Starets Assignee: Max Starets The issue may be demonstrated by taking our fileDownloadActionListener demo and modifying it to run with Facelets. After you click on the 'Click for Error button, you will get an UnsupportedOperationException instead of the expected FacesMessage. The exception is thrown because we calling getOutputStream(), but not completing the response when we want to report an error. JSF later calls getWriter(), which is causing UnsupportedOperationException. This problem does not show up with JSPs because of the side effect of the JSP engine dispatch - getWriter() simply succeeds. The solution is to create a proxy OutputStream that retrieves the delegate stream only when it needs to write. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1817) fileDownloadActionListeners needs to delay retrieving OutputStream from the response until something needs to be written to the stream
[ https://issues.apache.org/jira/browse/TRINIDAD-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1817: -- Status: Patch Available (was: Open) fileDownloadActionListeners needs to delay retrieving OutputStream from the response until something needs to be written to the stream -- Key: TRINIDAD-1817 URL: https://issues.apache.org/jira/browse/TRINIDAD-1817 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Max Starets Assignee: Max Starets Attachments: trinidad-1817.patch The issue may be demonstrated by taking our fileDownloadActionListener demo and modifying it to run with Facelets. After you click on the 'Click for Error button, you will get an UnsupportedOperationException instead of the expected FacesMessage. The exception is thrown because we calling getOutputStream(), but not completing the response when we want to report an error. JSF later calls getWriter(), which is causing UnsupportedOperationException. This problem does not show up with JSPs because of the side effect of the JSP engine dispatch - getWriter() simply succeeds. The solution is to create a proxy OutputStream that retrieves the delegate stream only when it needs to write. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1600) Trinidad2 - Dialog navigation clears View Scope
[ https://issues.apache.org/jira/browse/TRINIDAD-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1600: -- Status: Resolved (was: Patch Available) Assignee: Max Starets Fix Version/s: 2.0.0.3-core Resolution: Fixed Trinidad2 - Dialog navigation clears View Scope --- Key: TRINIDAD-1600 URL: https://issues.apache.org/jira/browse/TRINIDAD-1600 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha Environment: Trinidad 2.0 branch, JSF RI 2.0.0RC2 Reporter: Martin Koci Assignee: Max Starets Fix For: 2.0.0.3-core Attachments: patch.txt, patch2.txt, patch3.diff JSF 2.0 introduces new scope View Scope implemented with a Map UIViewRoot.viewMap. Spec also says that call FacesConfig.setViewRoot() clears that Map. Problem: Trinidad NavigationHandler uses method handleNavigation for detection if a dialog navigation will be performed - however that method creates new UIViewRoot and sets it to FacesContext - clears view scope. If user places managed bean into view scope and starts a dialog: navigation on that view, bean is removed and new instance of the bean is created after dialog return. Solution: use new JSF 2.0 ConfigurableNavigationHandler API -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1794) Possible settings bug in the web.xml of the 2.x Trinidad demos
[ https://issues.apache.org/jira/browse/TRINIDAD-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12859476#action_12859476 ] Max Starets commented on TRINIDAD-1794: --- Are you guys suggesting that we map *.jspx to Facelets in Trinidad? We have jsp-specific tags in those files (like jsp:root), and Trinidad does not provide Facelet handlers for those. These tags will appear in the rendered output as plain text, which will cause other problems. Until we convert all the samples to pure Facelets, I believe we should leave these jspx files mapped to the JSP engine. If the jsf.js script cannot be made available with JSPs, then we should be using the legacy PPR implementation for them, and f:ajax would be considered unsupported Possible settings bug in the web.xml of the 2.x Trinidad demos -- Key: TRINIDAD-1794 URL: https://issues.apache.org/jira/browse/TRINIDAD-1794 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha-2 Reporter: Werner Punz While investigating the Trinidad ppr demos I found following bugs: The Facelets View Mappins were set only to xhtml which then caused that jsf.js could not be included since it relies on having a valid head element that MyFaces failed due to a MyFaces 2 bug in conjunction of ppr + jspx (which will be further investigated) changing context-param param-namejavax.faces.FACELETS_VIEW_MAPPINGS/param-name param-value*.xhtml/param-value /context-param to context-param param-namejavax.faces.FACELETS_VIEW_MAPPINGS/param-name param-value*.xhtml;*.jspx/param-value /context-param Resolved both issues, I am not sure if the setting was intentional, on the 2.x preparation branch the setting was on, but along the way it got lost. I am adding this bug for documentation purposes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1790) Trinidad 2: Component Bindings are not executed during postback
Trinidad 2: Component Bindings are not executed during postback --- Key: TRINIDAD-1790 URL: https://issues.apache.org/jira/browse/TRINIDAD-1790 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Max Starets To reproduce, run testRelativePartialTriggers.jspx an click the first Make table Pink button. Note that the table component is being PPR-ed, but the inline style remains the same. This happens because 'table1' in the backing bean is null. The setter method never gets called. The most likely cause is the fact that JSF RI moved the code for binding execution out of the lifecycle implementation into the PostRestoreViewState event processing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1790) Trinidad 2: Component Bindings are not executed during postback
[ https://issues.apache.org/jira/browse/TRINIDAD-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12859045#action_12859045 ] Max Starets commented on TRINIDAD-1790: --- The issue only shows up if Trinidad view root caching is enabled. Trinidad 2: Component Bindings are not executed during postback --- Key: TRINIDAD-1790 URL: https://issues.apache.org/jira/browse/TRINIDAD-1790 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Max Starets To reproduce, run testRelativePartialTriggers.jspx an click the first Make table Pink button. Note that the table component is being PPR-ed, but the inline style remains the same. This happens because 'table1' in the backing bean is null. The setter method never gets called. The most likely cause is the fact that JSF RI moved the code for binding execution out of the lifecycle implementation into the PostRestoreViewState event processing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1770) Trinidad's ResponseWriterDecorator needs to avoid synchronization introduced by javax.faces.context.ResponseWriterWrapper
Trinidad's ResponseWriterDecorator needs to avoid synchronization introduced by javax.faces.context.ResponseWriterWrapper -- Key: TRINIDAD-1770 URL: https://issues.apache.org/jira/browse/TRINIDAD-1770 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Max Starets Since we moved to JSF 2.0, ResponseWriterDecorator extends javax.faces.context.ResponseWriterWrapper. The problem is that ResponseWriterWrapper does not override all ResponseWrapper methods. Non-overridden methods are handled by java.io.Writer, which uses synchronization. For example, write(String) will be calling into synchronized code in java.io.Writer.write(String). The solution will be to provide overrides in ResponseWriterDecorator for all ResponseWriter methods not overridden by ResponseWriterWrapper (at least until the ResponseWriterWrapper is fixed in JSF). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1760) Map returned from UIXComponentBase.getAttributes() is missing attributes set in restoreState()
[ https://issues.apache.org/jira/browse/TRINIDAD-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets resolved TRINIDAD-1760. --- Resolution: Fixed Fix Version/s: 2.0.0.3-core Fixed by Blake Sullivan in revision 924123 Map returned from UIXComponentBase.getAttributes() is missing attributes set in restoreState() -- Key: TRINIDAD-1760 URL: https://issues.apache.org/jira/browse/TRINIDAD-1760 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0.3-core Reporter: Max Starets Fix For: 2.0.0.3-core org.apache.myfaces.trinidad.bean.util.ValueMap is caching the set of Map entries (_entries member variable), and is assuming that the entries may be added/removed only by calling put()/remove(). However, UIXComponentBase.restoreState() adds new entries directly on the FacesBean, so the ValueMap does not know about these new entries. Basically, the current implementation of the ValueMap will cache the entry set too soon if UIXComponentBase.getAttributes() is called before the restored state is applied. This is precisely what is happening now after we started calling pushComponentToEL in processRestoreState(): (ValueMap.java:127) org.apache.myfaces.trinidad.bean.util.ValueMap$MakeEntries.init (ValueMap.java:101) org.apache.myfaces.trinidad.bean.util.ValueMap.entrySet (AbstractMap.java:123) java.util.AbstractMap.containsKey (UIComponent.java:1761) javax.faces.component.UIComponent.isCompositeComponent (UIComponent.java:1684) javax.faces.component.UIComponent.pushComponentToEL (UIXComponentBase.java:1073) org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState (TreeState.java:96) org.apache.myfaces.trinidad.component.TreeState.restoreState (UIXComponentBase.java:1080) org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState (AdfViewRoot.java:79) oracle.adfinternal.view.faces.component.AdfViewRoot.processRestoreState The stack shows where the entry set is being cached in the ValueMap. The attributes from the restored state are set on the FacesBean later,a nd are not reflected in the cached attribute map entry set. Possible fix: should we route UIXComponentBase.restoreState() through the ValueMap (instead of calling FacesBean directly), so that the ValueMap has a chance to clear its entry cache? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1760) Map returned from UIXComponentBase.getAttributes() is missing attributes set in restoreState()
Map returned from UIXComponentBase.getAttributes() is missing attributes set in restoreState() -- Key: TRINIDAD-1760 URL: https://issues.apache.org/jira/browse/TRINIDAD-1760 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0.3-core Reporter: Max Starets org.apache.myfaces.trinidad.bean.util.ValueMap is caching the set of Map entries (_entries member variable), and is assuming that the entries may be added/removed only by calling put()/remove(). However, UIXComponentBase.restoreState() adds new entries directly on the FacesBean, so the ValueMap does not know about these new entries. Basically, the current implementation of the ValueMap will cache the entry set too soon if UIXComponentBase.getAttributes() is called before the restored state is applied. This is precisely what is happening now after we started calling pushComponentToEL in processRestoreState(): (ValueMap.java:127) org.apache.myfaces.trinidad.bean.util.ValueMap$MakeEntries.init (ValueMap.java:101) org.apache.myfaces.trinidad.bean.util.ValueMap.entrySet (AbstractMap.java:123) java.util.AbstractMap.containsKey (UIComponent.java:1761) javax.faces.component.UIComponent.isCompositeComponent (UIComponent.java:1684) javax.faces.component.UIComponent.pushComponentToEL (UIXComponentBase.java:1073) org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState (TreeState.java:96) org.apache.myfaces.trinidad.component.TreeState.restoreState (UIXComponentBase.java:1080) org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState (AdfViewRoot.java:79) oracle.adfinternal.view.faces.component.AdfViewRoot.processRestoreState The stack shows where the entry set is being cached in the ValueMap. The attributes from the restored state are set on the FacesBean later,a nd are not reflected in the cached attribute map entry set. Possible fix: should we route UIXComponentBase.restoreState() through the ValueMap (instead of calling FacesBean directly), so that the ValueMap has a chance to clear its entry cache? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1749) Trinidad 2: UnsupportedOperationException during decode when h:form is on the page
Trinidad 2: UnsupportedOperationException during decode when h:form is on the page -- Key: TRINIDAD-1749 URL: https://issues.apache.org/jira/browse/TRINIDAD-1749 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-alpha-2 Reporter: Max Starets Assignee: Max Starets When a page has one of the basic HTML components (like h:form), decode will fail with the following exception: java.lang.UnsupportedOperationException at org.apache.myfaces.trinidadinternal.renderkit.htmlBasic.ComponentFacesBean.getClientBehaviors(ComponentFacesBean.java:180) at org.apache.myfaces.trinidad.render.CoreRenderer.decodeBehaviors(CoreRenderer.java:931) at org.apache.myfaces.trinidad.render.CoreRenderer.decode(CoreRenderer.java:242) at org.apache.myfaces.trinidadinternal.renderkit.htmlBasic.HtmlFormRenderer.decode(HtmlFormRenderer.java:44) at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:790) at javax.faces.component.UIForm.processDecodes(UIForm.java:205) The issue is that ComponentFacesBean does not delegate to the UIComponent's ClientBehaviorHolder -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1749) Trinidad 2: UnsupportedOperationException during decode when h:form is on the page
[ https://issues.apache.org/jira/browse/TRINIDAD-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets resolved TRINIDAD-1749. --- Resolution: Fixed Fix Version/s: 2.0.0-alpha-2 Trinidad 2: UnsupportedOperationException during decode when h:form is on the page -- Key: TRINIDAD-1749 URL: https://issues.apache.org/jira/browse/TRINIDAD-1749 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-alpha-2 Reporter: Max Starets Assignee: Max Starets Fix For: 2.0.0-alpha-2 When a page has one of the basic HTML components (like h:form), decode will fail with the following exception: java.lang.UnsupportedOperationException at org.apache.myfaces.trinidadinternal.renderkit.htmlBasic.ComponentFacesBean.getClientBehaviors(ComponentFacesBean.java:180) at org.apache.myfaces.trinidad.render.CoreRenderer.decodeBehaviors(CoreRenderer.java:931) at org.apache.myfaces.trinidad.render.CoreRenderer.decode(CoreRenderer.java:242) at org.apache.myfaces.trinidadinternal.renderkit.htmlBasic.HtmlFormRenderer.decode(HtmlFormRenderer.java:44) at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:790) at javax.faces.component.UIForm.processDecodes(UIForm.java:205) The issue is that ComponentFacesBean does not delegate to the UIComponent's ClientBehaviorHolder -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1735) Trinidad 2: Provide ViewDeclarationLanguageFactory wrapper instead of overriding ViewHandler.getViewDeclarationLanguage()
[ https://issues.apache.org/jira/browse/TRINIDAD-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1735: -- Status: Patch Available (was: Open) Trinidad 2: Provide ViewDeclarationLanguageFactory wrapper instead of overriding ViewHandler.getViewDeclarationLanguage() - Key: TRINIDAD-1735 URL: https://issues.apache.org/jira/browse/TRINIDAD-1735 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.2-core Reporter: Max Starets Assignee: Max Starets Attachments: trinidad-1735.diff We override ViewHandler.getViewDeclarationLanguage() to return null VDL for the internal views and to call inro PageResolver before determining the VDL. The problem is our override does not get called during ViewHandler.createView() because the delegate ViewHandler just calls getViewDeclarationLanguage on itself. This is not causing any serious problems today because both Facelets and JSP VDLs call into the same base implementation of createView(). However, the right solution will be to stop overriding getViewDeclarationLanguage() on the ViewHandler and start wrapping ViewDeclarationLanguageFactory instead, so we can start overriding getViewDeclarationLanguage() there. According to JavaDoc, ViewHandler.getViewDeclarationLanguage() is merely a convenience method. As such it should have been made final in the JSF API, and problems like these would be easily prevented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1735) Trinidad 2: Provide ViewDeclarationLanguageFactory wrapper instead of overriding ViewHandler.getViewDeclarationLanguage()
[ https://issues.apache.org/jira/browse/TRINIDAD-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839848#action_12839848 ] Max Starets commented on TRINIDAD-1735: --- Changing the priority to Major, as it turns out that ViewHandler.renderView() does not call our override either. Since we have to make the ViewDeclarationLanguageFactory aware of the InternalViews, it makes sense to move all logic related to the InternalViews from ViewHandlerImpl to the new ViewDeclarationLanguageFactoryImpl. This will allow us to expose InternalView handling as a VDL, which is a cleaner solution consistent with the JSF 2 architecture. The only issue is that ViewDeclarationLanguage does not expose writeState(0, so we will have to leave a minimal amount of the InternalView-related code in the ViewHandlerImpl. Trinidad 2: Provide ViewDeclarationLanguageFactory wrapper instead of overriding ViewHandler.getViewDeclarationLanguage() - Key: TRINIDAD-1735 URL: https://issues.apache.org/jira/browse/TRINIDAD-1735 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.2-core Reporter: Max Starets Assignee: Max Starets Attachments: trinidad-1735.diff We override ViewHandler.getViewDeclarationLanguage() to return null VDL for the internal views and to call inro PageResolver before determining the VDL. The problem is our override does not get called during ViewHandler.createView() because the delegate ViewHandler just calls getViewDeclarationLanguage on itself. This is not causing any serious problems today because both Facelets and JSP VDLs call into the same base implementation of createView(). However, the right solution will be to stop overriding getViewDeclarationLanguage() on the ViewHandler and start wrapping ViewDeclarationLanguageFactory instead, so we can start overriding getViewDeclarationLanguage() there. According to JavaDoc, ViewHandler.getViewDeclarationLanguage() is merely a convenience method. As such it should have been made final in the JSF API, and problems like these would be easily prevented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1735) Trinidad 2: Provide ViewDeclarationLanguageFactory wrapper instead of overriding ViewHandler.getViewDeclarationLanguage()
Trinidad 2: Provide ViewDeclarationLanguageFactory wrapper instead of overriding ViewHandler.getViewDeclarationLanguage() - Key: TRINIDAD-1735 URL: https://issues.apache.org/jira/browse/TRINIDAD-1735 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.2-core Reporter: Max Starets Priority: Minor We override ViewHandler.getViewDeclarationLanguage() to return null VDL for the internal views and to call inro PageResolver before determining the VDL. The problem is our override does not get called during ViewHandler.createView() because the delegate ViewHandler just calls getViewDeclarationLanguage on itself. This is not causing any serious problems today because both Facelets and JSP VDLs call into the same base implementation of createView(). However, the right solution will be to stop overriding getViewDeclarationLanguage() on the ViewHandler and start wrapping ViewDeclarationLanguageFactory instead, so we can start overriding getViewDeclarationLanguage() there. According to JavaDoc, ViewHandler.getViewDeclarationLanguage() is merely a convenience method. As such it should have been made final in the JSF API, and problems like these would be easily prevented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1723) Trinidad 2: ClassCastEXception while running componentDemos.jspx
[ https://issues.apache.org/jira/browse/TRINIDAD-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12834287#action_12834287 ] Max Starets commented on TRINIDAD-1723: --- The issue is that WLS is not loading faces-bean.properties from the impl jar, so we get a wrong FacesBean bean created for CorePanelPage. Prior to Blake's change (revision 901411), we had only one faces-bean.properties in the impl jar. That worked fine in both Jetty and WLS. Since 901411, we have two faces-bean.properties files - one in the impl jar, and one in the api. FacesBeanFactory._initializeBeanTypes() calls _getClassLoader().getResources( META-INF/faces-bean.properties); Jetty will return two URLs (one for faces-bean.properties in the api and one in impl), while WLS - only one (in the api). The behavior of WLS seems wrong to me. It looks like the faces-bean.properties is required for some unit tests in the API package. A temporary workaround for WLS would be to copy all entries from the impl's faces-bean.properties into the api's faces-bean.properties and building with tests disabled. Trinidad 2: ClassCastEXception while running componentDemos.jspx Key: TRINIDAD-1723 URL: https://issues.apache.org/jira/browse/TRINIDAD-1723 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-alpha-2 Reporter: Max Starets Grab the latest trinidad-2.0.x branch and try running componentDemos.jspx. The following exception will be thrown: java.lang.ClassCastException: org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode cannot be cast to org.apache.myfaces.trinidadinternal.uinode.UIXComponentUINode at org.apache.myfaces.trinidadinternal.uinode.UIXComponentUINode.__getAdapter(UIXComponentUINode.java:439) at org.apache.myfaces.trinidadinternal.uinode.UINodeRendererBase.encodeEnd(UINodeRendererBase.java:65) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:852) at org.apache.myfaces.trinidad.render.RenderUtils.encodeRecursive(RenderUtils.java:70) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:509) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:531) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer.renderContent(PanelPartialRootRenderer.java:70) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.BodyRenderer.renderContent(BodyRenderer.java:151) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer.encodeAll(PanelPartialRootRenderer.java:153) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.BodyRenderer.encodeAll(BodyRenderer.java:80) at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:546) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.DocumentRenderer.encodeAll(DocumentRenderer.java:82) This does not seem to be JSF 2 specific, but I have not had time to try it on the latest MAIN. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1722) Trinidad 2: Wrong locale rule used in skinng
[ https://issues.apache.org/jira/browse/TRINIDAD-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets resolved TRINIDAD-1722. --- Resolution: Fixed Fix Version/s: 2.0.0-alpha-2 Assignee: Max Starets Thanks for the patch, Andy Schwartz! Trinidad 2: Wrong locale rule used in skinng Key: TRINIDAD-1722 URL: https://issues.apache.org/jira/browse/TRINIDAD-1722 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.0.0-alpha-2 Reporter: Max Starets Assignee: Max Starets Fix For: 2.0.0-alpha-2 Attachments: trinidad-1722.patch To reproduce the issue, run table.jspx in Firefox with the latest 2.0.x branch. Notice that the font size is huge. For some strange reason, the skin picks up the following Thai locale rule in base-desktop.xss: !-- And on Thai Gecko - see bug 3897341 - bump the font size up -- styleSheet platforms=windows linux browsers=gecko locales=th style name=AFDefaultFontFamily property name=font-familyBrowallia New,Arial,Helvetica,Geneva,sans-serif/property property name=font-size16pt/property /style If you remove the rule, everything runs fine. If you use IE, it works fine too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1722) Trinidad 2: Wrong locale rule used in skinng
Trinidad 2: Wrong locale rule used in skinng Key: TRINIDAD-1722 URL: https://issues.apache.org/jira/browse/TRINIDAD-1722 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.0.0-alpha-2 Reporter: Max Starets To reproduce the issue, run table.jspx in Firefox with the latest 2.0.x branch. Notice that the font size is huge. For some strange reason, the skin picks up the following Thai locale rule in base-desktop.xss: !-- And on Thai Gecko - see bug 3897341 - bump the font size up -- styleSheet platforms=windows linux browsers=gecko locales=th style name=AFDefaultFontFamily property name=font-familyBrowallia New,Arial,Helvetica,Geneva,sans-serif/property property name=font-size16pt/property /style If you remove the rule, everything runs fine. If you use IE, it works fine too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1723) Trinidad 2: ClassCastEXception while running componentDemos.jspx
Trinidad 2: ClassCastEXception while running componentDemos.jspx Key: TRINIDAD-1723 URL: https://issues.apache.org/jira/browse/TRINIDAD-1723 Project: MyFaces Trinidad Issue Type: Bug Components: Archetype Affects Versions: 2.0.0-alpha-2 Reporter: Max Starets Grab the latest trinidad-2.0.x branch and try running componentDemos.jspx. The following exception will be thrown: java.lang.ClassCastException: org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode cannot be cast to org.apache.myfaces.trinidadinternal.uinode.UIXComponentUINode at org.apache.myfaces.trinidadinternal.uinode.UIXComponentUINode.__getAdapter(UIXComponentUINode.java:439) at org.apache.myfaces.trinidadinternal.uinode.UINodeRendererBase.encodeEnd(UINodeRendererBase.java:65) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:852) at org.apache.myfaces.trinidad.render.RenderUtils.encodeRecursive(RenderUtils.java:70) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:509) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:531) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer.renderContent(PanelPartialRootRenderer.java:70) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.BodyRenderer.renderContent(BodyRenderer.java:151) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer.encodeAll(PanelPartialRootRenderer.java:153) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.BodyRenderer.encodeAll(BodyRenderer.java:80) at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:546) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.DocumentRenderer.encodeAll(DocumentRenderer.java:82) This does not seem to be JSF 2 specific, but I have not had time to try it on the latest MAIN. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1724) Generated Facelets taglib.xml files don't validate against schema
[ https://issues.apache.org/jira/browse/TRINIDAD-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12833269#action_12833269 ] Max Starets commented on TRINIDAD-1724: --- The XSD shipped with Mojarra 2.0.1 (under jsf-api/doc) contains the following: xsd:element name=method-signature type=javaee:string minOccurs=0 xsd:annotation xsd:documentation Defines the method signature for a MethodExpression- enabled attribute. /xsd:documentation /xsd:annotation /xsd:element However, the one available from http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd does not. I suspect Mojarra guys forgot to update it. If the omission is intentional, we can stop genetating method-signature elements. Generated Facelets taglib.xml files don't validate against schema - Key: TRINIDAD-1724 URL: https://issues.apache.org/jira/browse/TRINIDAD-1724 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Affects Versions: 2.0.2-plugins Reporter: Catalin Kormos At least the tr.taglib.xml I just checked and it contains a lot of method-signature elements, for example: attribute description an EL binding to the method that will deliver the file contents. The method must take two parameters, a FacesContext and an OutputStream. /description namemethod/name requiredtrue/required method-signaturevoid myMethod(javax.faces.context.FacesContext, java.io.OutputStream)/method-signature /attribute Checking the schema method-signature is not allowed in attribute -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1723) Trinidad 2: ClassCastEXception while running componentDemos.jspx
[ https://issues.apache.org/jira/browse/TRINIDAD-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12833270#action_12833270 ] Max Starets commented on TRINIDAD-1723: --- Could you try running in JDev after generating workspace with 'mvn jdev:jdev'? Trinidad 2: ClassCastEXception while running componentDemos.jspx Key: TRINIDAD-1723 URL: https://issues.apache.org/jira/browse/TRINIDAD-1723 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-alpha-2 Reporter: Max Starets Grab the latest trinidad-2.0.x branch and try running componentDemos.jspx. The following exception will be thrown: java.lang.ClassCastException: org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode cannot be cast to org.apache.myfaces.trinidadinternal.uinode.UIXComponentUINode at org.apache.myfaces.trinidadinternal.uinode.UIXComponentUINode.__getAdapter(UIXComponentUINode.java:439) at org.apache.myfaces.trinidadinternal.uinode.UINodeRendererBase.encodeEnd(UINodeRendererBase.java:65) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:852) at org.apache.myfaces.trinidad.render.RenderUtils.encodeRecursive(RenderUtils.java:70) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:509) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:531) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer.renderContent(PanelPartialRootRenderer.java:70) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.BodyRenderer.renderContent(BodyRenderer.java:151) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer.encodeAll(PanelPartialRootRenderer.java:153) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.BodyRenderer.encodeAll(BodyRenderer.java:80) at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:546) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.DocumentRenderer.encodeAll(DocumentRenderer.java:82) This does not seem to be JSF 2 specific, but I have not had time to try it on the latest MAIN. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1681) Generated Facelets taglib.xml files contain the OLD DTD
[ https://issues.apache.org/jira/browse/TRINIDAD-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1681: -- Status: Patch Available (was: Open) Generated Facelets taglib.xml files contain the OLD DTD --- Key: TRINIDAD-1681 URL: https://issues.apache.org/jira/browse/TRINIDAD-1681 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-plugins Reporter: Matthias Weßendorf Attachments: declaration.diff The currently generated artifacts use the old DTD: ?xml version=1.0 encoding=utf-8? !DOCTYPE facelet-taglib PUBLIC -//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN http://java.sun.com/dtd/facelet-taglib_1_0.dtd; facelet-taglib xmlns=http://java.sun.com/JSF/Facelet; However, as of JSF 2.0 it has to be: facelet-taglib xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd; version=2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1681) Generated Facelets taglib.xml files contain the OLD DTD
[ https://issues.apache.org/jira/browse/TRINIDAD-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832679#action_12832679 ] Max Starets commented on TRINIDAD-1681: --- See the provided patch. Note that the tr-base.taglib.xml will need to be modified to have the correct namespace/XSD declaration as well. These two changes have to be made at the same time, otherwise the merge of the statically defined tags with the ones generated by the plugin will fail. Generated Facelets taglib.xml files contain the OLD DTD --- Key: TRINIDAD-1681 URL: https://issues.apache.org/jira/browse/TRINIDAD-1681 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-plugins Reporter: Matthias Weßendorf Attachments: declaration.diff The currently generated artifacts use the old DTD: ?xml version=1.0 encoding=utf-8? !DOCTYPE facelet-taglib PUBLIC -//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN http://java.sun.com/dtd/facelet-taglib_1_0.dtd; facelet-taglib xmlns=http://java.sun.com/JSF/Facelet; However, as of JSF 2.0 it has to be: facelet-taglib xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd; version=2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1707) JSF2: Need to inlude Design Time metadata in Facelets taglib
JSF2: Need to inlude Design Time metadata in Facelets taglib Key: TRINIDAD-1707 URL: https://issues.apache.org/jira/browse/TRINIDAD-1707 Project: MyFaces Trinidad Issue Type: Improvement Components: Facelets Affects Versions: 2.0.1-plugins Reporter: Max Starets We need to start writing design-time metadata for the facelets tags according to the following xsd: https://mojarra.dev.java.net/source/browse/*checkout*/mojarra/trunk/jsf-api/doc/web-facelettaglibrary_2_0.xsd -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1707) JSF2: Need to include Design Time metadata in Facelets taglib
[ https://issues.apache.org/jira/browse/TRINIDAD-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1707: -- Status: Patch Available (was: Open) JSF2: Need to include Design Time metadata in Facelets taglib - Key: TRINIDAD-1707 URL: https://issues.apache.org/jira/browse/TRINIDAD-1707 Project: MyFaces Trinidad Issue Type: Improvement Components: Facelets Affects Versions: 2.0.1-plugins Reporter: Max Starets Assignee: Max Starets Attachments: plugins.diff We need to start writing design-time metadata for the facelets tags according to the following xsd: https://mojarra.dev.java.net/source/browse/*checkout*/mojarra/trunk/jsf-api/doc/web-facelettaglibrary_2_0.xsd -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1707) JSF2: Need to include Design Time metadata in Facelets taglib
[ https://issues.apache.org/jira/browse/TRINIDAD-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1707: -- Resolution: Fixed Fix Version/s: 2.0.1-plugins Status: Resolved (was: Patch Available) JSF2: Need to include Design Time metadata in Facelets taglib - Key: TRINIDAD-1707 URL: https://issues.apache.org/jira/browse/TRINIDAD-1707 Project: MyFaces Trinidad Issue Type: Improvement Components: Facelets Affects Versions: 2.0.1-plugins Reporter: Max Starets Assignee: Max Starets Fix For: 2.0.1-plugins Attachments: plugins.diff We need to start writing design-time metadata for the facelets tags according to the following xsd: https://mojarra.dev.java.net/source/browse/*checkout*/mojarra/trunk/jsf-api/doc/web-facelettaglibrary_2_0.xsd -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
