[jira] Created: (MYFACES-2562) javax.el.PropertyNotFoundException: The class 'javax.faces.component.UIViewRoot' does not have the property 'example'.
javax.el.PropertyNotFoundException: The class 'javax.faces.component.UIViewRoot' does not have the property 'example'. -- Key: MYFACES-2562 URL: https://issues.apache.org/jira/browse/MYFACES-2562 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Reporter: Matthias Weßendorf Invoking this page: https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/componentDemos.jspx with Trinidad 1.2.14 (JSF 1.2 lib) with MyFAces 2.0 (trunk) gives me this exception: 2010-02-18 09:21:35.895::WARN: /trinidad-demo/faces/componentDemos.jspx javax.el.PropertyNotFoundException: The class 'javax.faces.component.UIViewRoot' does not have the property 'example'. at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:579) at javax.el.BeanELResolver.getValue(BeanELResolver.java:281) at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:175) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:140) at com.sun.el.parser.AstValue.getValue(AstValue.java:138) at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:206) at org.apache.myfaces.trinidad.bean.FacesBeanImpl.getProperty(FacesBeanImpl.java:66) at org.apache.myfaces.trinidad.component.UIXComponentBase.getBooleanProperty(UIXComponentBase.java:1275) at org.apache.myfaces.trinidad.component.UIXComponentBase.isRendered(UIXComponentBase.java:485) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelGroupLayoutRenderer._encodeChildren(PanelGroupLayoutRenderer.java:142) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelGroupLayoutRenderer.encodeAll(PanelGroupLayoutRenderer.java:106) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:379) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:833) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:459) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.TreeRenderer._renderStampBasedOnAccessibilty(TreeRenderer.java:1144) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.TreeRenderer.renderStampCell(TreeRenderer.java:943) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.TreeRenderer._renderNode(TreeRenderer.java:804) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.TreeRenderer._renderContent(TreeRenderer.java:189) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.TreeRenderer.encodeAll(TreeRenderer.java:135) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:379) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:833) at org.apache.myfaces.trinidad.component.UIXCollection.encodeEnd(UIXCollection.java:591) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:459) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:476) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelHeaderRenderer.encodeAll(PanelHeaderRenderer.java:133) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:379) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:833) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:459) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:476) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelHeaderRenderer.encodeAll(PanelHeaderRenderer.java:133) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:379) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:833) at org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode._renderComponent(UIComponentUINode.java:337) at org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode.render(UIComponentUINode.java:279) at org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode.render(UIComponentUINode.java:256) at org.apache.myfaces.trinidadinternal.ui.composite.ContextPoppingUINode$ContextPoppingRenderer.render(ContextPoppingUINode.java:240) at org.apache.myfaces.trinidadinternal.ui.BaseUINode.render(BaseUINode.java:358) at org.apache.myfaces.trinidadinternal.ui.BaseUINode.render(BaseUINode.java:313) at
[jira] Commented: (MYFACES-2562) javax.el.PropertyNotFoundException: The class 'javax.faces.component.UIViewRoot' does not have the property 'example'.
[
https://issues.apache.org/jira/browse/MYFACES-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835144#action_12835144
]
Matthias Weßendorf commented on MYFACES-2562:
-
problem is this part of the jspx
tr:tree var=component value=#{componentTree.model}
binding=#{componentTreeBean.tree}
f:facet name=nodeStamp
tr:panelGroupLayout
tr:outputText value=Example:
rendered=#{component.example}/
tr:commandLink text=#{component.label}
disabled=#{empty component.filename}
action=#{component.view}/
/tr:panelGroupLayout
/f:facet
/tr:tree
== #{component...
as #{component} is now a reserved EL via JSF2
javax.el.PropertyNotFoundException: The class
'javax.faces.component.UIViewRoot' does not have the property 'example'.
--
Key: MYFACES-2562
URL: https://issues.apache.org/jira/browse/MYFACES-2562
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta
Reporter: Matthias Weßendorf
Invoking this page:
https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/componentDemos.jspx
with Trinidad 1.2.14 (JSF 1.2 lib) with MyFAces 2.0 (trunk) gives me this
exception:
2010-02-18 09:21:35.895::WARN: /trinidad-demo/faces/componentDemos.jspx
javax.el.PropertyNotFoundException: The class
'javax.faces.component.UIViewRoot' does not have the property 'example'.
at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:579)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:281)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:175)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:140)
at com.sun.el.parser.AstValue.getValue(AstValue.java:138)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:206)
at
org.apache.myfaces.trinidad.bean.FacesBeanImpl.getProperty(FacesBeanImpl.java:66)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.getBooleanProperty(UIXComponentBase.java:1275)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.isRendered(UIXComponentBase.java:485)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelGroupLayoutRenderer._encodeChildren(PanelGroupLayoutRenderer.java:142)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelGroupLayoutRenderer.encodeAll(PanelGroupLayoutRenderer.java:106)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:379)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:833)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:459)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.TreeRenderer._renderStampBasedOnAccessibilty(TreeRenderer.java:1144)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.TreeRenderer.renderStampCell(TreeRenderer.java:943)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.TreeRenderer._renderNode(TreeRenderer.java:804)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.TreeRenderer._renderContent(TreeRenderer.java:189)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.TreeRenderer.encodeAll(TreeRenderer.java:135)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:379)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:833)
at
org.apache.myfaces.trinidad.component.UIXCollection.encodeEnd(UIXCollection.java:591)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:459)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:476)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelHeaderRenderer.encodeAll(PanelHeaderRenderer.java:133)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:379)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:833)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:459)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:476)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelHeaderRenderer.encodeAll(PanelHeaderRenderer.java:133)
at
[jira] Resolved: (MYFACES-2562) javax.el.PropertyNotFoundException: The class 'javax.faces.component.UIViewRoot' does not have the property 'example'.
[
https://issues.apache.org/jira/browse/MYFACES-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Weßendorf resolved MYFACES-2562.
-
Resolution: Invalid
ok... I close it for now...
but I am not sure (yes, the spec should be clear on warnings regarding
#{component} usage, on migration)
if we want a better warning here.
javax.el.PropertyNotFoundException: The class
'javax.faces.component.UIViewRoot' does not have the property 'example'.
--
Key: MYFACES-2562
URL: https://issues.apache.org/jira/browse/MYFACES-2562
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta
Reporter: Matthias Weßendorf
Invoking this page:
https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/componentDemos.jspx
with Trinidad 1.2.14 (JSF 1.2 lib) with MyFAces 2.0 (trunk) gives me this
exception:
2010-02-18 09:21:35.895::WARN: /trinidad-demo/faces/componentDemos.jspx
javax.el.PropertyNotFoundException: The class
'javax.faces.component.UIViewRoot' does not have the property 'example'.
at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:579)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:281)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:175)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:140)
at com.sun.el.parser.AstValue.getValue(AstValue.java:138)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:206)
at
org.apache.myfaces.trinidad.bean.FacesBeanImpl.getProperty(FacesBeanImpl.java:66)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.getBooleanProperty(UIXComponentBase.java:1275)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.isRendered(UIXComponentBase.java:485)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelGroupLayoutRenderer._encodeChildren(PanelGroupLayoutRenderer.java:142)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelGroupLayoutRenderer.encodeAll(PanelGroupLayoutRenderer.java:106)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:379)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:833)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:459)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.TreeRenderer._renderStampBasedOnAccessibilty(TreeRenderer.java:1144)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.TreeRenderer.renderStampCell(TreeRenderer.java:943)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.TreeRenderer._renderNode(TreeRenderer.java:804)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.TreeRenderer._renderContent(TreeRenderer.java:189)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.TreeRenderer.encodeAll(TreeRenderer.java:135)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:379)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:833)
at
org.apache.myfaces.trinidad.component.UIXCollection.encodeEnd(UIXCollection.java:591)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:459)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:476)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelHeaderRenderer.encodeAll(PanelHeaderRenderer.java:133)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:379)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:833)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:459)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:476)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelHeaderRenderer.encodeAll(PanelHeaderRenderer.java:133)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:379)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:833)
at
org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode._renderComponent(UIComponentUINode.java:337)
at
org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode.render(UIComponentUINode.java:279)
at
[jira] Created: (MYFACES-2563) Trinidad 1.2.x generates on POSTBACK a NullPointerException on MyFAces2
Trinidad 1.2.x generates on POSTBACK a NullPointerException on MyFAces2 --- Key: MYFACES-2563 URL: https://issues.apache.org/jira/browse/MYFACES-2563 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Reporter: Matthias Weßendorf tr:commandButton. a click generates this: SEVERE: An exception occurred javax.faces.FacesException: java.lang.NullPointerException at org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241) at org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:157) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:88) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) 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 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1148) at org.apache.myfaces.trinidaddemo.webapp.RedirectFilter.doFilter(RedirectFilter.java:97) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1148) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:387) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:535) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:880) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520) Caused by: java.lang.NullPointerException at org.apache.myfaces.application.ViewHandlerImpl.getViewParameterList(ViewHandlerImpl.java:297) at org.apache.myfaces.application.ViewHandlerImpl.getRedirectURL(ViewHandlerImpl.java:119) at javax.faces.application.ViewHandlerWrapper.getRedirectURL(ViewHandlerWrapper.java:121) at org.apache.myfaces.application.NavigationHandlerImpl.handleNavigation(NavigationHandlerImpl.java:92) at org.apache.myfaces.trinidadinternal.application.NavigationHandlerImpl.handleNavigation(NavigationHandlerImpl.java:49) at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:125) at org.apache.myfaces.trinidad.component.UIXCommand.broadcast(UIXCommand.java:190) at javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:878) at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:234) at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1190) at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:611) at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:35) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:138) ... 26 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [core] Backwards compatibility (e.g. MYFACES-2543)
Yes.- this is a BUG it needs to support more than just 2.0 (Dan/Ed commented on the open list) -Matthias On Thu, Feb 11, 2010 at 2:35 PM, Matthias Wessendorf mat...@apache.org wrote: nope, but the web.xml setting for Trinidad's alternate view handler; it is complaining about the facelets embedded faces-config -Matthias On Thu, Feb 11, 2010 at 2:22 PM, Jakob Korherr jakob.korh...@gmail.com wrote: have you installed the com.sun.facelets.FaceletViewHandler in faces-config? and which error did you get? 2010/2/11 Matthias Wessendorf mat...@apache.org @ javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER I tried (Glassfish v3) to deploy a JSF 1.2 application (with Facelets 1.1.14) and that javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER parameter == true; I get an error there as well :-) -Matthias On Wed, Feb 10, 2010 at 11:08 AM, Jakob Korherr jakob.korh...@gmail.com wrote: No I have not filed any bugs. Feel free to file them ;) Regards, Jakob 2010/2/10 Matthias Wessendorf mat...@apache.org On Wed, Feb 10, 2010 at 10:44 AM, Ganesh gan...@j4fry.org wrote: IMHO the spec is very clear about this and the stuff in the appendix is a spec bug. From the spec (10.1.2): A decision was made early in this process to strive for backwards compatibility between the latest popular version of Facelets and Facelets in JSF 2.0. The sole determinant to backwards compatibility lies in the answer to the question, “is there any Java code in the application, or in libraries used by the application, that extends from or depends on any class in package com.sun.facelets and/or its sub-packages?” ■ If the answer to this question is “yes”, Facelets in JSF 2.0 is not backwards compatibile with Facelets and such an application must continue to bundle the Facelets jar file along with the application, continue to set the Facelets configuration parameters, and also set the javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER context-param to true. Please see Section 11.1.3 “Application Configuration Parameters” for details on this option. Any code that extends or depends on any class in package com.sun.facelets and/or its sub-packages must be modified to depend on the appropriate classes in package javax.faces.webapp.vdl and/or its subpackages. yes (see previous email(s)) ■ If the answer to this question is “no”, Facelets in JSF 2.0 is backwards compatible with pre-JSF 2.0 Facelets and such an application must not continue to bundle the Facelets jar file along with the application, and must not continue to set the Facelets configuration parameters. Thankfully, most applications that use Facelets fall into the latter category, or, if they fall in the former, their dependence will easily be migrated to the new public classes. ok. please; file a bug on that appendix thing. thjx -m Best regards, Ganesh Matthias Wessendorf schrieb: On Wed, Feb 10, 2010 at 6:26 AM, Ganesh gan...@j4fry.org wrote: Many Facelets taglibs don't use Facelets tag handlers, but simply wrap some xhtml templates. Nothing will stop these libraries to work with MyFaces if we allow old version taglibs. If we insist on refusing them people will simply switch to Mojarra to get their application to run. I know; that's what I meant with my comment before The argument of a xsd:restriction in the spec will help little. Just taking old Facelets is *not* a solution, because the rest of the application may want to use the new features. Please try filing this as a bug to Mojarra as Matthias proposed - if they fix it, MyFaces may insist on version=2.0, but if they don't I think we shouldn't either. I agree I've carried the question whether a JSF 2.0 compatible implementation is required to refuse old version facelets taglibs into the EG - let's see, what they have to say technically, I think now we are correct. @Jakob: Did you create such a bug against the RI ? (that they allow old Facelets) maybe another on not being (too) clear in the spec about it... -Matthias on this ... Best regards, Ganesh I see both ways; I think I don't like the fact that the RI has this bug :) So, end of the story is, almost everybody will blame this to us ;-) Oh, crappy MyFaces doesn't work etc :) All the FUD! :) -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions:
[jira] Commented: (MYFACES-2563) Trinidad 1.2.x generates on POSTBACK a NullPointerException on MyFAces2
[ https://issues.apache.org/jira/browse/MYFACES-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835148#action_12835148 ] Matthias Weßendorf commented on MYFACES-2563: - as we are on JSP, the getViewMetadata() returns NULL Trinidad 1.2.x generates on POSTBACK a NullPointerException on MyFAces2 --- Key: MYFACES-2563 URL: https://issues.apache.org/jira/browse/MYFACES-2563 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Reporter: Matthias Weßendorf tr:commandButton. a click generates this: SEVERE: An exception occurred javax.faces.FacesException: java.lang.NullPointerException at org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241) at org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:157) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:88) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) 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 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1148) at org.apache.myfaces.trinidaddemo.webapp.RedirectFilter.doFilter(RedirectFilter.java:97) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1148) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:387) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:535) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:880) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520) Caused by: java.lang.NullPointerException at org.apache.myfaces.application.ViewHandlerImpl.getViewParameterList(ViewHandlerImpl.java:297) at org.apache.myfaces.application.ViewHandlerImpl.getRedirectURL(ViewHandlerImpl.java:119) at javax.faces.application.ViewHandlerWrapper.getRedirectURL(ViewHandlerWrapper.java:121) at org.apache.myfaces.application.NavigationHandlerImpl.handleNavigation(NavigationHandlerImpl.java:92) at org.apache.myfaces.trinidadinternal.application.NavigationHandlerImpl.handleNavigation(NavigationHandlerImpl.java:49) at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:125) at org.apache.myfaces.trinidad.component.UIXCommand.broadcast(UIXCommand.java:190) at javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:878) at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:234) at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1190) at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:611) at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:35) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:138) ... 26 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ExtVal] Cross Validations and duplicate messages
hi rudy,
you mentioned it correctly. it's a specific functionality
of AbstractCompareStrategy.
as alternative it's possible to provide a custom FacesMessageStorage which
filters messages before they get added (directly
in FacesMessageStorage#addFacesMessage). that would allow a better
performance as well as an add-on instead of a configuration parameter.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/2/18 Rudy De Busscher rdebussc...@gmail.com
Hi all,
There are cases that the validation message is shown twice for some Cross
Validations.
If we use for instance the Equals or NotEquals annotations where the target
component is also shown on the same page, the message is shown twice.
This is the example:
*public class Person
{
@NotEquals(value = lastName, validationErrorMsgKey = First name and
last name can't have the same value)
private String firstName;
private String lastName;
...
}
h:messages /
h:form
h:panelGrid columns=2
h:outputLabel value=First name for=firstName /
h:inputText id=firstName
value=#{personBean.selectedPerson.firstName} label=First Name /
h:outputLabel value=Last name for=lastName /
h:inputText id=lastName
value=#{personBean.selectedPerson.lastName} label=Last Name /
/h:panelGrid
/h:form*
This is expected behaviour since the code wants to mark both fields as
invalid and shows the message for each field. But when the errors are
displayed on the top of the page, the message seems to be duplicated. And in
case of the above example with a custom validation message, it can be
interpreted as a bug.
The only way, I found, to avoid the 'duplicate' message (other then
creating a custom strategy or annotation) was the creation of a
ValidationExceptionInterceptor that filters out the duplicate message.
*public class NoTargetMessageValidationExceptionInterceptor implements
ValidationExceptionInterceptor
{
public boolean afterThrowing(UIComponent uiComponent,
MetaDataEntry metaDataEntry, Object convertedObject,
ValidatorException validatorException,
ValidationStrategy validatorExceptionSource)
{
boolean result = true;
FacesMessageStorage storage = getStorage(FacesMessageStorage.class,
FacesMessageStorage.class.getName());
for (FacesMessageHolder holder : storage.getFacesMessages())
{
if (holder.getFacesMessage().getDetail().equals(
validatorException.getFacesMessage().getDetail()))
{
result = false;
}
}
return result;
}
...
}*
This code is not specific for Cross Validation messages, but is generic.
But in most cases, a duplicate message comes from the usage of
CrossValidation annotations.
Should there be a configuration option (like a ValidationParameter) created
in version x.x.4 so that the useTargetComponentToDisplayErrorMsg outcome is
not only specified in the code but also by the annotation?
regards
Rudy
[jira] Commented: (MYFACES-2561) StackOverflowError if a composite component implementation uses another composite component
[
https://issues.apache.org/jira/browse/MYFACES-2561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835159#action_12835159
]
Jakob Korherr commented on MYFACES-2561:
Thanks for all your ideas, Leonardo, but I already have a working solution for
that as I ment in I already have a solution for the #{cc} resolver problem..
My solution is similar to your last suggestion. I use the Location object to
check in which file the Value-/MethodExpression is generated (in
TagAttributeImpl). To save it I introduced LocationValueExpression and
LocationMethodExpression. These two classes pass through all EL methods but
push the related composite component to the stack before invocation and remove
it afterwards. Thus the implicit object resolver does not need to be changed.
To find the related composite component I search the current component stack
for the composite component with the same Location as stored in the
Value-/MethodExpression. And to get the Location of the composite component I
use the InterfaceHandler to store the Location from where the composite
component is created in the composite component's attribute map.
However there are still some problems with MethodExpressions as they are not
really resolved. That is why I did not already provide a patch for this issue,
but I will do this now so that you can take a look at my solution.
The problem with the MethodExpressions is that they are originally created as
ValueExpressions and then (later) changed to MethodExpressions in
FaceletVDL.retargetMethodExpressions. The problem here is that only the
expression string is taken into account. This works perfect on the outer
composite component, but the inner composite component gets something like
#{cc.attr.method} and thus wants to invoke the method method on
CompositeComponentAttributesMapWrapper.
One possible solution would be to look for expression strings with cc.attr in
FaceletVDL.retargetMethodExpressions and keep extracting them until the
expression string does not contain cc.attr, but this is not really a good
solution I think. I've been thinking a lot about this and still haven't found
something much better. Suggestions are welcome!
StackOverflowError if a composite component implementation uses another
composite component
---
Key: MYFACES-2561
URL: https://issues.apache.org/jira/browse/MYFACES-2561
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta-3
Reporter: Jakob Korherr
Assignee: Jakob Korherr
If you use another composite component in your composite component's
implementation you will get a StackOverflowError.
javax.faces.FacesException: java.lang.StackOverflowError
at
org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241)
at
org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:216)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Thread.java:637)
Caused by: java.lang.StackOverflowError
at java.util.ArrayList.toArray(ArrayList.java:306)
at java.util.logging.Logger.getHandlers(Logger.java:1200)
at
java.util.logging.LogManager$RootLogger.getHandlers(LogManager.java:1019)
at java.util.logging.Logger.log(Logger.java:454)
at java.util.logging.Logger.doLog(Logger.java:480)
at java.util.logging.Logger.logp(Logger.java:680)
at org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:167)
at org.apache.juli.logging.DirectJDKLog.error(DirectJDKLog.java:135)
at
[jira] Resolved: (TOBAGO-844) Change type of the markup attribute from String[] to new class Markup
[ https://issues.apache.org/jira/browse/TOBAGO-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-844. Resolution: Fixed Fix Version/s: 1.5.0 1.5.0-alpha-2 Change type of the markup attribute from String[] to new class Markup - Key: TOBAGO-844 URL: https://issues.apache.org/jira/browse/TOBAGO-844 Project: MyFaces Tobago Issue Type: Improvement Components: Core Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Minor Fix For: 1.5.0-alpha-2, 1.5.0 The main reason is performace. It turns out, that clone of a markup string array takes some time in the ResourceManager. When using a class, whith unmodifiable instances, no clone is needed. In addition the oo design is nicer. For ValueBindings it is also possible to use String and String[]. Value 'none' will be deprecated since this change. It has no right to live. One can use a NULL pointer instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-65) add optional compile whitelist
[ https://issues.apache.org/jira/browse/EXTSCRIPT-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-65. -- Resolution: Fixed add optional compile whitelist -- Key: EXTSCRIPT-65 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-65 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz a bigger integration into an existing system has shown that it makes sense to add compiler whitelists, to allow a pointing towards the full source directory but only include certain packages and their subpackages to the compile! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-64) NPE in JSR199Compiler in certain situations
[ https://issues.apache.org/jira/browse/EXTSCRIPT-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-64. -- Resolution: Fixed NPE in JSR199Compiler in certain situations --- Key: EXTSCRIPT-64 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-64 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Werner Punz Assignee: Werner Punz Priority: Minor Seems like the JDK does not have consistent behavior over all platforms diagnostics.getSource can return null values, hence we have to add a null check for everything in createErrorMessage -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-61) Fix parent pom relations before tagging alpha
[ https://issues.apache.org/jira/browse/EXTSCRIPT-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-61. -- Resolution: Fixed Fix parent pom relations before tagging alpha - Key: EXTSCRIPT-61 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-61 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Werner Punz Assignee: Werner Punz Priority: Minor Posted from Marc Struberg Not sure if this is needed in your case, but the pom in extensions/scripting/trunk doesn't contain a parent section. Usually this points (in the end) to parent groupIdorg.apache/groupId artifactIdapache/artifactId version6/version /parent for all Apache projects. Not sure if this is needed in your case, but the pom in extensions/scripting/trunk doesn't contain a parent section. Usually this points (in the end) to parent groupIdorg.apache/groupId artifactIdapache/artifactId version6/version /parent for all Apache projects. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-66) Concurrency problem - startup servlet filter
Concurrency problem - startup servlet filter Key: EXTSCRIPT-66 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-66 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Werner Punz Assignee: Werner Punz Priority: Minor Concurrency problem, the scripting filter should only be active once the startup process of our system is finished -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-62) Dependency detection - interfaces not entirely correctly detected
[ https://issues.apache.org/jira/browse/EXTSCRIPT-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-62. -- Resolution: Fixed Dependency detection - interfaces not entirely correctly detected - Key: EXTSCRIPT-62 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-62 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Werner Punz Assignee: Werner Punz In the dependency detection part of the code object - interface - object relations are not entirely correctly detected. The class which implements the interface does not get a dependency entry, we need to resolve that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-67) concurrency bug
concurrency bug --- Key: EXTSCRIPT-67 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-67 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Werner Punz Assignee: Werner Punz Priority: Minor During the startup process the servlet filter should be deactivated to prevent compile triggers at the wrong points -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2564) facelets in an app with a 1.2 level faces-config do not work
facelets in an app with a 1.2 level faces-config do not work Key: MYFACES-2564 URL: https://issues.apache.org/jira/browse/MYFACES-2564 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Reporter: Michael Concini Assignee: Michael Concini According to section 10.1.2 of the spec: -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2561) StackOverflowError if a composite component implementation uses another composite component
[
https://issues.apache.org/jira/browse/MYFACES-2561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835257#action_12835257
]
Leonardo Uribe commented on MYFACES-2561:
-
I look ri code to find if they changed the evaluation algorithm to solve #{cc}
(if there is a change we can do some hack on our code too). In fact as
supposed, they have its own hack there, so we can change the behavior of the
class
org.apache.myfaces.el.unified.resolver.implicitobject.CompositeComponentImplicitObject.
Use javax.faces.view.Location object is a good idea. I never think about it,
because in theory this object is used to log errors. It is not possible to have
one composite component that has some reference to itself inside
cc:implementation and nest cc:insertChildren or cc:insertFacet (or not?), so
it should be safe to use it as reference.
I remember the problem with FaceletVDL.retargetMethodExpressions. In
TagAttributeImpl.getMethodExpression there is a wrapper that does the
indirection from ValueExpression to MethodExpression. I suppose do something
like:
new TagValueExpressionMethodExpression(this, new
LocationValueExpression(..valueExpr..));
should solve the problem.
StackOverflowError if a composite component implementation uses another
composite component
---
Key: MYFACES-2561
URL: https://issues.apache.org/jira/browse/MYFACES-2561
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta-3
Reporter: Jakob Korherr
Assignee: Jakob Korherr
Attachments: MYFACES-2561.patch, test.xhtml, test1.xhtml, test2.xhtml
If you use another composite component in your composite component's
implementation you will get a StackOverflowError.
javax.faces.FacesException: java.lang.StackOverflowError
at
org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241)
at
org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:216)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Thread.java:637)
Caused by: java.lang.StackOverflowError
at java.util.ArrayList.toArray(ArrayList.java:306)
at java.util.logging.Logger.getHandlers(Logger.java:1200)
at
java.util.logging.LogManager$RootLogger.getHandlers(LogManager.java:1019)
at java.util.logging.Logger.log(Logger.java:454)
at java.util.logging.Logger.doLog(Logger.java:480)
at java.util.logging.Logger.logp(Logger.java:680)
at org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:167)
at org.apache.juli.logging.DirectJDKLog.error(DirectJDKLog.java:135)
at org.apache.catalina.connector.Request.setAttribute(Request.java:1448)
at
org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:503)
at
org.apache.myfaces.context.servlet.RequestMap.setAttribute(RequestMap.java:53)
at
org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:113)
at
org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:1)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.setScope(FacesCompositeELResolver.java:191)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:139)
at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:61)
at org.apache.el.parser.AstValue.getValue(AstValue.java:107)
at
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at
[jira] Commented: (MYFACES-2458) Miscellaneous AJAX bugs
[ https://issues.apache.org/jira/browse/MYFACES-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835259#action_12835259 ] Curtiss Howard commented on MYFACES-2458: - Fixed: * If calling jsf.ajax.request() directly and no options map is specified, the XHR call never occurs because the options map evaluates to undefined. Miscellaneous AJAX bugs --- Key: MYFACES-2458 URL: https://issues.apache.org/jira/browse/MYFACES-2458 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha-2 Reporter: Curtiss Howard Priority: Minor There are a couple minor AJAX-related bugs: * h:commandButton needs to append return false; for onclick when a behavior chain is present. * if f:ajax disabled=true, the AJAX call is still emitted. * Possible issue with f:ajax execute=multiple ids. Seems the javax.faces.partial.execute request param may differ from Sun RI. * Unable to restore StateHolder when listener is specified for f:ajax. * f:ajax onevent not being handled. * f:ajax onerror not being handled. * f:ajax render=@all not working correctly. * f:ajax render=@form not working correctly. * f:ajax render=@this not working correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2561) StackOverflowError if a composite component implementation uses another composite component
[
https://issues.apache.org/jira/browse/MYFACES-2561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835261#action_12835261
]
Leonardo Uribe commented on MYFACES-2561:
-
The reason why it is better to change CompositeComponentImplicitObject is
because use the component stack changes the evaluation value of #{component}
(see the table 5-10)
StackOverflowError if a composite component implementation uses another
composite component
---
Key: MYFACES-2561
URL: https://issues.apache.org/jira/browse/MYFACES-2561
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta-3
Reporter: Jakob Korherr
Assignee: Jakob Korherr
Attachments: MYFACES-2561.patch, test.xhtml, test1.xhtml, test2.xhtml
If you use another composite component in your composite component's
implementation you will get a StackOverflowError.
javax.faces.FacesException: java.lang.StackOverflowError
at
org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241)
at
org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:216)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Thread.java:637)
Caused by: java.lang.StackOverflowError
at java.util.ArrayList.toArray(ArrayList.java:306)
at java.util.logging.Logger.getHandlers(Logger.java:1200)
at
java.util.logging.LogManager$RootLogger.getHandlers(LogManager.java:1019)
at java.util.logging.Logger.log(Logger.java:454)
at java.util.logging.Logger.doLog(Logger.java:480)
at java.util.logging.Logger.logp(Logger.java:680)
at org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:167)
at org.apache.juli.logging.DirectJDKLog.error(DirectJDKLog.java:135)
at org.apache.catalina.connector.Request.setAttribute(Request.java:1448)
at
org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:503)
at
org.apache.myfaces.context.servlet.RequestMap.setAttribute(RequestMap.java:53)
at
org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:113)
at
org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:1)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.setScope(FacesCompositeELResolver.java:191)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:139)
at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:61)
at org.apache.el.parser.AstValue.getValue(AstValue.java:107)
at
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at
org.apache.myfaces.view.facelets.el.TagValueExpression.getValue(TagValueExpression.java:84)
at
org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver$CompositeComponentAttributesMapWrapper.get(CompositeComponentELResolver.java:245)
at javax.el.MapELResolver.getValue(MapELResolver.java:51)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:54)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:140)
at org.apache.el.parser.AstValue.getValue(AstValue.java:118)
at
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at
org.apache.myfaces.view.facelets.el.TagValueExpression.getValue(TagValueExpression.java:84)
at
MYFACES-2564
Hey Michael, I closed your MYFACES-2564 ticket, as we discussed this already. There is another open ticket for the problem -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (TOBAGO-852) Popup is not modal enough
Popup is not modal enough - Key: TOBAGO-852 URL: https://issues.apache.org/jira/browse/TOBAGO-852 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 1.0.24 Environment: Firefox 3.5.8/3.6 (on Windows XP or Ubuntu 9.04/9.10) Reporter: Sven Bunge An open pop-up don't refuse to open a menu through the grey-glass-pane. This behaviour doesn't exist in the Internet Explorer 8 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MYFACES-2564
I'm aware of the previous discussion, however my understanding was that it related more to supporting the using the legacy facelets library and doesn't appear to have anything to do with faces-config versioning. My fix in MYFACES-2564 just brings us into consistent behavior with how verseion info in config files are supposed to be treated. As I've been made to understand it, they are only for use in schema validation and not for use in determining which runtime behaviors are supported. -Mike On 2/18/2010 11:10 AM, Matthias Wessendorf wrote: Hey Michael, I closed your MYFACES-2564 ticket, as we discussed this already. There is another open ticket for the problem -Matthias
[jira] Commented: (MYFACES-2561) StackOverflowError if a composite component implementation uses another composite component
[
https://issues.apache.org/jira/browse/MYFACES-2561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835286#action_12835286
]
Jakob Korherr commented on MYFACES-2561:
I don't see the problem with #{component} when using a LocationValueExpression,
because I only push the component to the stack when I resolve #{cc} and then
afterwards remove it immediatly from the stack. In the meantime no #{component}
can be resolved, which would be disturbed by my algorithm.
StackOverflowError if a composite component implementation uses another
composite component
---
Key: MYFACES-2561
URL: https://issues.apache.org/jira/browse/MYFACES-2561
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta-3
Reporter: Jakob Korherr
Assignee: Jakob Korherr
Attachments: MYFACES-2561.patch, test.xhtml, test1.xhtml, test2.xhtml
If you use another composite component in your composite component's
implementation you will get a StackOverflowError.
javax.faces.FacesException: java.lang.StackOverflowError
at
org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241)
at
org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:216)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Thread.java:637)
Caused by: java.lang.StackOverflowError
at java.util.ArrayList.toArray(ArrayList.java:306)
at java.util.logging.Logger.getHandlers(Logger.java:1200)
at
java.util.logging.LogManager$RootLogger.getHandlers(LogManager.java:1019)
at java.util.logging.Logger.log(Logger.java:454)
at java.util.logging.Logger.doLog(Logger.java:480)
at java.util.logging.Logger.logp(Logger.java:680)
at org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:167)
at org.apache.juli.logging.DirectJDKLog.error(DirectJDKLog.java:135)
at org.apache.catalina.connector.Request.setAttribute(Request.java:1448)
at
org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:503)
at
org.apache.myfaces.context.servlet.RequestMap.setAttribute(RequestMap.java:53)
at
org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:113)
at
org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:1)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.setScope(FacesCompositeELResolver.java:191)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:139)
at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:61)
at org.apache.el.parser.AstValue.getValue(AstValue.java:107)
at
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at
org.apache.myfaces.view.facelets.el.TagValueExpression.getValue(TagValueExpression.java:84)
at
org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver$CompositeComponentAttributesMapWrapper.get(CompositeComponentELResolver.java:245)
at javax.el.MapELResolver.getValue(MapELResolver.java:51)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:54)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:140)
at org.apache.el.parser.AstValue.getValue(AstValue.java:118)
at
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at
[jira] Commented: (MYFACES-2564) facelets in an app with a 1.2 level faces-config do not work
[ https://issues.apache.org/jira/browse/MYFACES-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835289#action_12835289 ] Jakob Korherr commented on MYFACES-2564: Please revert the changes, because on an JSF 1.2 application (faces-config version!=2.0) there are no integrated facelets ;) Thus you have to use facelets 1.1.x! facelets in an app with a 1.2 level faces-config do not work Key: MYFACES-2564 URL: https://issues.apache.org/jira/browse/MYFACES-2564 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Reporter: Michael Concini Assignee: Michael Concini According to section 10.1.2 of the spec: The sole determinant to backwards compatibility lies in the answer to the question, is there any Java code in the application, or in libraries used by the application, that extends from or depends on any class in package com.sun.facelets and/or its sub-packages? ... If the answer to this question is no, Facelets in JSF 2.0 is backwards compatible with pre-JSF 2.0 Facelets and such an application must not continue to bundle the Facelets jar file along with the application, and must not continue to set the Facelets configuration parameters. This implies that simply removing the pre-2.0 facelets bundle should allow the app to run properly again in a 2.0 runtime. The problem is that right now we're doing a check against the version in the faces-config in addition to checking for the context param and the availability of the com/sun/facelets classes. We should only be doing the latter, as the version in the faces-config should only be used for schema validation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (MYFACES-2564) facelets in an app with a 1.2 level faces-config do not work
[ https://issues.apache.org/jira/browse/MYFACES-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr reopened MYFACES-2564: facelets in an app with a 1.2 level faces-config do not work Key: MYFACES-2564 URL: https://issues.apache.org/jira/browse/MYFACES-2564 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Reporter: Michael Concini Assignee: Michael Concini According to section 10.1.2 of the spec: The sole determinant to backwards compatibility lies in the answer to the question, is there any Java code in the application, or in libraries used by the application, that extends from or depends on any class in package com.sun.facelets and/or its sub-packages? ... If the answer to this question is no, Facelets in JSF 2.0 is backwards compatible with pre-JSF 2.0 Facelets and such an application must not continue to bundle the Facelets jar file along with the application, and must not continue to set the Facelets configuration parameters. This implies that simply removing the pre-2.0 facelets bundle should allow the app to run properly again in a 2.0 runtime. The problem is that right now we're doing a check against the version in the faces-config in addition to checking for the context param and the availability of the com/sun/facelets classes. We should only be doing the latter, as the version in the faces-config should only be used for schema validation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MYFACES-2564
I just reopend the issue, because it has nothing to do with the facelets taglibs version problem as Michael said. However the changes are incorrect. Please see my comment in jira and please revert the changes. Regards, Jakob 2010/2/18 Michael Concini mconc...@gmail.com I'm aware of the previous discussion, however my understanding was that it related more to supporting the using the legacy facelets library and doesn't appear to have anything to do with faces-config versioning. My fix in MYFACES-2564 just brings us into consistent behavior with how verseion info in config files are supposed to be treated. As I've been made to understand it, they are only for use in schema validation and not for use in determining which runtime behaviors are supported. -Mike On 2/18/2010 11:10 AM, Matthias Wessendorf wrote: Hey Michael, I closed your MYFACES-2564 ticket, as we discussed this already. There is another open ticket for the problem -Matthias
[jira] Commented: (MYFACES-2561) StackOverflowError if a composite component implementation uses another composite component
[
https://issues.apache.org/jira/browse/MYFACES-2561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835296#action_12835296
]
Leonardo Uribe commented on MYFACES-2561:
-
The problem is do something like this is valid and it should work.
#{cc.attr.property1 == component.property2}
it is possible to imagine other expressions like that (but maybe not very
common). Suppose every el expression that makes reference to cc does not for
component is risky. It is preferred to push the component instance somewhere
else (UIComponent.pushComponentToEL uses facescontext attribute map, so maybe
we can create another stack for this specific case, or maybe use a stack is not
necessary).
StackOverflowError if a composite component implementation uses another
composite component
---
Key: MYFACES-2561
URL: https://issues.apache.org/jira/browse/MYFACES-2561
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta-3
Reporter: Jakob Korherr
Assignee: Jakob Korherr
Attachments: MYFACES-2561.patch, test.xhtml, test1.xhtml, test2.xhtml
If you use another composite component in your composite component's
implementation you will get a StackOverflowError.
javax.faces.FacesException: java.lang.StackOverflowError
at
org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241)
at
org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:216)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Thread.java:637)
Caused by: java.lang.StackOverflowError
at java.util.ArrayList.toArray(ArrayList.java:306)
at java.util.logging.Logger.getHandlers(Logger.java:1200)
at
java.util.logging.LogManager$RootLogger.getHandlers(LogManager.java:1019)
at java.util.logging.Logger.log(Logger.java:454)
at java.util.logging.Logger.doLog(Logger.java:480)
at java.util.logging.Logger.logp(Logger.java:680)
at org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:167)
at org.apache.juli.logging.DirectJDKLog.error(DirectJDKLog.java:135)
at org.apache.catalina.connector.Request.setAttribute(Request.java:1448)
at
org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:503)
at
org.apache.myfaces.context.servlet.RequestMap.setAttribute(RequestMap.java:53)
at
org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:113)
at
org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:1)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.setScope(FacesCompositeELResolver.java:191)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:139)
at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:61)
at org.apache.el.parser.AstValue.getValue(AstValue.java:107)
at
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at
org.apache.myfaces.view.facelets.el.TagValueExpression.getValue(TagValueExpression.java:84)
at
org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver$CompositeComponentAttributesMapWrapper.get(CompositeComponentELResolver.java:245)
at javax.el.MapELResolver.getValue(MapELResolver.java:51)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:54)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:140)
[jira] Commented: (MYFACES-2561) StackOverflowError if a composite component implementation uses another composite component
[ https://issues.apache.org/jira/browse/MYFACES-2561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835299#action_12835299 ] Jakob Korherr commented on MYFACES-2561: Good point, I haven't thought of that. OK I'll change this to set the related composite component to a attribute on the FacesContext and to evaluate this attribute on CompositeComponentImplicitObject. After that and after the problem with the MethodExpressions we can commit the changes, because RI does the same. Or should be let this open with an available patch and wait for the official spec change? StackOverflowError if a composite component implementation uses another composite component --- Key: MYFACES-2561 URL: https://issues.apache.org/jira/browse/MYFACES-2561 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Reporter: Jakob Korherr Assignee: Jakob Korherr Attachments: MYFACES-2561.patch, test.xhtml, test1.xhtml, test2.xhtml If you use another composite component in your composite component's implementation you will get a StackOverflowError. javax.faces.FacesException: java.lang.StackOverflowError at org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241) at org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:216) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:637) Caused by: java.lang.StackOverflowError at java.util.ArrayList.toArray(ArrayList.java:306) at java.util.logging.Logger.getHandlers(Logger.java:1200) at java.util.logging.LogManager$RootLogger.getHandlers(LogManager.java:1019) at java.util.logging.Logger.log(Logger.java:454) at java.util.logging.Logger.doLog(Logger.java:480) at java.util.logging.Logger.logp(Logger.java:680) at org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:167) at org.apache.juli.logging.DirectJDKLog.error(DirectJDKLog.java:135) at org.apache.catalina.connector.Request.setAttribute(Request.java:1448) at org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:503) at org.apache.myfaces.context.servlet.RequestMap.setAttribute(RequestMap.java:53) at org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:113) at org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:1) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.setScope(FacesCompositeELResolver.java:191) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:139) at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:61) at org.apache.el.parser.AstValue.getValue(AstValue.java:107) at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186) at org.apache.myfaces.view.facelets.el.TagValueExpression.getValue(TagValueExpression.java:84) at org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver$CompositeComponentAttributesMapWrapper.get(CompositeComponentELResolver.java:245) at javax.el.MapELResolver.getValue(MapELResolver.java:51) at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:54) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:140) at org.apache.el.parser.AstValue.getValue(AstValue.java:118) at
Re: MYFACES-2564
Jakob, Im not sure I understand what about the fix you think is incorrect. I could use a little more specific explanation. In particular, why would you have to or want to use facelets 1.1.x in this case? The spec says nothing other than that facelets in JSF 2.0 is backwards compatible and that such an application must *NOT *continue to bundle the facelets jar. If you're talking about bundling the facelets jar, then you really are getting into the territory of MYFACES-2543. The way I read section 10.1.2 is that we should only be disabling the facelets VDL is if javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER is set to true. Just because the faces-config version is 1.2, doesn't mean that facelets stops being integrated if you're on a 2.0 runtime. Also, as mentioned in my previous comment, it is my understanding that the version number in a config file is only to be used for schema validation (e.g. determining which resources can be defined and such) and that it is not supposed to be used to determine the behavior of the runtime beyond that. I'm going to get in touch with one of our members of the EE group to get his take on it to be sure though. In the meantime, I'll temporarily back out the change until we can resolve this. -Mike On 2/18/2010 12:05 PM, Jakob Korherr wrote: I just reopend the issue, because it has nothing to do with the facelets taglibs version problem as Michael said. However the changes are incorrect. Please see my comment in jira and please revert the changes. Regards, Jakob 2010/2/18 Michael Concini mconc...@gmail.com mailto:mconc...@gmail.com I'm aware of the previous discussion, however my understanding was that it related more to supporting the using the legacy facelets library and doesn't appear to have anything to do with faces-config versioning. My fix in MYFACES-2564 just brings us into consistent behavior with how verseion info in config files are supposed to be treated. As I've been made to understand it, they are only for use in schema validation and not for use in determining which runtime behaviors are supported. -Mike On 2/18/2010 11:10 AM, Matthias Wessendorf wrote: Hey Michael, I closed your MYFACES-2564 ticket, as we discussed this already. There is another open ticket for the problem -Matthias
Re: MYFACES-2564
On Thu, Feb 18, 2010 at 6:05 PM, Jakob Korherr jakob.korh...@gmail.com wrote: I just reopend the issue, because it has nothing to do with the facelets taglibs version problem as Michael said. :-) I just saw ...If the answer to this question is no, Facelets in JSF 2 and closed it :-) However the changes are incorrect. Please see my comment in jira and please revert the changes. Regards, Jakob 2010/2/18 Michael Concini mconc...@gmail.com I'm aware of the previous discussion, however my understanding was that it related more to supporting the using the legacy facelets library and doesn't appear to have anything to do with faces-config versioning. My fix in MYFACES-2564 just brings us into consistent behavior with how verseion info in config files are supposed to be treated. As I've been made to understand it, they are only for use in schema validation and not for use in determining which runtime behaviors are supported. -Mike On 2/18/2010 11:10 AM, Matthias Wessendorf wrote: Hey Michael, I closed your MYFACES-2564 ticket, as we discussed this already. There is another open ticket for the problem -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (TRINIDAD-1415) allow :alias support to merge in -tr- custom skin properties as well
[
https://issues.apache.org/jira/browse/TRINIDAD-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835366#action_12835366
]
Jeanne Waldman commented on TRINIDAD-1415:
--
I reformatted your patch because the formatting was all off, and I uploaded it
so you can use this.
I added a test case to purple css file
/* Test that aliases that have skinning properties get resolved */
.AFAliasWithSkinProperty:alias {-tr-some-skin-property: true}
af|someComponent {-tr-rule-ref:selector(.AFAliasWithSkinProperty:alias);}
af|anotherComponent {-tr-rule-ref:selector(af|someComponent);}
I ran it and this does not work.
I stopped at this code in the debugger, and the SkinPropertyNode it was
creating had incorrect values.
The key was ok (af|someComponent-tr-some-skin-property), but the value was
.AFAliasWithSkinProperty-tr-some-skin-property instead of 'true'.
// add all alias properties as properties for the referencing
// selectors.
ListSkinPropertyNode addedTrProperties =
new ArrayListSkinPropertyNode();
for (String alias: aliases.keySet())
{
ListString selectors = aliases.get(alias);
for (SkinPropertyNode property: trSkinPropertyNodeList)
{
String propertyName = property.getKey().toString();
if (propertyName.startsWith(alias))
{
String trProperty = propertyName.substring(alias.length());
for (String selectorName: selectors)
{
addedTrProperties.add(_createSkinPropertyNode(selectorName,
trProperty,
propertyName));
}
}
}
trSkinPropertyNodeList.addAll(addedTrProperties);
}
allow :alias support to merge in -tr- custom skin properties as well
Key: TRINIDAD-1415
URL: https://issues.apache.org/jira/browse/TRINIDAD-1415
Project: MyFaces Trinidad
Issue Type: New Feature
Components: Skinning
Affects Versions: 1.2.11-core
Reporter: Jeanne Waldman
Attachments: tr_properties_in_alias.patch
.AFSomeAlias:alias {-tr-my-property: red}
af|foo {-tr-rule-ref: selector(.AFSomeAlias:alias)}
should resolve into:
af|foo {-tr-my-property: red}
so from the renderer you can say,
getSkin().getProperty(af|foot-tr-my-property) and it would return red.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Result (was: [VOTE] release for myfaces core 2.0.0-beta-2)
Hi Thanks to all people who vote. We have 7 +1 Bernd Bohmann Gerhard Petracek Matthias Wessendorf Grant Smith Werner Punz Jakob Korherr Leonardo Uribe so we can continue with the necessary steps to release myfaces core 2.0.0-beta-2 regards, Leonardo Uribe
[jira] Commented: (MYFACES-2561) StackOverflowError if a composite component implementation uses another composite component
[ https://issues.apache.org/jira/browse/MYFACES-2561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835391#action_12835391 ] Jakob Korherr commented on MYFACES-2561: OK I finally solved the MethodExpression problem. This was really not easy to think through. An explanation and the patch will come later.. ;) StackOverflowError if a composite component implementation uses another composite component --- Key: MYFACES-2561 URL: https://issues.apache.org/jira/browse/MYFACES-2561 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Reporter: Jakob Korherr Assignee: Jakob Korherr Attachments: MYFACES-2561.patch, test.xhtml, test1.xhtml, test2.xhtml If you use another composite component in your composite component's implementation you will get a StackOverflowError. javax.faces.FacesException: java.lang.StackOverflowError at org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241) at org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:216) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:637) Caused by: java.lang.StackOverflowError at java.util.ArrayList.toArray(ArrayList.java:306) at java.util.logging.Logger.getHandlers(Logger.java:1200) at java.util.logging.LogManager$RootLogger.getHandlers(LogManager.java:1019) at java.util.logging.Logger.log(Logger.java:454) at java.util.logging.Logger.doLog(Logger.java:480) at java.util.logging.Logger.logp(Logger.java:680) at org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:167) at org.apache.juli.logging.DirectJDKLog.error(DirectJDKLog.java:135) at org.apache.catalina.connector.Request.setAttribute(Request.java:1448) at org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:503) at org.apache.myfaces.context.servlet.RequestMap.setAttribute(RequestMap.java:53) at org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:113) at org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:1) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.setScope(FacesCompositeELResolver.java:191) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:139) at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:61) at org.apache.el.parser.AstValue.getValue(AstValue.java:107) at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186) at org.apache.myfaces.view.facelets.el.TagValueExpression.getValue(TagValueExpression.java:84) at org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver$CompositeComponentAttributesMapWrapper.get(CompositeComponentELResolver.java:245) at javax.el.MapELResolver.getValue(MapELResolver.java:51) at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:54) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:140) at org.apache.el.parser.AstValue.getValue(AstValue.java:118) at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186) at org.apache.myfaces.view.facelets.el.TagValueExpression.getValue(TagValueExpression.java:84) at
Re: Result (was: [VOTE] release for myfaces core 2.0.0-beta-2)
yeah! :) On Thu, Feb 18, 2010 at 9:27 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Thanks to all people who vote. We have 7 +1 Bernd Bohmann Gerhard Petracek Matthias Wessendorf Grant Smith Werner Punz Jakob Korherr Leonardo Uribe so we can continue with the necessary steps to release myfaces core 2.0.0-beta-2 regards, Leonardo Uribe -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2561) StackOverflowError if a composite component implementation uses another composite component
[
https://issues.apache.org/jira/browse/MYFACES-2561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835428#action_12835428
]
Leonardo Uribe commented on MYFACES-2561:
-
Thinking more about it maybe we need a stack that keeps track of resolved #{cc}
instances. It is possible to have multiple indirections between composite
components, and just a variable is not enough.
I would like to have the patch here, just as reference and commit the code. If
RI has the fix, we should provide it too.
StackOverflowError if a composite component implementation uses another
composite component
---
Key: MYFACES-2561
URL: https://issues.apache.org/jira/browse/MYFACES-2561
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta-3
Reporter: Jakob Korherr
Assignee: Jakob Korherr
Attachments: MYFACES-2561.patch, test.xhtml, test1.xhtml, test2.xhtml
If you use another composite component in your composite component's
implementation you will get a StackOverflowError.
javax.faces.FacesException: java.lang.StackOverflowError
at
org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241)
at
org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:216)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Thread.java:637)
Caused by: java.lang.StackOverflowError
at java.util.ArrayList.toArray(ArrayList.java:306)
at java.util.logging.Logger.getHandlers(Logger.java:1200)
at
java.util.logging.LogManager$RootLogger.getHandlers(LogManager.java:1019)
at java.util.logging.Logger.log(Logger.java:454)
at java.util.logging.Logger.doLog(Logger.java:480)
at java.util.logging.Logger.logp(Logger.java:680)
at org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:167)
at org.apache.juli.logging.DirectJDKLog.error(DirectJDKLog.java:135)
at org.apache.catalina.connector.Request.setAttribute(Request.java:1448)
at
org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:503)
at
org.apache.myfaces.context.servlet.RequestMap.setAttribute(RequestMap.java:53)
at
org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:113)
at
org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:1)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.setScope(FacesCompositeELResolver.java:191)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:139)
at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:61)
at org.apache.el.parser.AstValue.getValue(AstValue.java:107)
at
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at
org.apache.myfaces.view.facelets.el.TagValueExpression.getValue(TagValueExpression.java:84)
at
org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver$CompositeComponentAttributesMapWrapper.get(CompositeComponentELResolver.java:245)
at javax.el.MapELResolver.getValue(MapELResolver.java:51)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:54)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:140)
at org.apache.el.parser.AstValue.getValue(AstValue.java:118)
at
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at
[jira] Commented: (MYFACES-2561) StackOverflowError if a composite component implementation uses another composite component
[ https://issues.apache.org/jira/browse/MYFACES-2561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835430#action_12835430 ] Jakob Korherr commented on MYFACES-2561: To solve the problem with the MethodExpression I introduced something similar to that. You'll see! StackOverflowError if a composite component implementation uses another composite component --- Key: MYFACES-2561 URL: https://issues.apache.org/jira/browse/MYFACES-2561 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Reporter: Jakob Korherr Assignee: Jakob Korherr Attachments: MYFACES-2561.patch, test.xhtml, test1.xhtml, test2.xhtml If you use another composite component in your composite component's implementation you will get a StackOverflowError. javax.faces.FacesException: java.lang.StackOverflowError at org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241) at org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:216) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:637) Caused by: java.lang.StackOverflowError at java.util.ArrayList.toArray(ArrayList.java:306) at java.util.logging.Logger.getHandlers(Logger.java:1200) at java.util.logging.LogManager$RootLogger.getHandlers(LogManager.java:1019) at java.util.logging.Logger.log(Logger.java:454) at java.util.logging.Logger.doLog(Logger.java:480) at java.util.logging.Logger.logp(Logger.java:680) at org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:167) at org.apache.juli.logging.DirectJDKLog.error(DirectJDKLog.java:135) at org.apache.catalina.connector.Request.setAttribute(Request.java:1448) at org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:503) at org.apache.myfaces.context.servlet.RequestMap.setAttribute(RequestMap.java:53) at org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:113) at org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:1) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.setScope(FacesCompositeELResolver.java:191) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:139) at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:61) at org.apache.el.parser.AstValue.getValue(AstValue.java:107) at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186) at org.apache.myfaces.view.facelets.el.TagValueExpression.getValue(TagValueExpression.java:84) at org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver$CompositeComponentAttributesMapWrapper.get(CompositeComponentELResolver.java:245) at javax.el.MapELResolver.getValue(MapELResolver.java:51) at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:54) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:140) at org.apache.el.parser.AstValue.getValue(AstValue.java:118) at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186) at org.apache.myfaces.view.facelets.el.TagValueExpression.getValue(TagValueExpression.java:84) at org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver$CompositeComponentAttributesMapWrapper.get(CompositeComponentELResolver.java:245)
Re: [Trinidad][Skinning] Introduce include-Property in CSS
What do you mean by 'mode' dependent?
Marius Petoi wrote, On 2/3/2010 11:17 PM PT:
Ok Jeanne. Thank you!
One more question, in order to transform the XSS files in CSS files, in
base-desktop.xss there are some styles which are mode-dependent. Should
we add @mode in the CSS? Or do you have any other idea?
Marius
On Thu, Feb 4, 2010 at 7:17 AM, Jeanne
Waldman jeanne.wald...@oracle.com
wrote:
Hi,
I looked into the performance issues and they have nothing to do with
the new features we have been adding recently, so we are ok to add
patches.
I'll add this to my todo list, but if anyone else has some time in the
next couple of days, feel free to review the patch.
Jeanne
Jeanne Waldman wrote, On 1/21/2010 11:51 AM PT:
Ok. Our performance team has noticed the
Skinning Framework is using
more memory than not that long ago, so I want to look into that before
we add anymore patches.
Jeanne
Marius Petoi wrote, On 1/19/2010 1:23 AM PT:
Hi Jeanne,
The new patch is ready.
Marius
On Tue, Jan 19, 2010 at 8:58 AM,
Marius
Petoi marius.pe...@codebeat.ro
wrote:
Ok.
Then I shall adapt dealing with the aliases and I shall inform you when
the new patch is ready.
Marius
On Mon, Jan 18, 2010 at 11:16 PM,
Jeanne
Waldman jeanne.wald...@oracle.com
wrote:
I'm fine with your
syntax. I think it is clearer as well. I was just
giving an alternative option if people wanted to vote on it.
Marius Petoi wrote, On 1/15/2010 12:05 AM PT:
Yes, 'name' is an alias...I
introduced
it
because I saw it
was done this way in the XSS. I will remove it. Are you saying I should
change the syntax? I personally think it is clearer this way.
Marius
On Fri, Jan 15, 2010 at 1:45 AM,
Jeanne
Waldman jeanne.wald...@oracle.com
wrote:
What is 'name'?
Is
that
an
alias? We distinguished between selector and
name in XSS but we don't in the CSS format. We still do in the code,
but the person working with the css shouldn't know the difference.
Yes, the con of my suggestion is that order matters and the user needs
to know what the order means .I can see them not knowing is color what
I'm setting or is color what I'm retrieving? That is what I think the
con is for the CSS syntax like padding: 0px 2px 3px 4px
Regarding your link, I haven't had time to look at that yet.
Jeanne
Marius Petoi wrote, On 1/12/2010 11:46 PM PT:
Hi Jeanne,
Thank you for the answer! Like in the situation of -tr-rule-ref, the
list of properties is comma separated. I don't understand what you mean
by camel-case...The name of the new property can be whatever the user
wishes for. Afterwards, it will be treated like all the other
properties in the CSS. Regarding the new syntax you suggested, first of
all, we may have a selector or a name, in which case "selector" is
replaced with "name". Also, another problem is the order in which they
appear; with this syntax it can be any order.
How about http://markmail.org/search/?q=skinning%20list%3Aorg.apache.myfaces.dev#query:skinning%20list%3Aorg.apache.myfaces.dev%20order%3Adate-backward+page:3+mid:3au5ilvrrpbxopgx+state:results
? Did you have the time to look over it too?
Regards,
Marius
On Tue, Jan 12, 2010 at
11:58
PM,
Jeanne
Waldman jeanne.wald...@oracle.com
wrote:
Another idea for the syntax comes from the rgb color syntax -
color: rgb(100%, 0%, 0%)
You could use this syntax, and not specify what each of the properties is for:
-tr-include-property:
property("af|foo", "color", "background-color")
or
property(af|foo, color, background-color)
I like this because it's shorter, but I don't like it since they will have to look up which is which, something I have to do when I use the border: 0px 3px 2px 1px syntax - which is right, left, top, bottom.
Jeanne
Jeanne Waldman wrote, On 1/12/2010 10:21 AM PT:
Hi,
Thanks for this patch.
I will have to look at the CSS spec to see if this syntax conforms to
other CSS syntaxes. This is what I usually do when I try to come up
with a new skinning api.
Like, is the comma standard, or should it be space-separated? Is the
camel-case standard, or should it be '-'s.
I think it looks good, but I'll have to look at it closer before I vote.
Jeanne
Marius Petoi wrote, On 1/11/2010 4:52 AM PT:
Is there anyone who has
already
reviewed
this or added
them on
[jira] Commented: (TOMAHAWK-1472) Add Support for new Resource API in tomahawk 2.0 module
[
https://issues.apache.org/jira/browse/TOMAHAWK-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835438#action_12835438
]
Leonardo Uribe commented on TOMAHAWK-1472:
--
Trying to do this issue I found the following use case (all this snippets
happens on renderers)
if( tabbedPane.isClientSide() ){
addResource.addJavaScriptAtPosition(facesContext,
AddResource.HEADER_BEGIN, HtmlTabbedPaneRenderer.class, dynamicTabs.js);
This one is similar:
if (schedule.isTooltip())
{
addResource.addJavaScriptAtPosition(context,
AddResource.HEADER_BEGIN,
HtmlSchedule.class, javascript/alphaAPI.js);
Or this one:
if (DEFAULT_THEME.equals(theme) || OUTLOOK_THEME.equals(theme)
|| EVOLUTION_THEME.equals(theme))
{
addResource.addStyleSheet(context, AddResource.HEADER_BEGIN,
HtmlSchedule.class, CSS_RESOURCE);
}
The new JSF 2.0 Resource Api does not support conditional rendering for
resources out of the box. To solve this one, we need the resource has a
reference or a way to find the owner resource and check this condition when it
is rendered. That means we need a custom resource renderer that check the
condition.
Note the condition originally is evaluated each time on render response time,
but the new JSF 2.0 Resource Api requires all resources were added before that.
We don't have an event that gives the chance to register it before render
response.
Other option is copy the value or ValueExpression required in the condition on
the resource component, but this does not look good.
We have to try another alternative (a custom component event?), but it is not
still clear how to do that.
Add Support for new Resource API in tomahawk 2.0 module
---
Key: TOMAHAWK-1472
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1472
Project: MyFaces Tomahawk
Issue Type: Task
Reporter: Leonardo Uribe
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1731) Improve Formatting of Tag Doc Summary section
[ https://issues.apache.org/jira/browse/TRINIDAD-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Kaval updated TRINIDAD-1731: -- Status: Patch Available (was: Open) Improve Formatting of Tag Doc Summary section - Key: TRINIDAD-1731 URL: https://issues.apache.org/jira/browse/TRINIDAD-1731 Project: MyFaces Trinidad Issue Type: Improvement Components: Documentation Affects Versions: 1.2.12-plugins Reporter: Maria Kaval Priority: Minor Attachments: trinidad_new_summary.PNG Today the summary section of the tag doc (the top section where it lists for example the tag name, component class, component type and whether or not something is a naming container doesn't have very nice formatting. As an example see http://myfaces.apache.org/trinidad/trinidad-api/tagdoc/tr_table.html With this JIRA I will instead generate an HTML table, so that the left side and right side are well-aligned, and it will be cleaner to read. I will make the formatting of the lines consistent (bold on left, each word starts with a capital letter, each phrase ends with a colon and each line takes up the same amount of space - today some lines have white space around them while others don't). The summary section table will be in a div to allow CSS styling separate from other tables in the tag doc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1732) Code Cleanup: Move to using generics in the trinidad-maven project
[
https://issues.apache.org/jira/browse/TRINIDAD-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maria Kaval updated TRINIDAD-1732:
--
Status: Patch Available (was: Open)
Code Cleanup: Move to using generics in the trinidad-maven project
---
Key: TRINIDAD-1732
URL: https://issues.apache.org/jira/browse/TRINIDAD-1732
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Documentation
Affects Versions: 1.2.12-plugins
Reporter: Maria Kaval
Priority: Minor
As a code clean-up task, move to using Generics in the trinidad-maven
project, so e.g. instead of:
Iterator renderkits = facesConfig.renderKits();
while (renderkits.hasNext())
{
RenderKitBean renderkit = (RenderKitBean) renderkits.next();
change the code to:
IteratorRenderKitBean renderkits = facesConfig.renderKits();
while (renderkits.hasNext())
{
RenderKitBean renderkit = renderkits.next();
As part of this changeover I found one bug in ComponentBean.java where it
seems the code was improperly casting to an EventBean when really the object
was an EventRefBean.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1732) Code Cleanup: Move to using generics in the trinidad-maven project
Code Cleanup: Move to using generics in the trinidad-maven project
---
Key: TRINIDAD-1732
URL: https://issues.apache.org/jira/browse/TRINIDAD-1732
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Documentation
Affects Versions: 1.2.12-plugins
Reporter: Maria Kaval
Priority: Minor
As a code clean-up task, move to using Generics in the trinidad-maven project,
so e.g. instead of:
Iterator renderkits = facesConfig.renderKits();
while (renderkits.hasNext())
{
RenderKitBean renderkit = (RenderKitBean) renderkits.next();
change the code to:
IteratorRenderKitBean renderkits = facesConfig.renderKits();
while (renderkits.hasNext())
{
RenderKitBean renderkit = renderkits.next();
As part of this changeover I found one bug in ComponentBean.java where it seems
the code was improperly casting to an EventBean when really the object was an
EventRefBean.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [Trinidad][Skinning] Introduce include-Property in CSS
For example the definition of the following style sheet: styleSheet platforms=windows ppc browsers=ie versions=6 mode=quirks //. These are styles defined only for quirks mode. But in CSS this feature is not implemented... Marius On Fri, Feb 19, 2010 at 12:13 AM, Jeanne Waldman jeanne.wald...@oracle.comwrote: What do you mean by 'mode' dependent? Marius Petoi wrote, On 2/3/2010 11:17 PM PT: Ok Jeanne. Thank you! One more question, in order to transform the XSS files in CSS files, in base-desktop.xss there are some styles which are mode-dependent. Should we add @mode in the CSS? Or do you have any other idea? Marius On Thu, Feb 4, 2010 at 7:17 AM, Jeanne Waldman jeanne.wald...@oracle.comwrote: Hi, I looked into the performance issues and they have nothing to do with the new features we have been adding recently, so we are ok to add patches. I'll add this to my todo list, but if anyone else has some time in the next couple of days, feel free to review the patch. Jeanne Jeanne Waldman wrote, On 1/21/2010 11:51 AM PT: Ok. Our performance team has noticed the Skinning Framework is using more memory than not that long ago, so I want to look into that before we add anymore patches. Jeanne Marius Petoi wrote, On 1/19/2010 1:23 AM PT: Hi Jeanne, The new patch is ready. Marius On Tue, Jan 19, 2010 at 8:58 AM, Marius Petoi marius.pe...@codebeat.rowrote: Ok. Then I shall adapt dealing with the aliases and I shall inform you when the new patch is ready. Marius On Mon, Jan 18, 2010 at 11:16 PM, Jeanne Waldman jeanne.wald...@oracle.com wrote: I'm fine with your syntax. I think it is clearer as well. I was just giving an alternative option if people wanted to vote on it. Marius Petoi wrote, On 1/15/2010 12:05 AM PT: Yes, 'name' is an alias...I introduced it because I saw it was done this way in the XSS. I will remove it. Are you saying I should change the syntax? I personally think it is clearer this way. Marius On Fri, Jan 15, 2010 at 1:45 AM, Jeanne Waldman jeanne.wald...@oracle.com wrote: What is 'name'? Is that an alias? We distinguished between selector and name in XSS but we don't in the CSS format. We still do in the code, but the person working with the css shouldn't know the difference. Yes, the con of my suggestion is that order matters and the user needs to know what the order means .I can see them not knowing is color what I'm setting or is color what I'm retrieving? That is what I think the con is for the CSS syntax like *padding: 0px 2px 3px 4px* Regarding your link, I haven't had time to look at that yet. Jeanne Marius Petoi wrote, On 1/12/2010 11:46 PM PT: Hi Jeanne, Thank you for the answer! Like in the situation of -tr-rule-ref, the list of properties is comma separated. I don't understand what you mean by camel-case...The name of the new property can be whatever the user wishes for. Afterwards, it will be treated like all the other properties in the CSS. Regarding the new syntax you suggested, first of all, we may have a selector or a name, in which case selector is replaced with name. Also, another problem is the order in which they appear; with this syntax it can be any order. How about http://markmail.org/search/?q=skinning%20list%3Aorg.apache.myfaces.dev#query:skinning%20list%3Aorg.apache.myfaces.dev%20order%3Adate-backward+page:3+mid:3au5ilvrrpbxopgx+state:results? Did you have the time to look over it too? Regards, Marius On Tue, Jan 12, 2010 at 11:58 PM, Jeanne Waldman jeanne.wald...@oracle.com wrote: Another idea for the syntax comes from the rgb color syntax - color: rgb(100%, 0%, 0%) You could use this syntax, and not specify what each of the properties is for:-tr-include-property: property(af|foo, color, background-color) or property(af|foo, color, background-color) I like this because it's shorter, but I don't like it since they will have to look up which is which, something I have to do when I use the border: 0px 3px 2px 1px syntax - which is right, left, top, bottom. Jeanne Jeanne Waldman wrote, On 1/12/2010 10:21 AM PT: Hi, Thanks for this patch. I will have to look at the CSS spec to see if this syntax conforms to other CSS syntaxes. This is what I usually do when I try to come up with a new skinning api. Like, is the comma standard, or should it be space-separated? Is the camel-case standard, or should it be '-'s. I think it looks good, but I'll have to look at it closer before I vote. Jeanne Marius Petoi wrote, On 1/11/2010 4:52 AM PT: Is there anyone who has already reviewed this or added them on his/her TODO list? Thank you in advance! Marius On Fri, Jan 8, 2010 at 11:35 AM, Marius Petoi marius.pe...@codebeat.ro wrote: Hello, I created a new JIRA task for this issue ( https://issues.apache.org/jira/browse/TRINIDAD-1680) and I added a patch for it. I introduced a new -tr property:
