[jira] Resolved: (MYFACES-3005) Only send Flash cookie if needed
[ https://issues.apache.org/jira/browse/MYFACES-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Jung resolved MYFACES-3005. -- Resolution: Fixed Fix Version/s: 2.0.5-SNAPSHOT as discussed on the dev list this is resolved by adding a context param org.apache.myfaces.DISABLE_FLASH_SCOPE (true/false) and throwing a FlashScopeDisabledException in case someone calls one of the public Map acces methods like get, put, keep or putNow Only send Flash cookie if needed Key: MYFACES-3005 URL: https://issues.apache.org/jira/browse/MYFACES-3005 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.3 Reporter: Jakob Korherr Assignee: Ganesh Jung Fix For: 2.0.5-SNAPSHOT As pointed out by Ganesh on the mailing list [1], we do not always have to send the Flash cookie oam.Flash.RENDERMAP.TOKEN (e.g. when there is no data in the Flash scope). [1] http://old.nabble.com/oam.Flash.RENDERMAP.TOKEN-ts30491897.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (PORTLETBRIDGE-187) Why does the 3.0.0 implementation of PortletFacesContextFactoryImpl differ from the one in 2.0?
Why does the 3.0.0 implementation of PortletFacesContextFactoryImpl differ from
the one in 2.0?
---
Key: PORTLETBRIDGE-187
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-187
Project: MyFaces Portlet Bridge
Issue Type: Question
Components: Impl
Affects Versions: 3.0.0-alpha
Reporter: Hampus Wingren
Assignee: Michael Freedman
This seems like an impossible thing to do if there is no other
PortletFacesContext implementations available. Is it really correct to try and
lookup another FacesContext if we are in a portlet environment?
// if in portlet environment -- do a portlet container neutral test
// first in case we are packaged in a web app that isn't deployed
// on a portlet container/as a portlet. Note: can't use the BridgeUtil
// method as that call requires the facesContext to exist.
FacesContext fc = getWrapped().getFacesContext(context, request, response,
lifecycle);
if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
{
fc = new FacesContextImpl(fc);
}
return fc;
regards,
Hampus
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2056) Add utility method for locating nearest non-flattening ancestor component
[ https://issues.apache.org/jira/browse/TRINIDAD-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005675#comment-13005675 ] Andy Schwartz commented on TRINIDAD-2056: - Commited fix to trunk: http://svn.apache.org/viewvc?view=revisionrevision=1080600 Add utility method for locating nearest non-flattening ancestor component - Key: TRINIDAD-2056 URL: https://issues.apache.org/jira/browse/TRINIDAD-2056 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.0-beta-2 Reporter: Andy Schwartz Assignee: Andy Schwartz Priority: Minor Attachments: trinidad-2056.patch In some cases it may be necessary to walk up the ancestor chain to locate the nearest non-flattening parent. For example, a column component that wants to locate the containing table component would need to skip over any flattening components in between. Opening this issue to request that we provide a utility method for this instead of requiring each case where this is needed to re-implement. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2055) Introduce ChangeManager wrapper class
[ https://issues.apache.org/jira/browse/TRINIDAD-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005677#comment-13005677 ] Andy Schwartz commented on TRINIDAD-2055: - Committed fix to trunk: http://svn.apache.org/viewvc?view=revisionrevision=1080604 Introduce ChangeManager wrapper class - Key: TRINIDAD-2055 URL: https://issues.apache.org/jira/browse/TRINIDAD-2055 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.0-beta-2 Reporter: Andy Schwartz Assignee: Andy Schwartz Priority: Minor Attachments: ChangeManagerWrapper.java One way that users might customize change management behavior is to create a proxy ChangeManager that delegates through to an underlying ChangeManager (eg. to SessionChangeManager) for most operations after performing filtering of the incoming changes. It is possible to implement such proxy ChangeManager classes today. However, without a wrapper base class, these implementations are fragile - ie. they will break if we ever introduce a new method to the ChangeManager API. A more robust solution would be to introduce a base wrapper class for proxy ChangeManager implementations to extend. That way, in the event that we do introduce new ChangeManager methods, the base wrapper class can be updated in parallel, protecting subclasses from the change. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TRINIDAD-2056) Add utility method for locating nearest non-flattening ancestor component
[ https://issues.apache.org/jira/browse/TRINIDAD-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Schwartz updated TRINIDAD-2056: Resolution: Fixed Fix Version/s: 2.0.0-beta-3 Status: Resolved (was: Patch Available) Add utility method for locating nearest non-flattening ancestor component - Key: TRINIDAD-2056 URL: https://issues.apache.org/jira/browse/TRINIDAD-2056 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.0-beta-2 Reporter: Andy Schwartz Assignee: Andy Schwartz Priority: Minor Fix For: 2.0.0-beta-3 Attachments: trinidad-2056.patch In some cases it may be necessary to walk up the ancestor chain to locate the nearest non-flattening parent. For example, a column component that wants to locate the containing table component would need to skip over any flattening components in between. Opening this issue to request that we provide a utility method for this instead of requiring each case where this is needed to re-implement. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TRINIDAD-2055) Introduce ChangeManager wrapper class
[ https://issues.apache.org/jira/browse/TRINIDAD-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Schwartz updated TRINIDAD-2055: Resolution: Fixed Fix Version/s: 2.0.0-beta-3 Status: Resolved (was: Patch Available) Introduce ChangeManager wrapper class - Key: TRINIDAD-2055 URL: https://issues.apache.org/jira/browse/TRINIDAD-2055 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.0-beta-2 Reporter: Andy Schwartz Assignee: Andy Schwartz Priority: Minor Fix For: 2.0.0-beta-3 Attachments: ChangeManagerWrapper.java One way that users might customize change management behavior is to create a proxy ChangeManager that delegates through to an underlying ChangeManager (eg. to SessionChangeManager) for most operations after performing filtering of the incoming changes. It is possible to implement such proxy ChangeManager classes today. However, without a wrapper base class, these implementations are fragile - ie. they will break if we ever introduce a new method to the ChangeManager API. A more robust solution would be to introduce a base wrapper class for proxy ChangeManager implementations to extend. That way, in the event that we do introduce new ChangeManager methods, the base wrapper class can be updated in parallel, protecting subclasses from the change. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2056) Add utility method for locating nearest non-flattening ancestor component
[ https://issues.apache.org/jira/browse/TRINIDAD-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005683#comment-13005683 ] Andy Schwartz commented on TRINIDAD-2056: - Committed to 1.2.12.5: http://svn.apache.org/viewvc?view=revisionrevision=1080617 Add utility method for locating nearest non-flattening ancestor component - Key: TRINIDAD-2056 URL: https://issues.apache.org/jira/browse/TRINIDAD-2056 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.0-beta-2 Reporter: Andy Schwartz Assignee: Andy Schwartz Priority: Minor Fix For: 2.0.0-beta-3 Attachments: trinidad-2056.patch In some cases it may be necessary to walk up the ancestor chain to locate the nearest non-flattening parent. For example, a column component that wants to locate the containing table component would need to skip over any flattening components in between. Opening this issue to request that we provide a utility method for this instead of requiring each case where this is needed to re-implement. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2055) Introduce ChangeManager wrapper class
[ https://issues.apache.org/jira/browse/TRINIDAD-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005684#comment-13005684 ] Andy Schwartz commented on TRINIDAD-2055: - Committed to 1.2.12.5: http://svn.apache.org/viewvc?view=revisionrevision=1080622 Introduce ChangeManager wrapper class - Key: TRINIDAD-2055 URL: https://issues.apache.org/jira/browse/TRINIDAD-2055 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.0-beta-2 Reporter: Andy Schwartz Assignee: Andy Schwartz Priority: Minor Fix For: 2.0.0-beta-3 Attachments: ChangeManagerWrapper.java One way that users might customize change management behavior is to create a proxy ChangeManager that delegates through to an underlying ChangeManager (eg. to SessionChangeManager) for most operations after performing filtering of the incoming changes. It is possible to implement such proxy ChangeManager classes today. However, without a wrapper base class, these implementations are fragile - ie. they will break if we ever introduce a new method to the ChangeManager API. A more robust solution would be to introduce a base wrapper class for proxy ChangeManager implementations to extend. That way, in the event that we do introduce new ChangeManager methods, the base wrapper class can be updated in parallel, protecting subclasses from the change. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2056) Add utility method for locating nearest non-flattening ancestor component
[ https://issues.apache.org/jira/browse/TRINIDAD-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005691#comment-13005691 ] Andy Schwartz commented on TRINIDAD-2056: - Committed to 1.2.x: http://svn.apache.org/viewvc?view=revisionrevision=1080628 Add utility method for locating nearest non-flattening ancestor component - Key: TRINIDAD-2056 URL: https://issues.apache.org/jira/browse/TRINIDAD-2056 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.0-beta-2 Reporter: Andy Schwartz Assignee: Andy Schwartz Priority: Minor Fix For: 2.0.0-beta-3 Attachments: trinidad-2056.patch In some cases it may be necessary to walk up the ancestor chain to locate the nearest non-flattening parent. For example, a column component that wants to locate the containing table component would need to skip over any flattening components in between. Opening this issue to request that we provide a utility method for this instead of requiring each case where this is needed to re-implement. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2055) Introduce ChangeManager wrapper class
[ https://issues.apache.org/jira/browse/TRINIDAD-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005692#comment-13005692 ] Andy Schwartz commented on TRINIDAD-2055: - Committed to 1.2.x: http://svn.apache.org/viewvc?view=revisionrevision=1080631 Introduce ChangeManager wrapper class - Key: TRINIDAD-2055 URL: https://issues.apache.org/jira/browse/TRINIDAD-2055 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.0-beta-2 Reporter: Andy Schwartz Assignee: Andy Schwartz Priority: Minor Fix For: 2.0.0-beta-3 Attachments: ChangeManagerWrapper.java One way that users might customize change management behavior is to create a proxy ChangeManager that delegates through to an underlying ChangeManager (eg. to SessionChangeManager) for most operations after performing filtering of the incoming changes. It is possible to implement such proxy ChangeManager classes today. However, without a wrapper base class, these implementations are fragile - ie. they will break if we ever introduce a new method to the ChangeManager API. A more robust solution would be to introduce a base wrapper class for proxy ChangeManager implementations to extend. That way, in the event that we do introduce new ChangeManager methods, the base wrapper class can be updated in parallel, protecting subclasses from the change. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2059) NPE in CoreResponseStateManager._restoreSerializedView
[
https://issues.apache.org/jira/browse/TRINIDAD-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005698#comment-13005698
]
Volker Malzahn commented on TRINIDAD-2059:
--
redirect after post is standard behaviour when using SWF. It's not wise to
run without redirect after post because then you run into the reload button
issue. In any case it should make sense (and not much effort) to make the
method _restoreSerializedView null save respective the stateString (simply
returning null if stateString is null). This would tell SWF that the view can't
be restored and thus a createView is triggered.
NPE in CoreResponseStateManager._restoreSerializedView
--
Key: TRINIDAD-2059
URL: https://issues.apache.org/jira/browse/TRINIDAD-2059
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0-beta-2
Environment: WinXP, IE 8, Firefox 3.6, Tomcat 5.5, Spring Web Flow
2.3.0, Mojarra 2.0.2-FCS
Reporter: Volker Malzahn
When Trinidad runs inside Mojarra and Sping Web Flow (SWF) a
Nullpointerexception occurs when the redirect after post GET request is
executed for a postBack:
Caused by: java.lang.NullPointerException
at java.io.StringReader.init(StringReader.java:33)
at
org.apache.myfaces.trinidadinternal.renderkit.core.CoreResponseStateManager._restoreSerializedView(CoreResponseStateManager.java:279)
at
org.apache.myfaces.trinidadinternal.renderkit.core.CoreResponseStateManager.getTreeStructureToRestore(CoreResponseStateManager.java:146)
at
org.apache.myfaces.trinidadinternal.application.StateManagerImpl.restoreView(StateManagerImpl.java:584)
at
org.springframework.faces.webflow.FlowViewStateManager.restoreView(FlowViewStateManager.java:195)
at
com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:131)
at
com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:430)
at
com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:143)
at
org.springframework.faces.webflow.FlowViewHandler.restoreFlowView(FlowViewHandler.java:144)
at
org.springframework.faces.webflow.FlowViewHandler.restoreView(FlowViewHandler.java:83)
at
javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:288)
at
org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:242)
at
org.springframework.faces.webflow.FlowViewHandler.restoreFlowView(FlowViewHandler.java:144)
at
org.springframework.faces.webflow.FlowViewHandler.restoreView(FlowViewHandler.java:83)
at
org.springframework.faces.webflow.JsfViewFactory.getView(JsfViewFactory.java:105)
at
org.springframework.webflow.engine.ViewState.resume(ViewState.java:193)
at org.springframework.webflow.engine.Flow.resume(Flow.java:545)
The reason is that in String stateString = _getStateString(external); null
is returned (because the GET request of SWF doesn't contain the request
parameter javax.faces.ViewState).
CoreResponseStateManager._restoreSerializedView should become null save by
putting a if (stateString != null) { before the StringReader sr = new
StringReader(stateString);.
Is it possible to restore the view if we don't have a request parameter
javax.faces.ViewState so that the component tree doesn't need to be built
again in the GET request when emedded into SWF?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Tobago 1.0.35
+1 On Thu, Mar 10, 2011 at 9:39 AM, Volker Weber v.we...@inexso.de wrote: hi, +1 Regards, Volker 2011/3/10 Udo Schnurpfeil u...@schnurpfeil.de: Here is my +1 I've deployed the demo on http://irian.biz/tobago-example-demo/ Regards, Udo Am 09.03.11 15:14, schrieb Bernd Bohmann: Hello, I would like to release Tobago 1.0.35. Changes: ** Bug * [TOBAGO-974] - JavaScript Error when unselectAll in empty simplesheet * [TOBAGO-977] - JavaScript Error on InputSuggest with deactivated SessionSecret Token * [TOBAGO-978] - Hidden tags are not rendered, when using fix-layout-transparency ** Improvement * [TOBAGO-975] - CSS for sheet row selection should also effect the td element For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12316183 The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-003/ The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd -- inexso - information exchange solutions GmbH Ofener Str. 30 | 26121 Oldenburg Tel.: +49 441 219 730 56 | FAX: +49 441 219 730 66 | eMail: volker.we...@inexso.de Firmensitz: Oldenburg | Amtsgericht Oldenburg HRB 205251 Geschäftsführer: Stefan Schulte, Michael Terschüren -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (TRINIDAD-2057) UIXTree/UIXTreeTable/UIXTable RowKeySets require that their attributes are only fetched when the component is in context
[ https://issues.apache.org/jira/browse/TRINIDAD-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005716#comment-13005716 ] Scott O'Bryan commented on TRINIDAD-2057: - Blake's patch was not able to be applied cleanly to trunk but Garry's was. UIXTree/UIXTreeTable/UIXTable RowKeySets require that their attributes are only fetched when the component is in context Key: TRINIDAD-2057 URL: https://issues.apache.org/jira/browse/TRINIDAD-2057 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.15-core , 2.0.0-beta-3 Reporter: Blake Sullivan Assignee: Scott O'Bryan Attachments: RowKey-1.2.12.5.0-branch.patch, trin_2057_1_2_x.diff, trin_2057_2_x.diff Due to the way the RowKeySets for these components are implemented, they need to set the CollectionModel that the component is attached to when the RowKeySet is created. Since the CollectionModel may be EL-bound, this means that the attributes can only be fetched when the component is in context. This is different than how things are supposed to work in JSF, where an attribute should only need to be fetched in context if the attribute is EL-bound In the short term, the fix is to hack on the RowKeySetAttributeChange, but the longer term fix is to fix these components. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Tobago 1.0.35
+1 Leonardo
[jira] Commented: (TRINIDAD-2059) NPE in CoreResponseStateManager._restoreSerializedView
[
https://issues.apache.org/jira/browse/TRINIDAD-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005727#comment-13005727
]
Scott O'Bryan commented on TRINIDAD-2059:
-
I agree that redirect after post is a standard behavior for SWF, but SWF
itself is not a standard.
That said, if all that needs to happen is for us to return a null, I have no
issues with it. Let me do some consultation of the spec for JSF and see if
we're violating the contract there somewhere. I can't imagine a
NullPointerException is an acceptable exception to throw.. If it is, however,
then likely we'll need to open this up to the Trinidad list to get some
comments.
NPE in CoreResponseStateManager._restoreSerializedView
--
Key: TRINIDAD-2059
URL: https://issues.apache.org/jira/browse/TRINIDAD-2059
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0-beta-2
Environment: WinXP, IE 8, Firefox 3.6, Tomcat 5.5, Spring Web Flow
2.3.0, Mojarra 2.0.2-FCS
Reporter: Volker Malzahn
When Trinidad runs inside Mojarra and Sping Web Flow (SWF) a
Nullpointerexception occurs when the redirect after post GET request is
executed for a postBack:
Caused by: java.lang.NullPointerException
at java.io.StringReader.init(StringReader.java:33)
at
org.apache.myfaces.trinidadinternal.renderkit.core.CoreResponseStateManager._restoreSerializedView(CoreResponseStateManager.java:279)
at
org.apache.myfaces.trinidadinternal.renderkit.core.CoreResponseStateManager.getTreeStructureToRestore(CoreResponseStateManager.java:146)
at
org.apache.myfaces.trinidadinternal.application.StateManagerImpl.restoreView(StateManagerImpl.java:584)
at
org.springframework.faces.webflow.FlowViewStateManager.restoreView(FlowViewStateManager.java:195)
at
com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:131)
at
com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:430)
at
com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:143)
at
org.springframework.faces.webflow.FlowViewHandler.restoreFlowView(FlowViewHandler.java:144)
at
org.springframework.faces.webflow.FlowViewHandler.restoreView(FlowViewHandler.java:83)
at
javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:288)
at
org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:242)
at
org.springframework.faces.webflow.FlowViewHandler.restoreFlowView(FlowViewHandler.java:144)
at
org.springframework.faces.webflow.FlowViewHandler.restoreView(FlowViewHandler.java:83)
at
org.springframework.faces.webflow.JsfViewFactory.getView(JsfViewFactory.java:105)
at
org.springframework.webflow.engine.ViewState.resume(ViewState.java:193)
at org.springframework.webflow.engine.Flow.resume(Flow.java:545)
The reason is that in String stateString = _getStateString(external); null
is returned (because the GET request of SWF doesn't contain the request
parameter javax.faces.ViewState).
CoreResponseStateManager._restoreSerializedView should become null save by
putting a if (stateString != null) { before the StringReader sr = new
StringReader(stateString);.
Is it possible to restore the view if we don't have a request parameter
javax.faces.ViewState so that the component tree doesn't need to be built
again in the GET request when emedded into SWF?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (EXTCDI-156) performance improvements of codi scopes
performance improvements of codi scopes --- Key: EXTCDI-156 URL: https://issues.apache.org/jira/browse/EXTCDI-156 Project: MyFaces CODI Issue Type: Improvement Components: JEE-JSF12-Module, JEE-JSF20-Module Reporter: Gerhard Petracek Assignee: Gerhard Petracek -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2059) NPE in CoreResponseStateManager._restoreSerializedView
[
https://issues.apache.org/jira/browse/TRINIDAD-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005731#comment-13005731
]
Scott O'Bryan commented on TRINIDAD-2059:
-
Okay, yeah. We're clearly in violation of the JSF Spec here. In the Javadoc
for ViewHandler.restorView (http://tinyurl.com/4b5p3tv) is says:
If there is no available state for the specified viewId, return null.
I'll get to this when I can.. Of course if you're interested in submitting a
patch, I may be able to apply it quicker..
Thanks for catching this..
NPE in CoreResponseStateManager._restoreSerializedView
--
Key: TRINIDAD-2059
URL: https://issues.apache.org/jira/browse/TRINIDAD-2059
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0-beta-2
Environment: WinXP, IE 8, Firefox 3.6, Tomcat 5.5, Spring Web Flow
2.3.0, Mojarra 2.0.2-FCS
Reporter: Volker Malzahn
Assignee: Scott O'Bryan
When Trinidad runs inside Mojarra and Sping Web Flow (SWF) a
Nullpointerexception occurs when the redirect after post GET request is
executed for a postBack:
Caused by: java.lang.NullPointerException
at java.io.StringReader.init(StringReader.java:33)
at
org.apache.myfaces.trinidadinternal.renderkit.core.CoreResponseStateManager._restoreSerializedView(CoreResponseStateManager.java:279)
at
org.apache.myfaces.trinidadinternal.renderkit.core.CoreResponseStateManager.getTreeStructureToRestore(CoreResponseStateManager.java:146)
at
org.apache.myfaces.trinidadinternal.application.StateManagerImpl.restoreView(StateManagerImpl.java:584)
at
org.springframework.faces.webflow.FlowViewStateManager.restoreView(FlowViewStateManager.java:195)
at
com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:131)
at
com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:430)
at
com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:143)
at
org.springframework.faces.webflow.FlowViewHandler.restoreFlowView(FlowViewHandler.java:144)
at
org.springframework.faces.webflow.FlowViewHandler.restoreView(FlowViewHandler.java:83)
at
javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:288)
at
org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:242)
at
org.springframework.faces.webflow.FlowViewHandler.restoreFlowView(FlowViewHandler.java:144)
at
org.springframework.faces.webflow.FlowViewHandler.restoreView(FlowViewHandler.java:83)
at
org.springframework.faces.webflow.JsfViewFactory.getView(JsfViewFactory.java:105)
at
org.springframework.webflow.engine.ViewState.resume(ViewState.java:193)
at org.springframework.webflow.engine.Flow.resume(Flow.java:545)
The reason is that in String stateString = _getStateString(external); null
is returned (because the GET request of SWF doesn't contain the request
parameter javax.faces.ViewState).
CoreResponseStateManager._restoreSerializedView should become null save by
putting a if (stateString != null) { before the StringReader sr = new
StringReader(stateString);.
Is it possible to restore the view if we don't have a request parameter
javax.faces.ViewState so that the component tree doesn't need to be built
again in the GET request when emedded into SWF?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Tobago 1.0.35
+1 On Fri, Mar 11, 2011 at 9:02 AM, Leonardo Uribe lu4...@gmail.com wrote: +1 Leonardo -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
[jira] Created: (MYFACES-3069) Ajax: response function cannot be overrided by custom components
Ajax: response function cannot be overrided by custom components Key: MYFACES-3069 URL: https://issues.apache.org/jira/browse/MYFACES-3069 Project: MyFaces Core Issue Type: Bug Reporter: Nick Belaevski Attached is example of custom component that needs to proxy jsf.ajax.response. Works in Mojarra, doesn't work in MyFaces. To reproduce, run example, navigate to http://localhost:8080/jsf2-test/index.jsf and press link - alert should be shown if function was overriden correctly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (EXTCDI-156) performance improvements of codi scopes
[ https://issues.apache.org/jira/browse/EXTCDI-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved EXTCDI-156. - Resolution: Fixed Fix Version/s: 0.9.4 performance improvements of codi scopes --- Key: EXTCDI-156 URL: https://issues.apache.org/jira/browse/EXTCDI-156 Project: MyFaces CODI Issue Type: Improvement Components: JEE-JSF12-Module, JEE-JSF20-Module Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.9.4 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-3070) jsf.js: the viewstate resolution needs to be entirely deferred to the end of the rendering cycle
jsf.js: the viewstate resolution needs to be entirely deferred to the end of the rendering cycle Key: MYFACES-3070 URL: https://issues.apache.org/jira/browse/MYFACES-3070 Project: MyFaces Core Issue Type: Bug Reporter: Werner Punz Priority: Minor The problem with the current code and generally the spec is that if a viewstate update is issued the viewstate elemts should be updated normally this happens at the end of the rendering, but what if the viewstate is issued in between, then our update might happen on elements not yet rendered or later updated. Hence the viewstate then is lost. It makes sense to defer the viewstate update always to the end of the rendering cycle. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-3071) jsf.js: improve dynamic code loading
jsf.js: improve dynamic code loading Key: MYFACES-3071 URL: https://issues.apache.org/jira/browse/MYFACES-3071 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.4 Reporter: Werner Punz Priority: Minor Up until now we have used synchronous http get requests and evals to load the scripts. Now html5 opens another way we still can use the head appendix method but differently than before, we simply have to move it over to the addition of script src elements with async set to false and true depending on the script being loadable asynchronously or not. Also we can add this mechanism to our existing synchronous load by making the mechanism either asynchronous or synchronous. We then can redjust our dynamic loading code for the debugging case to this new loading method. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-3072) jsf.js: improvement in the error reporting
jsf.js: improvement in the error reporting -- Key: MYFACES-3072 URL: https://issues.apache.org/jira/browse/MYFACES-3072 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.4 Reporter: Werner Punz Priority: Minor We can improve on the error reporting, first there were some error messages not fully localized secondly we still have relatively unformatted error reporting strings. We can improve on both of that. Third the entire error handlers are currently hooked on transport we should move them over both to impl and to the ajax request directly, depending on where it makes sense mostly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-3073) jsf.js: code cleanup _Runtime.js
jsf.js: code cleanup _Runtime.js Key: MYFACES-3073 URL: https://issues.apache.org/jira/browse/MYFACES-3073 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.4 Reporter: Werner Punz Priority: Minor The global eval code in _Runtime.js is not really very readable due to several nested ifs, this will be replaced by a more readable functional approach which utilizes several boolean conditions and dynamic calls. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-3043) Ajax: response(...) function breaks if request(...) has not been called previously
[
https://issues.apache.org/jira/browse/MYFACES-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved MYFACES-3043.
--
Resolution: Fixed
Fix Version/s: 2.0.5-SNAPSHOT
Ajax: response(...) function breaks if request(...) has not been called
previously
--
Key: MYFACES-3043
URL: https://issues.apache.org/jira/browse/MYFACES-3043
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.4
Reporter: Nick Belaevski
Assignee: Werner Punz
Fix For: 2.0.5-SNAPSHOT
In RichFaces for file upload component we call jsf.ajax.response(...) method
to process contents of IFRAME element. The problem is that this call is not
preceded by call to jsf.ajax.request(...), making MyFaces fail:
response : function(request, context) {
this._q._curReq._response.processResponse(request, context);
}
this._q._curReq - is undefined.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3069) Ajax: response function cannot be overrided by custom components
[ https://issues.apache.org/jira/browse/MYFACES-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005837#comment-13005837 ] Werner Punz commented on MYFACES-3069: -- I have yet to look at the example but my personal guess is that mojarra calls jsf.ajax.response directly internally while we just expose it as api to the user but do not call it internally anymore. I guess we will have to change that back to allow the proxying of the function from the outside with custom code. Ajax: response function cannot be overrided by custom components Key: MYFACES-3069 URL: https://issues.apache.org/jira/browse/MYFACES-3069 Project: MyFaces Core Issue Type: Bug Reporter: Nick Belaevski Attachments: myfaces-3069.zip Attached is example of custom component that needs to proxy jsf.ajax.response. Works in Mojarra, doesn't work in MyFaces. To reproduce, run example, navigate to http://localhost:8080/jsf2-test/index.jsf and press link - alert should be shown if function was overriden correctly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-3071) jsf.js: improve dynamic code loading
[ https://issues.apache.org/jira/browse/MYFACES-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-3071. -- Resolution: Fixed Fix Version/s: 2.0.5-SNAPSHOT jsf.js: improve dynamic code loading Key: MYFACES-3071 URL: https://issues.apache.org/jira/browse/MYFACES-3071 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.4 Reporter: Werner Punz Priority: Minor Fix For: 2.0.5-SNAPSHOT Up until now we have used synchronous http get requests and evals to load the scripts. Now html5 opens another way we still can use the head appendix method but differently than before, we simply have to move it over to the addition of script src elements with async set to false and true depending on the script being loadable asynchronously or not. Also we can add this mechanism to our existing synchronous load by making the mechanism either asynchronous or synchronous. We then can redjust our dynamic loading code for the debugging case to this new loading method. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-3070) jsf.js: the viewstate resolution needs to be entirely deferred to the end of the rendering cycle
[ https://issues.apache.org/jira/browse/MYFACES-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-3070. -- Resolution: Fixed jsf.js: the viewstate resolution needs to be entirely deferred to the end of the rendering cycle Key: MYFACES-3070 URL: https://issues.apache.org/jira/browse/MYFACES-3070 Project: MyFaces Core Issue Type: Bug Reporter: Werner Punz Priority: Minor The problem with the current code and generally the spec is that if a viewstate update is issued the viewstate elemts should be updated normally this happens at the end of the rendering, but what if the viewstate is issued in between, then our update might happen on elements not yet rendered or later updated. Hence the viewstate then is lost. It makes sense to defer the viewstate update always to the end of the rendering cycle. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-3073) jsf.js: code cleanup _Runtime.js
[ https://issues.apache.org/jira/browse/MYFACES-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-3073. -- Resolution: Fixed Fix Version/s: 2.0.5-SNAPSHOT jsf.js: code cleanup _Runtime.js Key: MYFACES-3073 URL: https://issues.apache.org/jira/browse/MYFACES-3073 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.4 Reporter: Werner Punz Priority: Minor Fix For: 2.0.5-SNAPSHOT The global eval code in _Runtime.js is not really very readable due to several nested ifs, this will be replaced by a more readable functional approach which utilizes several boolean conditions and dynamic calls. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-3072) jsf.js: improvement in the error reporting
[ https://issues.apache.org/jira/browse/MYFACES-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-3072. -- Resolution: Fixed Fix Version/s: 2.0.5-SNAPSHOT jsf.js: improvement in the error reporting -- Key: MYFACES-3072 URL: https://issues.apache.org/jira/browse/MYFACES-3072 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.4 Reporter: Werner Punz Priority: Minor Fix For: 2.0.5-SNAPSHOT We can improve on the error reporting, first there were some error messages not fully localized secondly we still have relatively unformatted error reporting strings. We can improve on both of that. Third the entire error handlers are currently hooked on transport we should move them over both to impl and to the ajax request directly, depending on where it makes sense mostly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-2457) f:selectItem escape property not bound in facelets
[ https://issues.apache.org/jira/browse/MYFACES-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2457. - Resolution: Fixed Fix Version/s: 2.0.5-SNAPSHOT On JSF 2.0 spec rev A, finally the property was changed to escapeItem on facelets case. Closing it as fixed. f:selectItem escape property not bound in facelets Key: MYFACES-2457 URL: https://issues.apache.org/jira/browse/MYFACES-2457 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.5-SNAPSHOT escape property maps to UISelectItem.itemEscaped property, so we need to create a TagHandler that alias this property. It works in jsp but not on facelets Note this fix makes fails one TCK test, but the expected behavior is this, so we need to request exclude that test from TCK. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MYFACES-3071) jsf.js: improve dynamic code loading
[ https://issues.apache.org/jira/browse/MYFACES-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz reopened MYFACES-3071: -- it seems that the new code loading facilities are flakey so I will postpone to enable it until the browsers have resolved the issue jsf.js: improve dynamic code loading Key: MYFACES-3071 URL: https://issues.apache.org/jira/browse/MYFACES-3071 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.4 Reporter: Werner Punz Priority: Minor Fix For: 2.0.5-SNAPSHOT Up until now we have used synchronous http get requests and evals to load the scripts. Now html5 opens another way we still can use the head appendix method but differently than before, we simply have to move it over to the addition of script src elements with async set to false and true depending on the script being loadable asynchronously or not. Also we can add this mechanism to our existing synchronous load by making the mechanism either asynchronous or synchronous. We then can redjust our dynamic loading code for the debugging case to this new loading method. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-3071) jsf.js: improve dynamic code loading
[ https://issues.apache.org/jira/browse/MYFACES-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-3071. -- Resolution: Fixed Ok I left the new mechanism in, but set everything to synchronous to avoid problems, seems to work now and still is faster than xhr get + manual eval jsf.js: improve dynamic code loading Key: MYFACES-3071 URL: https://issues.apache.org/jira/browse/MYFACES-3071 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.4 Reporter: Werner Punz Priority: Minor Fix For: 2.0.5-SNAPSHOT Up until now we have used synchronous http get requests and evals to load the scripts. Now html5 opens another way we still can use the head appendix method but differently than before, we simply have to move it over to the addition of script src elements with async set to false and true depending on the script being loadable asynchronously or not. Also we can add this mechanism to our existing synchronous load by making the mechanism either asynchronous or synchronous. We then can redjust our dynamic loading code for the debugging case to this new loading method. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MYFACES-3069) Ajax: response function cannot be overrided by custom components
[ https://issues.apache.org/jira/browse/MYFACES-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-3069. -- Resolution: Fixed Fix Version/s: 2.0.5-SNAPSHOT It was indeed the problem I was talking about, I am now rerouting the internal processResponse calls into jsf.ajax.response. A decoration of the response object now produces a call onto the decorated function. If the response does its own thing and does nothing within our impl the queue still processed, so the queue handling wont be affected by some external override even if the function is overridden to 100%. Ajax: response function cannot be overrided by custom components Key: MYFACES-3069 URL: https://issues.apache.org/jira/browse/MYFACES-3069 Project: MyFaces Core Issue Type: Bug Reporter: Nick Belaevski Assignee: Werner Punz Fix For: 2.0.5-SNAPSHOT Attachments: myfaces-3069.zip Attached is example of custom component that needs to proxy jsf.ajax.response. Works in Mojarra, doesn't work in MyFaces. To reproduce, run example, navigate to http://localhost:8080/jsf2-test/index.jsf and press link - alert should be shown if function was overriden correctly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2061) add a utility method in PartialPageUtils to complete the ppr response
add a utility method in PartialPageUtils to complete the ppr response - Key: TRINIDAD-2061 URL: https://issues.apache.org/jira/browse/TRINIDAD-2061 Project: MyFaces Trinidad Issue Type: Bug Reporter: Yuan Gao Just discussed with Blake. What we are trying to do is to add a new utility method (API) in PartialPageUtils. /** * This method completes the PPR request and writes a noop/ to the response. * it also handles script and redirect * * @param context the FacesContext * @param script the script * @param redirectUrl the URL to redirect to * @throws IOException */ public static void completePPRResponse(FacesContext context, String script, String redirectUrl) throws IOException The reason is currently we have several places that we want to complete the response with this noop/ or redirect, or a script, and we want to refactor the codes to use this utility. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
propose a new utility API in PartialPageUtils to complate the response
hi, I'd like to propose a new utility API to complete the PPR response. Talked with Blake and we suggest to put it in PartialPageUtils. Here is the JIRA: https://issues.apache.org/jira/browse/TRINIDAD-2061 Please review. Thanks, -Yuan
