[jira] Created: (EXTCDI-127) Injection in FacesConverter does not work
Injection in FacesConverter does not work
-
Key: EXTCDI-127
URL: https://issues.apache.org/jira/browse/EXTCDI-127
Project: MyFaces CODI
Issue Type: Bug
Components: JEE-JSF20-Module
Affects Versions: 0.9.2
Environment: Myfaces 2.0.3, CODI 0.9.2, ExtVal 2.0.4, OWB 1.0.0,
PrimeFaces 2.2-RC2
Reporter: Thomas Andraschko
The bean which sould be injected in my converter is always null.
I also added some logging to CODI, to see where the problem is.
The bean was created and injected into the converter but it seems as the used
converter is not the converter which was created by CODI.
Is there something wrong in my setup or is this really a bug?
---
@Advanced
@FacesConverter(localeConverter)
public class LocaleConverter implements Converter {
@Inject private LocaleService localeService;
---
h:form
h:selectOneMenu
id=selectLocaleMenu
value=#{localeController.selectedLocale}
onchange=this.form.submit()
converter=localeConverter
f:selectItems
value=#{allLocalesController.locales}
var=locale
itemLabel=#{locale.name}
itemValue=#{locale}/
/h:selectOneMenu
/h:form
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTCDI-127) Injection in FacesConverter does not work
[
https://issues.apache.org/jira/browse/EXTCDI-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12986978#action_12986978
]
Thomas Andraschko commented on EXTCDI-127:
--
thanks for your effort, Jakob!
Injection in FacesConverter does not work
-
Key: EXTCDI-127
URL: https://issues.apache.org/jira/browse/EXTCDI-127
Project: MyFaces CODI
Issue Type: Bug
Components: JEE-JSF20-Module
Affects Versions: 0.9.2
Environment: Myfaces 2.0.3, CODI 0.9.2, ExtVal 2.0.4, OWB 1.0.0,
PrimeFaces 2.2-RC2
Reporter: Thomas Andraschko
Assignee: Jakob Korherr
The bean which sould be injected in my converter is always null.
I also added some logging to CODI, to see where the problem is.
The bean was created and injected into the converter but it seems as the used
converter is not the converter which was created by CODI.
Is there something wrong in my setup or is this really a bug?
---
@Advanced
@FacesConverter(localeConverter)
public class LocaleConverter implements Converter {
@Inject private LocaleService localeService;
---
h:form
h:selectOneMenu
id=selectLocaleMenu
value=#{localeController.selectedLocale}
onchange=this.form.submit()
converter=localeConverter
f:selectItems
value=#{allLocalesController.locales}
var=locale
itemLabel=#{locale.name}
itemValue=#{locale}/
/h:selectOneMenu
/h:form
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTCDI-128) Injection in BV MessageInterpolator does not work
Injection in BV MessageInterpolator does not work - Key: EXTCDI-128 URL: https://issues.apache.org/jira/browse/EXTCDI-128 Project: MyFaces CODI Issue Type: Bug Components: JEE-BV1-Module, JEE-JSF20-Module Affects Versions: 0.9.2 Environment: Myfaces 2.0.3, CODI 0.9.2, ExtVal 2.0.4, OWB 1.0.0, PrimeFaces 2.2-RC2 Reporter: Thomas Andraschko The getMessageInterpolator() method in InvalidValueAwareValidatorFactory injects the bean into the wrong MessageInterpolator. In my opinion CODI should do injection into the unwrapped MessageInterpolator (getValidatorFactory().getMessageInterpolator()). I have tested this in my environment and works without problems. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] [Commented] (EXTCDI-118) Could not serialize state: org.jboss.weld.bean.ManagedBean
[ https://issues.apache.org/jira/browse/EXTCDI-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13054919#comment-13054919 ] Thomas Andraschko commented on EXTCDI-118: -- It does not work with Weld 1.1.2-SNAPSHOT! (I don't use codi in this project, i just commented this issue to get more information) Could not serialize state: org.jboss.weld.bean.ManagedBean -- Key: EXTCDI-118 URL: https://issues.apache.org/jira/browse/EXTCDI-118 Project: MyFaces CODI Issue Type: Bug Affects Versions: 0.9.1, 0.9.2 Environment: JbossAS6Final, MyFaces2, jdk1.6_21, win7 64bit Reporter: Michael Schuetz Priority: Minor Having MyFaces configured now. Getting following error: 09:58:21,068 INFO [org.apache.myfaces.util.ExternalSpecifications] MyFaces Unified EL support enabled 09:58:21,209 INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/myfaces-cdi-1.0.2-SNAPSHOT]] No state saving method defined, assuming default server state saving 09:58:28,820 SCHWERWIEGEND [org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementHelper] Exiting serializeView - Could not serialize state: org.jboss.weld.bean.ManagedBean: java.io.NotSerializableException: org.jboss.weld.bean.ManagedBean at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156) [:1.6.0_21] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) [:1.6.0_21] at java.util.concurrent.ConcurrentHashMap.writeObject(ConcurrentHashMap.java:1246) [:1.6.0_21] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_21] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_21] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_21] at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_21] at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945) [:1.6.0_21] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461) [:1.6.0_21] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392) [:1.6.0_21] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) [:1.6.0_21] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) [:1.6.0_21] at java.util.HashMap.writeObject(HashMap.java:1001) [:1.6.0_21] at sun.reflect.GeneratedMethodAccessor270.invoke(Unknown Source) [:1.6.0_21] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTVAL-144) ExtVal should not overwrite maxLength defined in xhtml
Thomas Andraschko created EXTVAL-144: Summary: ExtVal should not overwrite maxLength defined in xhtml Key: EXTVAL-144 URL: https://issues.apache.org/jira/browse/EXTVAL-144 Project: MyFaces Extensions Validator Issue Type: Bug Components: Core Affects Versions: 2.0.4 Reporter: Thomas Andraschko Currently ExtVal overwrites maxLength if a @Column or @Size annotation is available. ExtVal should not overwrite it, if the maxLength attribute is already defined. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTVAL-145) [perf] Cache renderer interceptors as list
Thomas Andraschko created EXTVAL-145: Summary: [perf] Cache renderer interceptors as list Key: EXTVAL-145 URL: https://issues.apache.org/jira/browse/EXTVAL-145 Project: MyFaces Extensions Validator Issue Type: Bug Components: Core Affects Versions: 2.0.5, 2.0.6 Reporter: Thomas Andraschko Attachments: EXTVAL-145.patch Caching of the renderer interceptors decrease the execution time from 51ms to 0.5ms for a big page/many invocations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTVAL-146) [perf] Reduce logging/string operations in ExtValRendererWrapper
Thomas Andraschko created EXTVAL-146: Summary: [perf] Reduce logging/string operations in ExtValRendererWrapper Key: EXTVAL-146 URL: https://issues.apache.org/jira/browse/EXTVAL-146 Project: MyFaces Extensions Validator Issue Type: Bug Components: Core Affects Versions: 2.0.5, 2.0.6 Reporter: Thomas Andraschko Attachments: EXTVAL-146.patch Improvement on a big page: encodeChilren: 634ms - 5ms encodeEnd: 141ms - 13.5ms encodeBegin: 139ms - 16.2ms -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-298) [perf] reduce overhead in ClassUtils
Thomas Andraschko created EXTCDI-298: Summary: [perf] reduce overhead in ClassUtils Key: EXTCDI-298 URL: https://issues.apache.org/jira/browse/EXTCDI-298 Project: MyFaces CODI Issue Type: Improvement Reporter: Thomas Andraschko As discussed with gerhard, i removed the #doPriviliged which improved the method execution duration from 50ms to 0ms (30.000 invocations / request) I also added a class cache which improves loadClassForName from 62ms to 6ms for 9600 invocations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-298) [perf] reduce overhead in ClassUtils
[ https://issues.apache.org/jira/browse/EXTCDI-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411445#comment-13411445 ] Thomas Andraschko commented on EXTCDI-298: -- Is there another solution for the class cache? 60ms is much - also with profiling overhead. [perf] reduce overhead in ClassUtils Key: EXTCDI-298 URL: https://issues.apache.org/jira/browse/EXTCDI-298 Project: MyFaces CODI Issue Type: Improvement Reporter: Thomas Andraschko Assignee: Mark Struberg Attachments: EXTCDI-298.patch As discussed with gerhard, i removed the #doPriviliged which improved the method execution duration from 50ms to 0ms (30.000 invocations / request) I also added a class cache which improves loadClassForName from 62ms to 6ms for 9600 invocations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-298) [perf] reduce overhead in ClassUtils
[ https://issues.apache.org/jira/browse/EXTCDI-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411460#comment-13411460 ] Thomas Andraschko commented on EXTCDI-298: -- Will test it later, thanks! loadClassForName is called arround 9600 / request. That's because i have 1-5 links / row in my repeater with 2000 items. Maybe a className/outcome cache is possible? [perf] reduce overhead in ClassUtils Key: EXTCDI-298 URL: https://issues.apache.org/jira/browse/EXTCDI-298 Project: MyFaces CODI Issue Type: Improvement Reporter: Thomas Andraschko Assignee: Mark Struberg Attachments: EXTCDI-298.patch As discussed with gerhard, i removed the #doPriviliged which improved the method execution duration from 50ms to 0ms (30.000 invocations / request) I also added a class cache which improves loadClassForName from 62ms to 6ms for 9600 invocations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-298) [perf] reduce overhead in ClassUtils
[ https://issues.apache.org/jira/browse/EXTCDI-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411465#comment-13411465 ] Thomas Andraschko commented on EXTCDI-298: -- Also i know that the classes could be different in WebAppA and WebAppB. Therefore i added the classloader, too :) [perf] reduce overhead in ClassUtils Key: EXTCDI-298 URL: https://issues.apache.org/jira/browse/EXTCDI-298 Project: MyFaces CODI Issue Type: Improvement Reporter: Thomas Andraschko Assignee: Mark Struberg Attachments: EXTCDI-298.patch As discussed with gerhard, i removed the #doPriviliged which improved the method execution duration from 50ms to 0ms (30.000 invocations / request) I also added a class cache which improves loadClassForName from 62ms to 6ms for 9600 invocations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-298) [perf] reduce overhead in ClassUtils
[ https://issues.apache.org/jira/browse/EXTCDI-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411557#comment-13411557 ] Thomas Andraschko commented on EXTCDI-298: -- Would it be possible to cache NavigationCase/outcome in CodiNavigationHandler? I already done a patch but don't know if there are other drawbacks then. [perf] reduce overhead in ClassUtils Key: EXTCDI-298 URL: https://issues.apache.org/jira/browse/EXTCDI-298 Project: MyFaces CODI Issue Type: Improvement Reporter: Thomas Andraschko Assignee: Mark Struberg Attachments: EXTCDI-298.patch As discussed with gerhard, i removed the #doPriviliged which improved the method execution duration from 50ms to 0ms (30.000 invocations / request) I also added a class cache which improves loadClassForName from 62ms to 6ms for 9600 invocations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-298) [perf] reduce overhead in ClassUtils
[ https://issues.apache.org/jira/browse/EXTCDI-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411637#comment-13411637 ] Thomas Andraschko commented on EXTCDI-298: -- ok. if you think a outcome/navigationCase cache in the NavigationHandler is ok, just ping me and i could provide a patch. [perf] reduce overhead in ClassUtils Key: EXTCDI-298 URL: https://issues.apache.org/jira/browse/EXTCDI-298 Project: MyFaces CODI Issue Type: Improvement Reporter: Thomas Andraschko Assignee: Mark Struberg Attachments: EXTCDI-298.patch As discussed with gerhard, i removed the #doPriviliged which improved the method execution duration from 50ms to 0ms (30.000 invocations / request) I also added a class cache which improves loadClassForName from 62ms to 6ms for 9600 invocations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3587) Not existing viewId will not be handled
Thomas Andraschko created MYFACES-3587: -- Summary: Not existing viewId will not be handled Key: MYFACES-3587 URL: https://issues.apache.org/jira/browse/MYFACES-3587 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.8 Environment: Jetty/Tomcat, JUEL, CODI, ExtVal Reporter: Thomas Andraschko If i call a page, which does not exist, following exceptions occurs: Cannot reset buffer after response has been committed. After digging deeper into this problem, i found out that getViewHandlerSupport()#calculateViewId returns null and the JspViewDeclarationLanguageStrategy will be used - Cannot reset buffer after response has been committed. occurs. I added a null check for the logicalViewId in RestoreViewExecutor#execute to call HttpServletResponse#sendError. It does not work as expected because it just renders the errorPage and no redirect will be done. Why there is not such null check? Is it possible to add this check and redirect to the web.xml defined 404 or common error page? Or should it use the ErrorHandler? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3605) Expression ClassCastException
Thomas Andraschko created MYFACES-3605: -- Summary: Expression ClassCastException Key: MYFACES-3605 URL: https://issues.apache.org/jira/browse/MYFACES-3605 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.9-SNAPSHOT Reporter: Thomas Andraschko Priority: Critical After upgrading from 2.1.8 to 2.1.9 follwing exceptions occurs: Caused by: java.lang.ClassCastException: org.apache.myfaces.view.facelets.el.ContextAwareTagMethodExpression cannot be cast to org.apache.myfaces.view.facelets.el.LocationMethodExpression at org.apache.myfaces.view.facelets.tag.TagAttributeImpl.getMethodExpression(TagAttributeImpl.java:222) at org.apache.myfaces.view.facelets.tag.jsf.core.EventHandler.apply(EventHandler.java:125) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:294) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:294) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at org.apache.myfaces.view.facelets.tag.composite.ImplementationHandler.apply(ImplementationHandler.java:67) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at org.apache.myfaces.view.facelets.tag.composite.CompositeComponentDefinitionTagHandler.apply(CompositeComponentDefinitionTagHandler.java:255) at org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:57) at org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:48) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.applyCompositeComponent(DefaultFacelet.java:482) at org.apache.myfaces.view.facelets.impl.DefaultFaceletContext.applyCompositeComponent(DefaultFaceletContext.java:779) at org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler.applyCompositeComponentFacelet(CompositeComponentResourceTagHandler.java:378) at org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler.applyNextHandler(CompositeComponentResourceTagHandler.java:158) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:294) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at org.apache.myfaces.view.facelets.tag.ui.DefineHandler.applyDefinition(DefineHandler.java:86) at org.apache.myfaces.view.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:175) at org.apache.myfaces.view.facelets.impl.TemplateContextImpl$TemplateManagerImpl.apply(TemplateContextImpl.java:186) at org.apache.myfaces.view.facelets.impl.TemplateContextImpl.includeDefinition(TemplateContextImpl.java:131) at org.apache.myfaces.view.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:460) at org.apache.myfaces.view.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:94) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:294) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at org.apache.myfaces.view.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:156) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:57) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:48) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:394) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:448) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:426) at
[jira] [Commented] (MYFACES-3605) Expression ClassCastException
[ https://issues.apache.org/jira/browse/MYFACES-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453109#comment-13453109 ] Thomas Andraschko commented on MYFACES-3605: Thanks, works fine now! :) Expression ClassCastException --- Key: MYFACES-3605 URL: https://issues.apache.org/jira/browse/MYFACES-3605 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.9-SNAPSHOT Reporter: Thomas Andraschko Assignee: Leonardo Uribe Priority: Critical Fix For: 2.0.15, 2.1.9 After upgrading from 2.1.8 to 2.1.9 follwing exceptions occurs: Caused by: java.lang.ClassCastException: org.apache.myfaces.view.facelets.el.ContextAwareTagMethodExpression cannot be cast to org.apache.myfaces.view.facelets.el.LocationMethodExpression at org.apache.myfaces.view.facelets.tag.TagAttributeImpl.getMethodExpression(TagAttributeImpl.java:222) at org.apache.myfaces.view.facelets.tag.jsf.core.EventHandler.apply(EventHandler.java:125) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:294) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:294) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at org.apache.myfaces.view.facelets.tag.composite.ImplementationHandler.apply(ImplementationHandler.java:67) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at org.apache.myfaces.view.facelets.tag.composite.CompositeComponentDefinitionTagHandler.apply(CompositeComponentDefinitionTagHandler.java:255) at org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:57) at org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:48) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.applyCompositeComponent(DefaultFacelet.java:482) at org.apache.myfaces.view.facelets.impl.DefaultFaceletContext.applyCompositeComponent(DefaultFaceletContext.java:779) at org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler.applyCompositeComponentFacelet(CompositeComponentResourceTagHandler.java:378) at org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler.applyNextHandler(CompositeComponentResourceTagHandler.java:158) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:294) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at org.apache.myfaces.view.facelets.tag.ui.DefineHandler.applyDefinition(DefineHandler.java:86) at org.apache.myfaces.view.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:175) at org.apache.myfaces.view.facelets.impl.TemplateContextImpl$TemplateManagerImpl.apply(TemplateContextImpl.java:186) at org.apache.myfaces.view.facelets.impl.TemplateContextImpl.includeDefinition(TemplateContextImpl.java:131) at org.apache.myfaces.view.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:460) at org.apache.myfaces.view.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:94) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:294) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at org.apache.myfaces.view.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:156) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:57) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49) at
[jira] [Commented] (MYFACES-3655) add pluggable Serialization strategies
[ https://issues.apache.org/jira/browse/MYFACES-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501123#comment-13501123 ] Thomas Andraschko commented on MYFACES-3655: +1, kryo is really fast! I also asked this some monts/years before on the mailing list: http://mail-archives.apache.org/mod_mbox/myfaces-users/201201.mbox/%3ccamg-+prax3jvuas2pck3xr8zzt_xqvedcjwyxkbfgqrrv-8...@mail.gmail.com%3E off topic: it's not my project, i'm just a user who did a lot testing etc. and i use in our environment :) add pluggable Serialization strategies -- Key: MYFACES-3655 URL: https://issues.apache.org/jira/browse/MYFACES-3655 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.0 Reporter: Mark Struberg Assignee: Mark Struberg We might check if we can get an even better performance by using a different serialisation strategy. This might heavily improve the performance of ClientSideStateSaving and ViewMap serialisation(if enabled). There are a few alternative libraries like XStream and Kryo available: * http://xstream.codehaus.org * http://code.google.com/p/kryo/ Thomas from the OWB team did a nice benchmark for his clustering project: http://code.google.com/p/memcached-session-manager/wiki/SerializationStrategyBenchmark Definitely worth taking a look imo. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3656) ViewScoped bean fails when SERIALIZE_STATE_IN_SESSION is set to true
[
https://issues.apache.org/jira/browse/MYFACES-3656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13503939#comment-13503939
]
Thomas Andraschko commented on MYFACES-3656:
does your bean implement serializable?
ViewScoped bean fails when SERIALIZE_STATE_IN_SESSION is set to true
Key: MYFACES-3656
URL: https://issues.apache.org/jira/browse/MYFACES-3656
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.15
Environment: WebSphere V8 and Tomcat 2.0.27
Reporter: Paul Nicolucci
Attachments: ViewScopeProblemMyFaces.war
Original Estimate: 24h
Remaining Estimate: 24h
My beans are defined as follows:
managed-bean
managed-bean-nameappManagerBean/managed-bean-name
managed-bean-classcom.ibm.ws.jsf.beans.AppManagerBean/managed-bean-class
managed-bean-scopeapplication/managed-bean-scope
/managed-bean
managed-bean
managed-bean-nameemailBean/managed-bean-name
managed-bean-classcom.ibm.ws.jsf.beans.EmailBean/managed-bean-class
managed-bean-scopesession/managed-bean-scope
/managed-bean
managed-bean
managed-bean-nameviewScopedBean/managed-bean-name
managed-bean-classcom.ibm.ws.jsf.beans.ViewScopedManagedBean/managed-bean-class
managed-bean-scopeview/managed-bean-scope
managed-property
property-nameemailBean/property-name
value#{emailBean}/value
/managed-property
managed-property
property-nameappManagerBean/property-name
value#{appManagerBean}/value
/managed-property
/managed-bean
I've provided an application that reproduces this issue. To reproduce follow
these steps:
1) install application
2) drive a request into the following URL
host:port/context-root/ViewScopeTest1.jsf
3) leave the email field empty
4) press the submit button.
5) you should be taken to the error page
6) the following text should appear in the textArea but it does not Invalid
Email: Email can Not be empty
The second test ViewScopeTest2.jsf is similar it does not contain the
binding attribute and just references a value from the ViewScoped bean and
the problem can again be reproduced.
It seems as though the AppManager errorMessage field is null but it has not
been reset. I would think that the application scoped bean would still be
accessible even though the view scoped bean is out of scope.
If you set the SERIALIZE_STATE_IN_SESSION to false and redeploy the
application then everything works as expected, which seems odd to me but if
you un-comment this from the web.xml you'll see we get the text on the error
page as expected.
I've been working to debug this issue and can't seem to figure out where the
problem is in the MyFaces code. I tested the same application on WAS and
Tomcat to ensure that it was not something specific to a server. It seems as
though this is a implementation issue.
Any help that folks can provide would be greatly appreciated!!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3709) metadata - component with duplicate id
Thomas Andraschko created MYFACES-3709: -- Summary: metadata - component with duplicate id Key: MYFACES-3709 URL: https://issues.apache.org/jira/browse/MYFACES-3709 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.11 Reporter: Thomas Andraschko Attachments: my-webapp.7z Just run the attached project. Following exception occurs: java.lang.IllegalStateException: component with duplicate id j_id__md_1 found at org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:100) at org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:116) at org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:110) at org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:82) at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.saveView(DefaultFaceletsStateManagementStrategy.java:558) at org.apache.myfaces.application.StateManagerImpl.saveView(StateManagerImpl.java:188) at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:2052) at org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285) at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199) This works fine if i remove the f:viewParam. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3728) javax.faces.partial.execute=@none still process
Thomas Andraschko created MYFACES-3728: -- Summary: javax.faces.partial.execute=@none still process Key: MYFACES-3728 URL: https://issues.apache.org/jira/browse/MYFACES-3728 Project: MyFaces Core Issue Type: Bug Reporter: Thomas Andraschko -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3728) javax.faces.partial.execute=@none still process javax.faces.source component
[ https://issues.apache.org/jira/browse/MYFACES-3728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13703058#comment-13703058 ] Thomas Andraschko commented on MYFACES-3728: Any plans to fix this? Otherwise i must temporally do a workaround in PrimeFaces. AFAICS the @none handling was removed in PartialViewContext + Impl. javax.faces.partial.execute=@none still process javax.faces.source component Key: MYFACES-3728 URL: https://issues.apache.org/jira/browse/MYFACES-3728 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.10 Reporter: Thomas Andraschko i found a weird issue that if i use p:ajax on inputText with process=@none, the InputTextRenderer#decode method will be still invoked. This works fine with f:ajax in myfaces and mojarra. p:ajax only works expected on mojarra. The only difference i found is, that p:ajax sends the javax.faces.partial.execute param and f:ajax not. Here is a list with the post params (without my inputs): PrimeFaces: javax.faces.ViewState=N%2F6uUZMB9%2BPXSBTJVus5p6rncWDWwUAgQ9UIOweKuerVM0Z7 javax.faces.partial.ajax=true javax.faces.source=xxx javax.faces.partial.execute=%40none javax.faces.partial.render=%40none javax.faces.behavior.event=change javax.faces.partial.event=change form_SUBMIT=1 MyFaces: javax.faces.ViewState=EHCQlskNw%2BLXSBTJVus5pyzjdxWpT%2B72t7rvnK11Nffi10%2Bl javax.faces.partial.ajax=true javax.faces.source=xxx javax.faces.behavior.event=change javax.faces.partial.event=change javax.faces.windowId=2cc form_SUBMIT=1 form=form -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3728) javax.faces.partial.execute=@none still process javax.faces.source component
[ https://issues.apache.org/jira/browse/MYFACES-3728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13703448#comment-13703448 ] Thomas Andraschko commented on MYFACES-3728: Thanks Leo for checking the specs! I will change the primefaces impl to be compatible with the specs but allow @none in myfaces would be a good enhancement too. javax.faces.partial.execute=@none still process javax.faces.source component Key: MYFACES-3728 URL: https://issues.apache.org/jira/browse/MYFACES-3728 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.10 Reporter: Thomas Andraschko i found a weird issue that if i use p:ajax on inputText with process=@none, the InputTextRenderer#decode method will be still invoked. This works fine with f:ajax in myfaces and mojarra. p:ajax only works expected on mojarra. The only difference i found is, that p:ajax sends the javax.faces.partial.execute param and f:ajax not. Here is a list with the post params (without my inputs): PrimeFaces: javax.faces.ViewState=N%2F6uUZMB9%2BPXSBTJVus5p6rncWDWwUAgQ9UIOweKuerVM0Z7 javax.faces.partial.ajax=true javax.faces.source=xxx javax.faces.partial.execute=%40none javax.faces.partial.render=%40none javax.faces.behavior.event=change javax.faces.partial.event=change form_SUBMIT=1 MyFaces: javax.faces.ViewState=EHCQlskNw%2BLXSBTJVus5pyzjdxWpT%2B72t7rvnK11Nffi10%2Bl javax.faces.partial.ajax=true javax.faces.source=xxx javax.faces.behavior.event=change javax.faces.partial.event=change javax.faces.windowId=2cc form_SUBMIT=1 form=form -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3728) javax.faces.partial.execute=@none still process javax.faces.source component
[ https://issues.apache.org/jira/browse/MYFACES-3728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13706888#comment-13706888 ] Thomas Andraschko commented on MYFACES-3728: You are right Werner. I fixed this in PrimeFaces but allow @none as parameter on server side (like Mojarra) would be a great enhancement. Thanks. javax.faces.partial.execute=@none still process javax.faces.source component Key: MYFACES-3728 URL: https://issues.apache.org/jira/browse/MYFACES-3728 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.10 Reporter: Thomas Andraschko i found a weird issue that if i use p:ajax on inputText with process=@none, the InputTextRenderer#decode method will be still invoked. This works fine with f:ajax in myfaces and mojarra. p:ajax only works expected on mojarra. The only difference i found is, that p:ajax sends the javax.faces.partial.execute param and f:ajax not. Here is a list with the post params (without my inputs): PrimeFaces: javax.faces.ViewState=N%2F6uUZMB9%2BPXSBTJVus5p6rncWDWwUAgQ9UIOweKuerVM0Z7 javax.faces.partial.ajax=true javax.faces.source=xxx javax.faces.partial.execute=%40none javax.faces.partial.render=%40none javax.faces.behavior.event=change javax.faces.partial.event=change form_SUBMIT=1 MyFaces: javax.faces.ViewState=EHCQlskNw%2BLXSBTJVus5pyzjdxWpT%2B72t7rvnK11Nffi10%2Bl javax.faces.partial.ajax=true javax.faces.source=xxx javax.faces.behavior.event=change javax.faces.partial.event=change javax.faces.windowId=2cc form_SUBMIT=1 form=form -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3772) SessionScoped beans are not synchronizing between tomcat 6 cluster
[ https://issues.apache.org/jira/browse/MYFACES-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13767632#comment-13767632 ] Thomas Andraschko commented on MYFACES-3772: Leo, are you sure that MyFaces handles this 100% correctly? I had the same problem before switching to OpenWebBeans some years ago. Do we always call session#putAttribute(mySessionBean) after each request? Otherwise, the change of a property won't be replicated. SessionScoped beans are not synchronizing between tomcat 6 cluster -- Key: MYFACES-3772 URL: https://issues.apache.org/jira/browse/MYFACES-3772 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.12 Environment: Tomcat6 + JDK7 + Win7 + Apache httpd load balancer (without sticky session) Reporter: Prasenjit Purohit Assignee: Leonardo Uribe I am using myfaces in our project. We use some session scoped beans. Let me explain the error reproduction steps with two Tomcat6 nodes and Apache httpd load balancer (without sticky session). web.xml has distributable/ element. Other session variables are synchronizing well. 1. Start node 1 2. Set some value in the property of a session bean 3. Value is available for get on node 1 4. Start node 2 same value is available on node 2 5. Set new value on the property of node 1 6. New value is available on node 1 7. Node 2 still contains the old value 8. Restart node 2 9. Node 2 now contains new value 10. Set new value on node 2 11. New value available on node 2 but not on node 1 12. Restart node 2 13. Node 2 has the old value taken from Node 1 No exception is raised during the process. Session bean implements Serializable interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3775) [perf] optional early flush
[ https://issues.apache.org/jira/browse/MYFACES-3775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770645#comment-13770645 ] Thomas Andraschko commented on MYFACES-3775: cool feature gerhard :) [perf] optional early flush --- Key: MYFACES-3775 URL: https://issues.apache.org/jira/browse/MYFACES-3775 Project: MyFaces Core Issue Type: Improvement Components: JSR-344 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 2.2.0 in project-stage production it should be possible to enable an early flush via context-param (performed at the end of HtmlHeadRenderer#encodeEnd) (see http://developer.yahoo.com/performance/rules.html#flush) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3772) SessionScoped beans are not synchronizing between tomcat 6 cluster
[ https://issues.apache.org/jira/browse/MYFACES-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770651#comment-13770651 ] Thomas Andraschko commented on MYFACES-3772: I think we should do it the same as we did in OWB. Creating a bag/container with all sessionScoped beans and always store this container in the session after each request. (this should be the same for viewscoped beans, too) In this container we should also store a server identifier / jvm_id (in OWB it's just a static UID). So we can restore the beans from the container if the jvm_id is another as from the last request. [~prasenjitpurohit] As workaround, you can use ObenWebBeans and CDI instead of JSF Beans or using another failover manager for tomcat - http://code.google.com/p/memcached-session-manager/ SessionScoped beans are not synchronizing between tomcat 6 cluster -- Key: MYFACES-3772 URL: https://issues.apache.org/jira/browse/MYFACES-3772 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.12 Environment: Tomcat6 + JDK7 + Win7 + Apache httpd load balancer (without sticky session) Reporter: Prasenjit Purohit Assignee: Leonardo Uribe I am using myfaces in our project. We use some session scoped beans. Let me explain the error reproduction steps with two Tomcat6 nodes and Apache httpd load balancer (without sticky session). web.xml has distributable/ element. Other session variables are synchronizing well. 1. Start node 1 2. Set some value in the property of a session bean 3. Value is available for get on node 1 4. Start node 2 same value is available on node 2 5. Set new value on the property of node 1 6. New value is available on node 1 7. Node 2 still contains the old value 8. Restart node 2 9. Node 2 now contains new value 10. Set new value on node 2 11. New value available on node 2 but not on node 1 12. Restart node 2 13. Node 2 has the old value taken from Node 1 No exception is raised during the process. Session bean implements Serializable interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3772) SessionScoped beans are not synchronizing between tomcat 6 cluster
[ https://issues.apache.org/jira/browse/MYFACES-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770659#comment-13770659 ] Thomas Andraschko commented on MYFACES-3772: - http://tandraschko.blogspot.de/2012/08/test.html SessionScoped beans are not synchronizing between tomcat 6 cluster -- Key: MYFACES-3772 URL: https://issues.apache.org/jira/browse/MYFACES-3772 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.12 Environment: Tomcat6 + JDK7 + Win7 + Apache httpd load balancer (without sticky session) Reporter: Prasenjit Purohit Assignee: Leonardo Uribe I am using myfaces in our project. We use some session scoped beans. Let me explain the error reproduction steps with two Tomcat6 nodes and Apache httpd load balancer (without sticky session). web.xml has distributable/ element. Other session variables are synchronizing well. 1. Start node 1 2. Set some value in the property of a session bean 3. Value is available for get on node 1 4. Start node 2 same value is available on node 2 5. Set new value on the property of node 1 6. New value is available on node 1 7. Node 2 still contains the old value 8. Restart node 2 9. Node 2 now contains new value 10. Set new value on node 2 11. New value available on node 2 but not on node 1 12. Restart node 2 13. Node 2 has the old value taken from Node 1 No exception is raised during the process. Session bean implements Serializable interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3779) Mixed mode(Server+client) for state saving
[ https://issues.apache.org/jira/browse/MYFACES-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774331#comment-13774331 ] Thomas Andraschko commented on MYFACES-3779: Don't know if this is really usefull - The state is so small if you don't blow it up with your ViewScopd beans. IMO The only usecass when a mixed mode is really usefull i described here: http://tandraschko.blogspot.de/2012/12/dynamical-switching-of-jsf-state-saving.html Mixed mode(Server+client) for state saving -- Key: MYFACES-3779 URL: https://issues.apache.org/jira/browse/MYFACES-3779 Project: MyFaces Core Issue Type: New Feature Reporter: Ertio Lew How about having a mixed mode for state saving whereby state is initially kept on server for a configurable amount of time (so that fast frequent requests are served without transferring the state from client to server several times, the drawback with client side saving) after that period of time if the page is still alive in browser but it is idle, a javascript request is triggered which asks the server for that state data now it will be kept on client side, now the client the server both know that state for this session is there on client. If the page has died no request has been sent to server asking for state data till that period of time, then state data would be removed from server. A further enhancement could be that you could set a fixed amount out of all memory on server that you want to allocate for state saving of all sessions. Till the time that quota remains, state is kept on server using that quota. But when that quota is over all the state information for further sessions is kept using client side state saving. Also a mixed mode. Such mixed modes would be very helpful in improving performance, better utilization of the server resources. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3779) Mixed mode(Server+client) for state saving
[ https://issues.apache.org/jira/browse/MYFACES-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774403#comment-13774403 ] Thomas Andraschko commented on MYFACES-3779: It is clear that the hack proposed aims to solve some situations where a ViewExpiredException should not be thrown. I didn't know that ViewScoped beans will be always serialized to the session now. What happens in the future if i would use client side state and the ViewScoped beans are not available anymore? Also a ViewExpiredException? Mixed mode(Server+client) for state saving -- Key: MYFACES-3779 URL: https://issues.apache.org/jira/browse/MYFACES-3779 Project: MyFaces Core Issue Type: New Feature Reporter: Ertio Lew How about having a mixed mode for state saving whereby state is initially kept on server for a configurable amount of time (so that fast frequent requests are served without transferring the state from client to server several times, the drawback with client side saving) after that period of time if the page is still alive in browser but it is idle, a javascript request is triggered which asks the server for that state data now it will be kept on client side, now the client the server both know that state for this session is there on client. If the page has died no request has been sent to server asking for state data till that period of time, then state data would be removed from server. A further enhancement could be that you could set a fixed amount out of all memory on server that you want to allocate for state saving of all sessions. Till the time that quota remains, state is kept on server using that quota. But when that quota is over all the state information for further sessions is kept using client side state saving. Also a mixed mode. Such mixed modes would be very helpful in improving performance, better utilization of the server resources. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3779) Mixed mode(Server+client) for state saving
[ https://issues.apache.org/jira/browse/MYFACES-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13776248#comment-13776248 ] Thomas Andraschko commented on MYFACES-3779: Can i ask you how much users and memory do you have on one machine? AFAIR we had only ~2-10kb view state (from small to big and of course without viewscoped beans) for a view. With 1000 users, limited views to 20 for each user and a state of 10kb (10kb is really big for a average state size) - the complete state would only take 200mb for all users. Mixed mode(Server+client) for state saving -- Key: MYFACES-3779 URL: https://issues.apache.org/jira/browse/MYFACES-3779 Project: MyFaces Core Issue Type: New Feature Reporter: Ertio Lew How about having a mixed mode for state saving whereby state is initially kept on server for a configurable amount of time (so that fast frequent requests are served without transferring the state from client to server several times, the drawback with client side saving) after that period of time if the page is still alive in browser but it is idle, a javascript request is triggered which asks the server for that state data now it will be kept on client side, now the client the server both know that state for this session is there on client. If the page has died no request has been sent to server asking for state data till that period of time, then state data would be removed from server. A further enhancement could be that you could set a fixed amount out of all memory on server that you want to allocate for state saving of all sessions. Till the time that quota remains, state is kept on server using that quota. But when that quota is over all the state information for further sessions is kept using client side state saving. Also a mixed mode. Such mixed modes would be very helpful in improving performance, better utilization of the server resources. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3728) javax.faces.partial.execute=@none still process javax.faces.source component
[ https://issues.apache.org/jira/browse/MYFACES-3728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798852#comment-13798852 ] Thomas Andraschko commented on MYFACES-3728: but why should @none actually process @this? I think this should really be discussed in the EG, how process @none should actually work. javax.faces.partial.execute=@none still process javax.faces.source component Key: MYFACES-3728 URL: https://issues.apache.org/jira/browse/MYFACES-3728 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.10 Reporter: Thomas Andraschko Fix For: 2.1.13 i found a weird issue that if i use p:ajax on inputText with process=@none, the InputTextRenderer#decode method will be still invoked. This works fine with f:ajax in myfaces and mojarra. p:ajax only works expected on mojarra. The only difference i found is, that p:ajax sends the javax.faces.partial.execute param and f:ajax not. Here is a list with the post params (without my inputs): PrimeFaces: javax.faces.ViewState=N%2F6uUZMB9%2BPXSBTJVus5p6rncWDWwUAgQ9UIOweKuerVM0Z7 javax.faces.partial.ajax=true javax.faces.source=xxx javax.faces.partial.execute=%40none javax.faces.partial.render=%40none javax.faces.behavior.event=change javax.faces.partial.event=change form_SUBMIT=1 MyFaces: javax.faces.ViewState=EHCQlskNw%2BLXSBTJVus5pyzjdxWpT%2B72t7rvnK11Nffi10%2Bl javax.faces.partial.ajax=true javax.faces.source=xxx javax.faces.behavior.event=change javax.faces.partial.event=change javax.faces.windowId=2cc form_SUBMIT=1 form=form -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3664) JSF View Pooling (going beyond JSF Stateless Mode)
[ https://issues.apache.org/jira/browse/MYFACES-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13842260#comment-13842260 ] Thomas Andraschko commented on MYFACES-3664: thanks for your effort Leo. Will you also do another performance/memory/troughput comparison after 2.2 release? Would be great! JSF View Pooling (going beyond JSF Stateless Mode) -- Key: MYFACES-3664 URL: https://issues.apache.org/jira/browse/MYFACES-3664 Project: MyFaces Core Issue Type: New Feature Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Attachments: myfacesStatelessMode-12-view-pool.patch, myfacesStatelessMode-6-view-pool.patch, myfacesStatelessMode-8-view-pool.patch In the last months, I have been doing some investigations around stateless JSF ideas. The intention is try to find ways to improve MyFaces Core performance as much as possible, without lose all those nice features we all are used to. In summary, the justification around stateless JSF is that, if it is possible to cut the build view time from a request, there will be an improvement from both speed and memory perspective. This is true, but only to some point, because the response time for a request is given by the build view, validation/invoke application and render response time. To get to the same goal, without sacrifice JSF stateful behavior, other improvements has been already done (cache EL expressions, cache ids, make tree structure lighter, ...). The idea is cache that stateless information into a place where it can be reused effectively, which in this case is inside Facelet abstract syntax tree (AST). This has worked well so far. The side effects of enable these optimizations has been analysed, and there is a good understanding about this. In few words, the basic idea about stateless JSF as proposed originally by Rudi Simic in his blog is this: Mark the view as stateless using some attribute. Use a pool of views, because views are not thread safe. Before store the view in the pool, use a visitTree call to reset the fields. Unfortunately, it was quickly found that the implementation proposed requires a better view pool and try to reset the fields is not fail-safe, because the component tree also stores more than just the input field values. Additionally, it doesn't provide a way to use it for dynamic views. Provide a thread safe implementation of UIComponent that can be reused across threads is not a good solution, because anyway there is some information that is inside UIComponent and should be stored per thread, and precisely UIComponent is a place specifically designed to store that information. Based on the previous background, the big question is if a solution based on object pooling pattern can be done effectively for a web framework like JSF. A good description of the technique and its trade-off can be found at: http://en.wikipedia.org/wiki/Object_pool_pattern In few words, the proposal is go Beyond JSF Stateless Mode, and instead blame the state, make it your friend. Let's just take advantage of the stateful nature of JSF to allow reuse views fully or partially. How? - PSS algorithm can be used to check if a view has been modified or not, checking its state. So, it can be used to check which components has state, and if it is possible to provide a way to reset the state of a component to the initial state set by the first markInitialState(), restore the state is possible. -If the view cannot be reset fully, it is possible to use facelets refreshing algorithm and reuse a view partially. - Add some additional code to recover a view instance when it is discarded, and store it into the view pool. This requires some changes over NavigationHandlerImpl, because it is not possible to reuse a view and store it in the pool that is still on usage, so it is necessary to do a deferred navigation, changing the default ActionListenerImpl and ensure handleNavigation() is called before end invoke application phase but outside the visitTree() call. - In MyFaces there exists the concept of FaceletState. It is possible to use this concept and cache even dynamic views, because each different FaceletState can identify an specific view structure. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MYFACES-3832) disableClientWindow is not fully implemented
Thomas Andraschko created MYFACES-3832: -- Summary: disableClientWindow is not fully implemented Key: MYFACES-3832 URL: https://issues.apache.org/jira/browse/MYFACES-3832 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.0-beta Reporter: Thomas Andraschko The OutcomeTargetUtils must consider the attribute when rendering the URL -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (MYFACES-3465) Provide stateless extension
[ https://issues.apache.org/jira/browse/MYFACES-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-3465. Resolution: Duplicate JSF 2.2 provides stateless views and MyFaces 2.2 AFAIK provide poolable views Provide stateless extension --- Key: MYFACES-3465 URL: https://issues.apache.org/jira/browse/MYFACES-3465 Project: MyFaces Core Issue Type: New Feature Reporter: Thomas Andraschko As discussed with Leonardo, i create an issue with the stateless jsf extension. The code: http://www.mediafire.com/?3wr72zlch7ly1wc (also prepared with myfaces namespace and checkstyle) This extension is based on: http://industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead/ (Thanks to Rudi!) I completely refactored the code and made it compatible with mojarra and myfaces (with extra modules). -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (MYFACES-3881) CLIENT_WINDOW_MODE generates new windowid even if one exists
[ https://issues.apache.org/jira/browse/MYFACES-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13968241#comment-13968241 ] Thomas Andraschko commented on MYFACES-3881: What about using DeltaSpikes LAZY mode? CLIENT_WINDOW_MODE generates new windowid even if one exists Key: MYFACES-3881 URL: https://issues.apache.org/jira/browse/MYFACES-3881 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.2 Environment: java 7, tomcat 7.0.50 Reporter: Rene O Attachments: jsftest22.zip, jsftest22_new.zip If you use @ViewScoped beans and activate CLIENT_WINDOW_MODE (url or client) a page refresh generates a new windowid although the application in the current browser window already has a windowid. I think a new windowid should only be generated, if no windowid exists, e.g. open new window or tab with the same url. context-param param-namejavax.faces.CLIENT_WINDOW_MODE/param-name param-valueurl/param-value !--client doesn't work too-- /context-param A testcase is attached. call url: http://localhost:8080/jsftest22/mypage.jsf Fill some values into field Press F5 to refresh the page = new windowid is generated = inputdata is lost, because a new @ViewScoped bean was created -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MYFACES-3886) SerializedViewCollection does not update it's _keys list when _serializedViews contains key
[ https://issues.apache.org/jira/browse/MYFACES-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13978284#comment-13978284 ] Thomas Andraschko commented on MYFACES-3886: We just open a new dialog each time with a iframe and the URL to the view to open. If you open a new one, likely a new windowId will be assigned. Thats by design as it's a new dialog with a new view. Don't know how we could overcome this limitation and if reusing the windowId for all dialogs is a good way or even a correct solution. SerializedViewCollection does not update it's _keys list when _serializedViews contains key --- Key: MYFACES-3886 URL: https://issues.apache.org/jira/browse/MYFACES-3886 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.2.2 Environment: PrimeFaces 4.0.12. Reporter: Adam Balazs When I use DialogFramework (of PrimeFaces), it's adds a new view to the session every time. The problem is that when I post an AJAX request to the original view, the _keys list is not updated, only the view get updated in the _serializedViews map. After I reach the limit defined with the org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION context-param, MyFaces gets the first element in the _keys list (which is the container view) - assuming that this is the oldest view in the session - and remove the corresponding view from the _serializedViews map by the key. But clearly it is not, as I already posted some AJAX requests to it. I think the optimal behavior would be the following: when a view gets an ajax request the code should remove the the key from the _keys list and than add it as a last element. The related class is org.apache.myfaces.application.viewstate.SerializedViewCollection at the if condition started at line 87. My question is if it is an intended behavior or if it's a bug. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (MYFACES-3886) SerializedViewCollection does not update it's _keys list when _serializedViews contains key
[ https://issues.apache.org/jira/browse/MYFACES-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13978284#comment-13978284 ] Thomas Andraschko edited comment on MYFACES-3886 at 4/23/14 3:10 PM: - From PrimeFaces perspective: We just open a new dialog each time with a iframe and the URL to the view to open. If you open a new one, likely a new windowId will be assigned. Thats by design as it's a new dialog with a new view. Don't know how we could overcome this limitation and if reusing the windowId for all dialogs is a good way or even a correct solution. was (Author: tandraschko): We just open a new dialog each time with a iframe and the URL to the view to open. If you open a new one, likely a new windowId will be assigned. Thats by design as it's a new dialog with a new view. Don't know how we could overcome this limitation and if reusing the windowId for all dialogs is a good way or even a correct solution. SerializedViewCollection does not update it's _keys list when _serializedViews contains key --- Key: MYFACES-3886 URL: https://issues.apache.org/jira/browse/MYFACES-3886 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.2.2 Environment: PrimeFaces 4.0.12. Reporter: Adam Balazs When I use DialogFramework (of PrimeFaces), it's adds a new view to the session every time. The problem is that when I post an AJAX request to the original view, the _keys list is not updated, only the view get updated in the _serializedViews map. After I reach the limit defined with the org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION context-param, MyFaces gets the first element in the _keys list (which is the container view) - assuming that this is the oldest view in the session - and remove the corresponding view from the _serializedViews map by the key. But clearly it is not, as I already posted some AJAX requests to it. I think the optimal behavior would be the following: when a view gets an ajax request the code should remove the the key from the _keys list and than add it as a last element. The related class is org.apache.myfaces.application.viewstate.SerializedViewCollection at the if condition started at line 87. My question is if it is an intended behavior or if it's a bug. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MYFACES-3894) Make the duplicate client id check optional in development mode
[ https://issues.apache.org/jira/browse/MYFACES-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14002333#comment-14002333 ] Thomas Andraschko commented on MYFACES-3894: Could you please create a issue on PrimeFaces side? I'm a PrimeFaces developer and MyFaces User and i'm not aware of such a problem. Maybe if you use the old 3.5 MenuModel stuff but this is outdated. Make the duplicate client id check optional in development mode --- Key: MYFACES-3894 URL: https://issues.apache.org/jira/browse/MYFACES-3894 Project: MyFaces Core Issue Type: Wish Reporter: Adam Balazs Priority: Minor Hi, I just wanted to start using JRebel with JSF, and found out that there are some issues with the JRebel - MyFaces - PrimeFaces combo. It seems that some of the PF components generates invalid component trees, which cause the MyFaces throwing DuplicateIdException in development mode. The strange thing is that we are using these components in production for more than 2 years now, and never noticed any issues with them, so I guess, the guys at PF worked this around very well. I've already reported this to them with my company's PRO account. As I browsed the code of PF I realized that fixing this behavior is not so easy and can take more time, so I just wonder if - as a quick fix - you can make the duplicate id check algorithm optional in development mode too. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (MYFACES-3913) NPE in SwitchAjaxExceptionHandlerWrapperImpl
Thomas Andraschko created MYFACES-3913: -- Summary: NPE in SwitchAjaxExceptionHandlerWrapperImpl Key: MYFACES-3913 URL: https://issues.apache.org/jira/browse/MYFACES-3913 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.15 Reporter: Thomas Andraschko _isAjaxRequest = facesContext.getPartialViewContext().isAjaxRequest(); occurs 2 times in SwitchAjaxExceptionHandlerWrapperImpl and facesContext.getPartialViewContext() can be null. We should just return false if it's null. StackTrace: java.lang.NullPointerException at org.apache.myfaces.shared.context.SwitchAjaxExceptionHandlerWrapperImpl.isAjaxRequest(SwitchAjaxExceptionHandlerWrapperImpl.java:98) at org.apache.myfaces.shared.context.SwitchAjaxExceptionHandlerWrapperImpl.getWrapped(SwitchAjaxExceptionHandlerWrapperImpl.java:106) at javax.faces.context.ExceptionHandlerWrapper.isListenerForSource(ExceptionHandlerWrapper.java:70) at javax.faces.context.ExceptionHandlerWrapper.isListenerForSource(ExceptionHandlerWrapper.java:70) at javax.faces.context.ExceptionHandlerWrapper.isListenerForSource(ExceptionHandlerWrapper.java:70) at org.apache.myfaces.application.ApplicationImpl._traverseListenerList(ApplicationImpl.java:2480) at org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:586) at org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:616) at javax.faces.application.ApplicationWrapper.publishEvent(ApplicationWrapper.java:336) at javax.faces.application.ApplicationWrapper.publishEvent(ApplicationWrapper.java:336) at javax.faces.application.ApplicationWrapper.publishEvent(ApplicationWrapper.java:336) at org.apache.deltaspike.jsf.impl.injection.InjectionAwareApplicationWrapper.publishEvent(InjectionAwareApplicationWrapper.java:121) at org.apache.myfaces.lifecycle.PhaseListenerManager.publishException(PhaseListenerManager.java:136) at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager.java:123) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:185) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) at org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.execute(DeltaSpikeLifecycleWrapper.java:89) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:197) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (MYFACES-4005) Update commons-codec to 1.10
Thomas Andraschko created MYFACES-4005: -- Summary: Update commons-codec to 1.10 Key: MYFACES-4005 URL: https://issues.apache.org/jira/browse/MYFACES-4005 Project: MyFaces Core Issue Type: Task Reporter: Thomas Andraschko To avoid problems like: http://stackoverflow.com/questions/7688644/java-lang-nosuchmethoderror-org-apache-commons-codec-binary-base64-encodebase64 Source: /core/trunk/parent/pom.xml Line 497 I could also provide an patch but should be the same effort to commit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4008) AbstractMethodError thrown by javax.servlet.http.Part.getSubmittedFileName()
[
https://issues.apache.org/jira/browse/MYFACES-4008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14653658#comment-14653658
]
Thomas Andraschko commented on MYFACES-4008:
MyFaces is still built on Servlet API 3.0 and not 3.1.
I would like to fix the problem but there currently is no
geronimo-servlet_3.1_spec available.
Can we use this instead:
dependency
groupIdjavax.servlet/groupId
artifactIdjavax.servlet-api/artifactId
version3.1.0/version
/dependency
?
AbstractMethodError thrown by javax.servlet.http.Part.getSubmittedFileName()
Key: MYFACES-4008
URL: https://issues.apache.org/jira/browse/MYFACES-4008
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.2.6, 2.2.8
Environment: apache-tomcat-8.0.24
myfaces-core-2.2.8-bin
Eclipse Version: Luna Release (4.4.0)
jdk1.8.0_51
Windows 7 Professional (64 bit, 32 GB ram, Intel i7-4900MQ 2.80 Ghz)
Reporter: Lance Bader
I can't believe I am the first person in the world to try this combination.
{code}
java.lang.AbstractMethodError:
org.apache.myfaces.shared.renderkit.html.util.HttpPartWrapper.getSubmittedFileName()Ljava/lang/String;
at com.mli.filecollector.BeanWelcome.actionSubmit(BeanWelcome.java:220)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.apache.el.parser.AstValue.invoke(AstValue.java:247)
at
org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:267)
at
org.apache.myfaces.view.facelets.el.ContextAwareTagMethodExpression.invoke(ContextAwareTagMethodExpression.java:96)
at
org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:74)
at javax.faces.component.UICommand.broadcast(UICommand.java:120)
at javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:1172)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:365)
at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1658)
at
javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:862)
at
org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:42)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:196)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:143)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:198)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:617)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1091)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:668)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1527)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1484)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (MYFACES-4017) custom expression factory not correctly loaded
[ https://issues.apache.org/jira/browse/MYFACES-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-4017. Resolution: Fixed > custom expression factory not correctly loaded > -- > > Key: MYFACES-4017 > URL: https://issues.apache.org/jira/browse/MYFACES-4017 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.8 >Reporter: Romain Manni-Bucau >Assignee: Thomas Andraschko > Fix For: 2.2.9 > > > in org.apache.myfaces.webapp.AbstractFacesInitializer#loadExpressionFactory > Class.forName is used which means if you put myfaces in the container then > container loader is used. > Switching to java.lang.Class#forName(java.lang.String, boolean, > java.lang.ClassLoader) or using the tccl.loadClass() solves it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MYFACES-3063) code cleanup and performance review
[ https://issues.apache.org/jira/browse/MYFACES-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-3063. Resolution: Fixed > code cleanup and performance review > > > Key: MYFACES-3063 > URL: https://issues.apache.org/jira/browse/MYFACES-3063 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 2.0.4 >Reporter: Mark Struberg >Assignee: Thomas Andraschko > Fix For: 2.2.9 > > > A sonar scan shows lots of small possible enhancements, like using > Integer#valueOf(i) instead new Integer(i) and stuff. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-2778) jsf.js ajax response xml format exception broken on newer mozilla builds
[ https://issues.apache.org/jira/browse/MYFACES-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14978587#comment-14978587 ] Thomas Andraschko commented on MYFACES-2778: Hi Werner, is this really broken anymore? :) > jsf.js ajax response xml format exception broken on newer mozilla builds > > > Key: MYFACES-2778 > URL: https://issues.apache.org/jira/browse/MYFACES-2778 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.1-SNAPSHOT >Reporter: Werner Punz >Priority: Minor > > The way the xml errors are handled is not standardized every browser rolls > its own handling, mozilla has changed the way it handles the xml parsing > errors slightly, I have to readjust so that it works again. > Also additionally to that I am going to make the development stage > configurable from the config items if no default one is given. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-3170) [perf] use initialCapacity for ArrayList
[ https://issues.apache.org/jira/browse/MYFACES-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14981010#comment-14981010 ] Thomas Andraschko commented on MYFACES-3170: AFAICS it's already used in many places. [~lu4242] WDYT? is this still required in trunk? > [perf] use initialCapacity for ArrayList > > > Key: MYFACES-3170 > URL: https://issues.apache.org/jira/browse/MYFACES-3170 > Project: MyFaces Core > Issue Type: Improvement > Components: General > Environment: myfaces trunk >Reporter: Martin Kočí >Assignee: Martin Kočí >Priority: Minor > > new ArrayList() creates Object [10] and in some situation it is not > necessary. For example, UIInput.addValidator allocates ArrayList of size ten > but in real usage nobody adds 10 validators to one component. > Analyze usage of new ArrayList() and myfaces code and use initialCapacity if > possible. > i -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-3864) myfaces-core-assembly-2.1.14 source debug issue
[ https://issues.apache.org/jira/browse/MYFACES-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976510#comment-14976510 ] Thomas Andraschko commented on MYFACES-3864: Could you try with a newer version? it works fine for me with 2.1.17 > myfaces-core-assembly-2.1.14 source debug issue > --- > > Key: MYFACES-3864 > URL: https://issues.apache.org/jira/browse/MYFACES-3864 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.1.14 >Reporter: Kumar >Priority: Minor > > Hi, > I am trying to debug through the latest myfaces-core-assembly-2.1.14-src, and > finding that some of the breakpoints of some java classes are not reachable. > In particular, I am not able to reach getStateCache method of > HtmlResponseStateManager. I am not very sure if something wrong with my > setup or if there is any issue with myfaces src and bin packages. > To cross check that my setup has no problems, I have tried to debug with > 2.1.8 version, and I have found no issues with that package. > If this is no issue for you, please kindly share if there is any possible > issue with my setup. > Thanks in advance. > Regards, > Kumar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MYFACES-3961) ajax misbehavior for readonly bean property
[
https://issues.apache.org/jira/browse/MYFACES-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved MYFACES-3961.
Resolution: Cannot Reproduce
Assignee: Thomas Andraschko
Works fine in a fresh sample project with MyFaces trunk and Jetty.
> ajax misbehavior for readonly bean property
> ---
>
> Key: MYFACES-3961
> URL: https://issues.apache.org/jira/browse/MYFACES-3961
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.7
>Reporter: xiefei
>Assignee: Thomas Andraschko
>
> This is a simple button that hide itself:
> {code:title=markup.xml}
>
> rendered="#{not hello.buttonHidden}">
>
>
>
> {code}
> This is the backing bean:
> {code:title=Hello.java}
> @ManagedBean
> @ViewScoped
> public class Hello {
> private boolean buttonHidden = false;
> public void hideButton(){
> buttonHidden = true;
> }
> public boolean isButtonHidden() {
> return buttonHidden;
> }
> }
> {code}
> When the button is clicked, it failed to hide itself. If we add setter
> method for buttonHidden property, then the button works as expected.
> Mojarra 2.2.8 does not have this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MYFACES-3957) Disabled h:commandLink results in rendering of a span with onclick
[
https://issues.apache.org/jira/browse/MYFACES-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko updated MYFACES-3957:
---
Status: Patch Available (was: Open)
> Disabled h:commandLink results in rendering of a span with onclick
> ---
>
> Key: MYFACES-3957
> URL: https://issues.apache.org/jira/browse/MYFACES-3957
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.2
> Environment: Websphere 8.5
>Reporter: Stephan Knitelius
>
> {code}
>type="button">link
> AND
>type="button" value="link" />
> {code}
> Result in:
> {code}
> link
> {code}
> I would have expected to find a disabled or a span without the
> onclick action.
> In comparison a disabled h:commandButton:
> {code}
> type="button"/>
> {code}
> Results in:
> {code}
> id="frmContent:j_id499838546_62f34114" onclick="alert('hello')" type="button"
> value="button">
> {code}
> As expected the onclick action is not preformed.
> I would expect similar behaviour from both h:commandButton and h:commandLink.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MYFACES-3959) Outcommented f:metadata will be also executed
[ https://issues.apache.org/jira/browse/MYFACES-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14978635#comment-14978635 ] Thomas Andraschko commented on MYFACES-3959: Also if you set javax.faces.FACELETS_SKIP_COMMENTS true ? > Outcommented f:metadata will be also executed > - > > Key: MYFACES-3959 > URL: https://issues.apache.org/jira/browse/MYFACES-3959 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.7 > Environment: tomcat 7 > windows 7 >Reporter: Artur Sommer >Priority: Minor > > This outcommented code in a jsf page will be executed but is outcommented. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4013) action of h:commandButton rendered in h:dataTable doesn't navigate to action page
[ https://issues.apache.org/jira/browse/MYFACES-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976406#comment-14976406 ] Thomas Andraschko commented on MYFACES-4013: As the button has disabled="true", it's will be rendered as disabled. So the button can't even be clicked on the client side. Removing disabled=true works fine for me. > action of h:commandButton rendered in h:dataTable doesn't navigate to action > page > - > > Key: MYFACES-4013 > URL: https://issues.apache.org/jira/browse/MYFACES-4013 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.8 >Reporter: Santosh P >Assignee: Thomas Andraschko > Attachments: TableFormModel.java, tableForm.xhtml > > > I am using h:commandButton in each row of a h:dataTable. I have used a file > name as action attribute value. On click of which the page should be > navigated to other expected page. But when the button is used in h:dataTable > the page just refreshes existing page itself instead of showing content of > other file. However, the action of button works properly when I use it out of > the table. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MYFACES-4013) action of h:commandButton rendered in h:dataTable doesn't navigate to action page
[ https://issues.apache.org/jira/browse/MYFACES-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-4013. Resolution: Not A Problem > action of h:commandButton rendered in h:dataTable doesn't navigate to action > page > - > > Key: MYFACES-4013 > URL: https://issues.apache.org/jira/browse/MYFACES-4013 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.8 >Reporter: Santosh P >Assignee: Thomas Andraschko > Attachments: TableFormModel.java, tableForm.xhtml > > > I am using h:commandButton in each row of a h:dataTable. I have used a file > name as action attribute value. On click of which the page should be > navigated to other expected page. But when the button is used in h:dataTable > the page just refreshes existing page itself instead of showing content of > other file. However, the action of button works properly when I use it out of > the table. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-1383) FacesContextFactoryImpl issue using trinidad any myfaces core
[ https://issues.apache.org/jira/browse/MYFACES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated MYFACES-1383: --- Status: Open (was: Patch Available) FacesContextFactoryImpl issue using trinidad any myfaces core - Key: MYFACES-1383 URL: https://issues.apache.org/jira/browse/MYFACES-1383 Project: MyFaces Core Issue Type: Bug Components: Portlet_Support Affects Versions: 1.1.5-SNAPSHOT Environment: pluto 1.1-dev, tomcat 5.5.17 running on linux 2.6.17 Reporter: nicolas kalkhof Assignee: Matthias Weßendorf Attachments: bridge.patch trinidad won´t run in a portlet environment. problem is, that FacesContextFactoryImpl does not extend ServletFacesContextImpl. therefore this is an internal myfaces core problem that could hopefully be fixed. stacktrace of the crashing portlet using myfaces and trinidad: javax.portlet.PortletException: org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit at org.apache.myfaces.portlet.MyFacesGenericPortlet.handleExceptionFromLifecycle(MyFacesGenericPortlet.java:253) at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:407) Nested Exception is java.lang.ClassCastException: org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:387) at net.portlets.logon.LogonPortlet.doView(LogonPortlet.java:88) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (MYFACES-1431) missing javascript for subform (since myFacesCore 1.1.4)
[ https://issues.apache.org/jira/browse/MYFACES-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko reopened MYFACES-1431: > missing javascript for subform (since myFacesCore 1.1.4) > > > Key: MYFACES-1431 > URL: https://issues.apache.org/jira/browse/MYFACES-1431 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 1.1.4 > Environment: myFacesCore 1.1.4 > tomahawk 1.1.3 > tomahawk sandbox 1.1.3 Snapshot > tomcat 5.5.17 > jdk 1.5.0.7 >Reporter: Michael Heinen > > This problem does occur after updating to myFacesCore 1.1.4. > I does not occur with myFacesCore 1.1.3!!! > (Therefore I entered this bug for myFacesCore 1.1.4 and not for tomahawk > 1.1.3) > I have two subforms inside a form. Each subform contains command buttons. > I receive JavaScript errors if I click the command buttons: > > Generated HTML for the button with core 1.1.4: > name="docform:singleFormId:_idJsp210" type="submit" value="Accept" > onclick="clear_docform_3AsingleFormId();" style="z-index:1" > class="button_img_60" accesskey="a" /> > JS Error: clear_docform_3AsingleFormId not defined > Generated HTML for the button with core 1.1.3: > name="docform:singleFormId:_idJsp210" type="submit" value="Accept" > onclick="clear_docform();" style="z-index:1" class="button_img_60" > accesskey="a" /> > > JSP source: > > ... > styleClass="button_img_60" style="z-index:1" accesskey="a"/> > ... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-1892) validator element in faces-config should support nested attribute and property definitions
[ https://issues.apache.org/jira/browse/MYFACES-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated MYFACES-1892: --- Status: Open (was: Patch Available) > validator element in faces-config should support nested attribute and > property definitions > -- > > Key: MYFACES-1892 > URL: https://issues.apache.org/jira/browse/MYFACES-1892 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 1.2.3 >Reporter: Simon Kitching > Attachments: 1892api1_attribute.patch, 1892api2_attribute.patch, > 1892impl1_attribute.patch, 1892impl2_attribute.patch, > 1892impl3_attribute.patch, 1892impl4_attribute.patch, MYFACES-1892.patch > > > As shown in this dtd: > http://java.sun.com/dtd/web-facesconfig_1_1.dtd > the validator element in a faces-config.xml file should support nested > attribute and property elements: > >xyValidtor >com.xy.XyValidator > > length > java.lang.Integer > 40 > > > However this appears to never have been implemented in either 1.1.x or 1.2.x > of core; only validator-id and validator-class are supported. Note that the > equivalent feature exists for converters, and does appear to have been > implemented. > See the digester rules registered in the constructor for class > org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl > Reported by Joerg (superjoerch at gmx.de) on the myfaces user list, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-1816) Improve tracing view in DebugUtils
[ https://issues.apache.org/jira/browse/MYFACES-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated MYFACES-1816: --- Status: Open (was: Patch Available) > Improve tracing view in DebugUtils > --- > > Key: MYFACES-1816 > URL: https://issues.apache.org/jira/browse/MYFACES-1816 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 1.1.5 >Reporter: Michael Heinen >Priority: Minor > Attachments: DebugUtils.patch > > > I noticed today strange behavior if I change the loglevel for myfaces. Some > getters of backing beans are called although the rendered attribute of a > parent component is false. It is caused by class DebugUtils.traceView. > I enabled logging via following setting: log4j.logger.org.apache.myfaces=DEBUG > Sample jsp: > > > myController.getValue() is now called if logging is enabled although myflag > is not set in request scope. > This makes debugging difficult if the app behaves different depending on > loglevel settings. Data can be uninitialized if the parent should not be > rendered (or it will be lazy initialized on each request if BackingBean is > request scope and not saved in the request). > Therefore I would prefer to skip all components that should not be rendered > from output. > I'll provide a patch as soon as possible (I 'l try this month) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-3981) Unable to resolve Integer API as Lambda expression in a facelet
[ https://issues.apache.org/jira/browse/MYFACES-3981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936743#comment-14936743 ] Thomas Andraschko commented on MYFACES-3981: The patch looks fine but will it also work correctly with a EL 2.x implementation? > Unable to resolve Integer API as Lambda expression in a facelet > --- > > Key: MYFACES-3981 > URL: https://issues.apache.org/jira/browse/MYFACES-3981 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-344 >Affects Versions: 2.2.7 >Reporter: Anup >Priority: Minor > Attachments: myfaces-3981-2.2.8.patch > > > Following testcases does not print anything in a facelet > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-4015) [perf] provide annotation scanning via CDI extension
[ https://issues.apache.org/jira/browse/MYFACES-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated MYFACES-4015: --- Resolution: Fixed Status: Resolved (was: Patch Available) Applied - Thanks for testing it > [perf] provide annotation scanning via CDI extension > > > Key: MYFACES-4015 > URL: https://issues.apache.org/jira/browse/MYFACES-4015 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 2.2.8 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko > Fix For: 2.2.9 > > Attachments: MYFACES-4015.patch > > > Improves the startup performance a lot if many jars are available in the > classpath. > In my environment its about 700ms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MYFACES-4015) [perf] provide annotation scanning via CDI extension
[ https://issues.apache.org/jira/browse/MYFACES-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936731#comment-14936731 ] Thomas Andraschko edited comment on MYFACES-4015 at 9/30/15 11:32 AM: -- Applied - Thanks for reviewing it was (Author: tandraschko): Applied - Thanks for testing it > [perf] provide annotation scanning via CDI extension > > > Key: MYFACES-4015 > URL: https://issues.apache.org/jira/browse/MYFACES-4015 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 2.2.8 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko > Fix For: 2.2.9 > > Attachments: MYFACES-4015.patch > > > Improves the startup performance a lot if many jars are available in the > classpath. > In my environment its about 700ms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MYFACES-3981) Unable to resolve Integer API as Lambda expression in a facelet
[ https://issues.apache.org/jira/browse/MYFACES-3981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936743#comment-14936743 ] Thomas Andraschko edited comment on MYFACES-3981 at 9/30/15 11:51 AM: -- The patch looks fine but will it also work correctly with a EL 2.x implementation? If the property can't be resolved from the scopedMap, the ImportHandler would be still called but doesn't exist in a EL 2.x environment. Maybe we would need a if(el==3.x) around the ImportHandler stuff. was (Author: tandraschko): The patch looks fine but will it also work correctly with a EL 2.x implementation? > Unable to resolve Integer API as Lambda expression in a facelet > --- > > Key: MYFACES-3981 > URL: https://issues.apache.org/jira/browse/MYFACES-3981 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-344 >Affects Versions: 2.2.7 >Reporter: Anup >Priority: Minor > Attachments: myfaces-3981-2.2.8.patch > > > Following testcases does not print anything in a facelet > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-3957) Disabled h:commandLink results in rendering of a span with onclick
[
https://issues.apache.org/jira/browse/MYFACES-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936745#comment-14936745
]
Thomas Andraschko commented on MYFACES-3957:
Does it still occur in a newer version? 2.0.2 is very old.
> Disabled h:commandLink results in rendering of a span with onclick
> ---
>
> Key: MYFACES-3957
> URL: https://issues.apache.org/jira/browse/MYFACES-3957
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.2
> Environment: Websphere 8.5
>Reporter: Stephan Knitelius
>
> {code}
>type="button">link
> AND
>type="button" value="link" />
> {code}
> Result in:
> {code}
> link
> {code}
> I would have expected to find a disabled or a span without the
> onclick action.
> In comparison a disabled h:commandButton:
> {code}
> type="button"/>
> {code}
> Results in:
> {code}
> id="frmContent:j_id499838546_62f34114" onclick="alert('hello')" type="button"
> value="button">
> {code}
> As expected the onclick action is not preformed.
> I would expect similar behaviour from both h:commandButton and h:commandLink.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MYFACES-4014) Log required startup time
[ https://issues.apache.org/jira/browse/MYFACES-4014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated MYFACES-4014: --- Resolution: Fixed Status: Resolved (was: Patch Available) Applied - Thanks for reviewing it > Log required startup time > - > > Key: MYFACES-4014 > URL: https://issues.apache.org/jira/browse/MYFACES-4014 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Fix For: 2.2.9 > > Attachments: MYFACES-4014.patch > > > similiar to OWB: > MyFaces Core has started, it took [1000] ms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-3622) Merging the jsf2.2 changes of jsf.js into the 2.2 branch
[ https://issues.apache.org/jira/browse/MYFACES-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936795#comment-14936795 ] Thomas Andraschko commented on MYFACES-3622: Thanks for your effort :) Is there still something to merge or can we just close the issue? > Merging the jsf2.2 changes of jsf.js into the 2.2 branch > > > Key: MYFACES-3622 > URL: https://issues.apache.org/jira/browse/MYFACES-3622 > Project: MyFaces Core > Issue Type: New Feature >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Minor > > i have several tested extensions from my apache-extras sideproject which need > to be merged into the 2.2 branch, this is done under this task -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-3670) Immediate evaluation must be read-only
[ https://issues.apache.org/jira/browse/MYFACES-3670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936852#comment-14936852 ] Thomas Andraschko commented on MYFACES-3670: Could you please a complete example + more detailed description? > Immediate evaluation must be read-only > -- > > Key: MYFACES-3670 > URL: https://issues.apache.org/jira/browse/MYFACES-3670 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.1.10 > Environment: gae,el sun implementation 2.4 >Reporter: ulises petrunior > > > > > > > > > when submit, properties are modified -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-3622) Merging the jsf2.2 changes of jsf.js into the 2.2 branch
[ https://issues.apache.org/jira/browse/MYFACES-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936761#comment-14936761 ] Thomas Andraschko commented on MYFACES-3622: [~werpu] Could you please provide a list what needs to be merged and why? > Merging the jsf2.2 changes of jsf.js into the 2.2 branch > > > Key: MYFACES-3622 > URL: https://issues.apache.org/jira/browse/MYFACES-3622 > Project: MyFaces Core > Issue Type: New Feature >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Minor > > i have several tested extensions from my apache-extras sideproject which need > to be merged into the 2.2 branch, this is done under this task -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-3803) Success messages (FacesMessage)
[
https://issues.apache.org/jira/browse/MYFACES-3803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936749#comment-14936749
]
Thomas Andraschko commented on MYFACES-3803:
This would affect a class in the JSF API.
Please create a spec issue.
> Success messages (FacesMessage)
> ---
>
> Key: MYFACES-3803
> URL: https://issues.apache.org/jira/browse/MYFACES-3803
> Project: MyFaces Core
> Issue Type: New Feature
>Reporter: Arn Waßmann
>
> Pleace add success messages to javax.faces.application.FacesMessage, e.g.
> public static final FacesMessage.Severity SEVERITY_SUCCESS = new
> Severity("success", 0);
> thx
> (99270)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MYFACES-3602) Myfaces is disabled by richfaces
[ https://issues.apache.org/jira/browse/MYFACES-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14942676#comment-14942676 ] Thomas Andraschko commented on MYFACES-3602: Thats probably related to RichFaces resource routing/mapping feature. I can't reproduce this e.g. when i add a PrimeFaces component. > Myfaces is disabled by richfaces > > > Key: MYFACES-3602 > URL: https://issues.apache.org/jira/browse/MYFACES-3602 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.1.8 > Environment: Tomee server richfaces 4.2.2 >Reporter: Emmanuel DUFOUR > > The simple presence of the popupanel or calendar or datatable tag frin > richfaces makes the myfaces javascript library not included in the page > disabling the link ex the simple jsf page below : > -- > > http://www.w3.org/1999/xhtml; > xmlns:h="http://java.sun.com/jsf/html; > xmlns:rich="http://richfaces.org/rich;> > > > > > > > > > > --- > A soon as richfaces tags are added to the page, the myFace JavaScript library > link usually included in the 1st form of the page: >
[jira] [Commented] (MYFACES-3629) StartupServletContextListener crashes if FacesServlet is defined in web-fragments.
[ https://issues.apache.org/jira/browse/MYFACES-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14942678#comment-14942678 ] Thomas Andraschko commented on MYFACES-3629: Is there any reason why you didn't merge it back to myfaces? > StartupServletContextListener crashes if FacesServlet is defined in > web-fragments. > -- > > Key: MYFACES-3629 > URL: https://issues.apache.org/jira/browse/MYFACES-3629 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.1.9 >Reporter: Mark Struberg > > I'm trying to move all my common web.xml content from my 12 webapps in an EAR > into a web-fragment.xml which gets referenced. > MyFaces fails with the following Exception if the FacesServlet is defined in > a web-fragment rather than web.xml: > >If you did that and find nothing, the mistake might be due to the fact that > >you use some special > >web-containers which do not support registering context-listeners via TLD > >files and a context listener is not > > setup in your web.xml. > > A typical config looks like this; > > > > > > org.apache.myfaces.webapp.StartupServletContextListener > > > In general the StartupServletContextListener defined in JSF-2.1 is pure PITA > as it does crash apps which do not have any JSF content at all!. > We should scan if we either find a faces-config.xml or any *.xhtml files in > the app and if not we shall not start JSF. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-3212) Give Hint when CustomAnnotationProvider needed, ex. when DefaultAnnotationProvider fails on jboss AS6 related to jboss-vfs urls
[ https://issues.apache.org/jira/browse/MYFACES-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14942757#comment-14942757 ] Thomas Andraschko commented on MYFACES-3212: AFAICS WildFly now provides an mode for MyFaces as JSF implementation. I would close it as won't fix. WDYT? > Give Hint when CustomAnnotationProvider needed, ex. when > DefaultAnnotationProvider fails on jboss AS6 related to jboss-vfs urls > --- > > Key: MYFACES-3212 > URL: https://issues.apache.org/jira/browse/MYFACES-3212 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.7, 2.1.1 > Environment: JBoss AS6 and others >Reporter: Pablo Morales Mombiela > Original Estimate: 1m > Remaining Estimate: 1m > > When scanning class files searching for annotatios, if > org.apache.myfaces.config.annotation.DefaultAnnotationProvider can not open > URL quietly do nothing. It's really difficult to discover what is going on > and many people may think that provided MyFaces can not be used on JbossAS6 > I think that > org.apache.myfaces.config.annotation.DefaultAnnotationProvider._getAlternativeJarFile(URL > url) must report/log some error before 'return null' and point the user to > implement a CustomAnnotationProvider in order to make it work. > I didn't found any documentation that make this clear at any point. MyFaces > documentation should explain: >- why is needed >- How to provide custom DefaultAnnotationProvider in web.xml context param > or in META-INF/services/org.apache.myfaces.spi.AnnotationProvider >- Explain that in JBoss AS6 a custom implementation must be provided able > to use jboss-vsf and point to VSF documentation in > http://community.jboss.org/wiki/VFS3UserGuide. We implemented a scanner based > on VSF visitor pattern that work great but spent a huge amount of time on it. > Can't this provider be included because of license issues with jboss? > This will make migration from Mojarra much faster when using jboss and > probably others. > Thank you for your attention. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4013) action of h:commandButton rendered in h:dataTable doesn't navigate to action page
[ https://issues.apache.org/jira/browse/MYFACES-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14942744#comment-14942744 ] Thomas Andraschko commented on MYFACES-4013: Could you please provide a example? (xhtml + bean) > action of h:commandButton rendered in h:dataTable doesn't navigate to action > page > - > > Key: MYFACES-4013 > URL: https://issues.apache.org/jira/browse/MYFACES-4013 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.8 >Reporter: Santosh P > > I am using h:commandButton in each row of a h:dataTable. I have used a file > name as action attribute value. On click of which the page should be > navigated to other expected page. But when the button is used in h:dataTable > the page just refreshes existing page itself instead of showing content of > other file. However, the action of button works properly when I use it out of > the table. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-3981) Unable to resolve Integer API as Lambda expression in a facelet
[
https://issues.apache.org/jira/browse/MYFACES-3981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14943985#comment-14943985
]
Thomas Andraschko commented on MYFACES-3981:
Yep thats true - same as: https://issues.apache.org/jira/browse/MYFACES-4008
We could of course use reflection but thats not a good way IMO.
We should update the servlet 3.1 (for ticket 4008) and EL 3 and do something
like:
if (el3Available) {ImportHandler}
This should also work fine for el 2.2 as the code is only executed with EL 3.0.
We use some of such statements in PrimeFaces and this is working fine.
[~lu4242] WDYT?
> Unable to resolve Integer API as Lambda expression in a facelet
> ---
>
> Key: MYFACES-3981
> URL: https://issues.apache.org/jira/browse/MYFACES-3981
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-344
>Affects Versions: 2.2.7
>Reporter: Anup
>Priority: Minor
> Attachments: myfaces-3981-2.2.8.patch
>
>
> Following testcases does not print anything in a facelet
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (MYFACES-3985) [perf] avoid field initialization on CDI beans
[ https://issues.apache.org/jira/browse/MYFACES-3985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-3985. Resolution: Fixed > [perf] avoid field initialization on CDI beans > -- > > Key: MYFACES-3985 > URL: https://issues.apache.org/jira/browse/MYFACES-3985 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.2.8 >Reporter: Sami Korhonen >Assignee: Thomas Andraschko > Fix For: 2.2.9 > > > Beans such as ViewScopeBeanHolder should use either @PostConstruct or lazy > initialization to initialize required fields. Depending on CDI implementation > container may create unneccessary objects when field initialization is used -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4014) Log required startup time
[ https://issues.apache.org/jira/browse/MYFACES-4014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14907704#comment-14907704 ] Thomas Andraschko commented on MYFACES-4014: If there are no objections, i will commit it in 1-2 weeks. > Log required startup time > - > > Key: MYFACES-4014 > URL: https://issues.apache.org/jira/browse/MYFACES-4014 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: MYFACES-4014.patch > > > similiar to OWB: > MyFaces Core has started, it took [1000] ms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4015) [perf] provide annotation scanning via CDI extension
[ https://issues.apache.org/jira/browse/MYFACES-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14907710#comment-14907710 ] Thomas Andraschko commented on MYFACES-4015: If there are no objections, i will commit it in 1-2 weeks. > [perf] provide annotation scanning via CDI extension > > > Key: MYFACES-4015 > URL: https://issues.apache.org/jira/browse/MYFACES-4015 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 2.2.8 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko > Attachments: MYFACES-4015.patch > > > Improves the startup performance a lot if many jars are available in the > classpath. > In my environment its about 700ms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-4015) [perf] provide annotation scanning via CDI extension
[ https://issues.apache.org/jira/browse/MYFACES-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated MYFACES-4015: --- Status: Patch Available (was: Open) > [perf] provide annotation scanning via CDI extension > > > Key: MYFACES-4015 > URL: https://issues.apache.org/jira/browse/MYFACES-4015 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 2.2.8 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko > Attachments: MYFACES-4015.patch > > > Improves the startup performance a lot if many jars are available in the > classpath. > In my environment its about 700ms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MYFACES-4014) Log required startup time
Thomas Andraschko created MYFACES-4014: -- Summary: Log required startup time Key: MYFACES-4014 URL: https://issues.apache.org/jira/browse/MYFACES-4014 Project: MyFaces Core Issue Type: Improvement Components: General Reporter: Thomas Andraschko Assignee: Thomas Andraschko Priority: Minor similiar to OWB: MyFaces Core has started, it took [1000] ms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-4014) Log required startup time
[ https://issues.apache.org/jira/browse/MYFACES-4014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated MYFACES-4014: --- Status: Patch Available (was: Open) > Log required startup time > - > > Key: MYFACES-4014 > URL: https://issues.apache.org/jira/browse/MYFACES-4014 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > > similiar to OWB: > MyFaces Core has started, it took [1000] ms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MYFACES-4015) [perf] provide annotation scanning via CDI extension
Thomas Andraschko created MYFACES-4015: -- Summary: [perf] provide annotation scanning via CDI extension Key: MYFACES-4015 URL: https://issues.apache.org/jira/browse/MYFACES-4015 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 2.2.8 Reporter: Thomas Andraschko Assignee: Thomas Andraschko Improves the startup performance a lot if many jars are available in the classpath. In my environment its about 700ms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MYFACES-2932) More error logging when Bean Validation throws an exception at startup
[ https://issues.apache.org/jira/browse/MYFACES-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-2932. Resolution: Won't Fix Please check our issue closing policy: http://myfaces.apache.org/wiki/core/committer-and-pmc-guide/myfaces-project-management.html If the is issue is still important for you, please reopen and attach a patch. > More error logging when Bean Validation throws an exception at startup > -- > > Key: MYFACES-2932 > URL: https://issues.apache.org/jira/browse/MYFACES-2932 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.2 > Environment: Any >Reporter: Jan-Kees van Andel > > When the Bean Validation implementation fails to startup, for example because > it is misconfigured by the developer, or because of some dependency issue > (missing slf4j jar or something), the Bean Validator automatically turns > itself off. > The error is logged as "fine", because in many cases the developer doesn't > care about this behavior. For example, if bean validation api is provided, > but impl is not. In these cases, logging an error is not desirable. > But maybe this should be increased to "info", to ease debugging in the cases > where the developer is interested in why bean validation fails to startup. > I guess we change the logging to "info", especially because the block of code > is guarded by a Class.forName() check, which takes care of the obvious case > that Bean Validation is unavailable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MYFACES-2629) Accept abstract FaceletContext, do not force AbstractFaceletContext
[ https://issues.apache.org/jira/browse/MYFACES-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-2629. Resolution: Won't Fix Please check our issue closing policy: http://myfaces.apache.org/wiki/core/committer-and-pmc-guide/myfaces-project-management.html If the is issue is still important for you, please reopen and attach a patch. > Accept abstract FaceletContext, do not force AbstractFaceletContext > --- > > Key: MYFACES-2629 > URL: https://issues.apache.org/jira/browse/MYFACES-2629 > Project: MyFaces Core > Issue Type: Improvement > Components: General, JSR-314 >Affects Versions: 2.0.0-beta-3 > Environment: Tomcat 6.0+, MyFaces 2.0.0-beta3 API/Impl. >Reporter: Lewis Gass >Assignee: Leonardo Uribe > Attachments: MYFACES-2629-1.patch, MYFACES-2629-2.patch > > > I am the main coder on the Gracelets project > (http://gracelets.sourceforge.net/) and have recently began integration of > Groovy with JSF 2.0. In order for Gracelets to harness the already existing > Facelets libraries it needs access to the TagLibrary class and the actual > libraries loaded by the JSF 2.0 implementation. Since that library is not > part of the JSF 2.0 public API, I have to write an extension for each > different JSF 2.0 implementation in order to load them. I have been able to > successfully integrate with the SUN RI with minimal code. However, in MyFaces > Core implementation this code appears on line 135 of the > org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate: > AbstractFaceletContext actx = (AbstractFaceletContext) ctx; > Gracelets has its own FaceletContext (which is part of the public API) in > order to mimimize integration between different JSF 2.0 implementations. > Since in MyFaces this is forced to be a particular sub class here, it breaks > portability. Is there anyway this can be avoided? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MYFACES-2618) Don't warn if there is no submitted value in the current request for every EditableValueHolder
[ https://issues.apache.org/jira/browse/MYFACES-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated MYFACES-2618: --- Resolution: Won't Fix Status: Resolved (was: Patch Available) Please check our issue closing policy: http://myfaces.apache.org/wiki/core/committer-and-pmc-guide/myfaces-project-management.html If the is issue is still important for you, please reopen and attach a patch. > Don't warn if there is no submitted value in the current request for every > EditableValueHolder > -- > > Key: MYFACES-2618 > URL: https://issues.apache.org/jira/browse/MYFACES-2618 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-beta-2 >Reporter: Jakob Korherr >Assignee: Jakob Korherr >Priority: Minor > Attachments: MYFACES-2618.patch > > > Take a look at HtmlRendererUtils.decodeUIInput(): There we do a check for > paramMap.containsKey(clientId) and if this returns false (meaning that there > is no submitted value for the given component in the request parameter map) > we add a warning message to the log. > I think we should get rid of this warning, because as a reason of AJAX it is > on my opinion normal to not submit all values of a form in every request. > Furthermore it has no impact on the lifecycle, because if the submitted value > is null it just isn't processed any further. > See also the related thread on the mailing list: > http://www.mail-archive.com/users@myfaces.apache.org/msg55238.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MYFACES-2674) ClassNotFoundException when using "org.apache.myfaces.annotation.SCAN_PACKAGES" parameter with not existing package
[ https://issues.apache.org/jira/browse/MYFACES-2674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-2674. Resolution: Won't Fix Please check our issue closing policy: http://myfaces.apache.org/wiki/core/committer-and-pmc-guide/myfaces-project-management.html If the is issue is still important for you, please reopen and attach a patch. > ClassNotFoundException when using > "org.apache.myfaces.annotation.SCAN_PACKAGES" parameter with not existing > package > --- > > Key: MYFACES-2674 > URL: https://issues.apache.org/jira/browse/MYFACES-2674 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Reporter: Matthias Weßendorf > > in web.xml have the following ctx param: > > org.apache.myfaces.annotation.SCAN_PACKAGES > net.wessendorf > > but if this package does not exist, you'll notice this: > Caused by: java.lang.ClassNotFoundException: No resource for net/wessendorf > at > org.apache.myfaces.config.annotation._PackageInfo.getClasses(_PackageInfo.java:102) > at > org.apache.myfaces.config.annotation.AnnotationConfigurator.packageClasses(AnnotationConfigurator.java:332) > at > org.apache.myfaces.config.annotation.AnnotationConfigurator.configure(AnnotationConfigurator.java:186) > ... 17 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MYFACES-4012) Documentation wrong about Error handling
[
https://issues.apache.org/jira/browse/MYFACES-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057981#comment-15057981
]
Thomas Andraschko edited comment on MYFACES-4012 at 12/15/15 12:30 PM:
---
[~mkienenb] Would you please check my wiki role? I would like to change it but
AFAICS i have no edit role.
was (Author: tandraschko):
[~mkienenb] Would you please check my wiki role? I would like to change it but
AFAIK i have no edit role.
> Documentation wrong about Error handling
>
>
> Key: MYFACES-4012
> URL: https://issues.apache.org/jira/browse/MYFACES-4012
> Project: MyFaces Core
> Issue Type: Bug
> Components: website
>Reporter: Matthew Alexander
>Priority: Minor
>
> https://cwiki.apache.org/confluence/display/MYFACES/Handling+Server+Errors
> Current version:
> {quote}
> *Provide an error page*
> The default ExceptionHandler in Production stage or when myfaces error
> handling is disabled just throw an exception. So you can still setup an error
> page adding something like this in your web.xml file:
> {code}
> 500
> /somepage.jsp
> {code}
> {quote}
> Should be:
> {quote}
> *Provide an error page*
> If org.apache.myfaces.ERROR_HANDLING is set to "false", or if it is undefined
> and the project stage is "Development", the default ExceptionHandler just
> throws an exception. So you can still setup an error page by adding something
> like this in your web.xml file:
> {code}
> 500
> /somepage.jsp
> {code}
> {quote}
> Changes
> - Corrected the explanation of the behavior of the default ExceptionHandler.
> - Improved the grammar.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MYFACES-4012) Documentation wrong about Error handling
[
https://issues.apache.org/jira/browse/MYFACES-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057981#comment-15057981
]
Thomas Andraschko commented on MYFACES-4012:
[~mkienenb] Would you please check my wiki role? I would like to change it but
AFAIK i have no edit role.
> Documentation wrong about Error handling
>
>
> Key: MYFACES-4012
> URL: https://issues.apache.org/jira/browse/MYFACES-4012
> Project: MyFaces Core
> Issue Type: Bug
> Components: website
>Reporter: Matthew Alexander
>Priority: Minor
>
> https://cwiki.apache.org/confluence/display/MYFACES/Handling+Server+Errors
> Current version:
> {quote}
> *Provide an error page*
> The default ExceptionHandler in Production stage or when myfaces error
> handling is disabled just throw an exception. So you can still setup an error
> page adding something like this in your web.xml file:
> {code}
> 500
> /somepage.jsp
> {code}
> {quote}
> Should be:
> {quote}
> *Provide an error page*
> If org.apache.myfaces.ERROR_HANDLING is set to "false", or if it is undefined
> and the project stage is "Development", the default ExceptionHandler just
> throws an exception. So you can still setup an error page by adding something
> like this in your web.xml file:
> {code}
> 500
> /somepage.jsp
> {code}
> {quote}
> Changes
> - Corrected the explanation of the behavior of the default ExceptionHandler.
> - Improved the grammar.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MYFACES-4012) Documentation wrong about Error handling
[
https://issues.apache.org/jira/browse/MYFACES-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058103#comment-15058103
]
Thomas Andraschko commented on MYFACES-4012:
Thanks Mike!
Done!
> Documentation wrong about Error handling
>
>
> Key: MYFACES-4012
> URL: https://issues.apache.org/jira/browse/MYFACES-4012
> Project: MyFaces Core
> Issue Type: Bug
> Components: website
>Reporter: Matthew Alexander
>Priority: Minor
>
> https://cwiki.apache.org/confluence/display/MYFACES/Handling+Server+Errors
> Current version:
> {quote}
> *Provide an error page*
> The default ExceptionHandler in Production stage or when myfaces error
> handling is disabled just throw an exception. So you can still setup an error
> page adding something like this in your web.xml file:
> {code}
> 500
> /somepage.jsp
> {code}
> {quote}
> Should be:
> {quote}
> *Provide an error page*
> If org.apache.myfaces.ERROR_HANDLING is set to "false", or if it is undefined
> and the project stage is "Development", the default ExceptionHandler just
> throws an exception. So you can still setup an error page by adding something
> like this in your web.xml file:
> {code}
> 500
> /somepage.jsp
> {code}
> {quote}
> Changes
> - Corrected the explanation of the behavior of the default ExceptionHandler.
> - Improved the grammar.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (MYFACES-4012) Documentation wrong about Error handling
[
https://issues.apache.org/jira/browse/MYFACES-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved MYFACES-4012.
Resolution: Fixed
Assignee: Thomas Andraschko
> Documentation wrong about Error handling
>
>
> Key: MYFACES-4012
> URL: https://issues.apache.org/jira/browse/MYFACES-4012
> Project: MyFaces Core
> Issue Type: Bug
> Components: website
>Reporter: Matthew Alexander
>Assignee: Thomas Andraschko
>Priority: Minor
>
> https://cwiki.apache.org/confluence/display/MYFACES/Handling+Server+Errors
> Current version:
> {quote}
> *Provide an error page*
> The default ExceptionHandler in Production stage or when myfaces error
> handling is disabled just throw an exception. So you can still setup an error
> page adding something like this in your web.xml file:
> {code}
> 500
> /somepage.jsp
> {code}
> {quote}
> Should be:
> {quote}
> *Provide an error page*
> If org.apache.myfaces.ERROR_HANDLING is set to "false", or if it is undefined
> and the project stage is "Development", the default ExceptionHandler just
> throws an exception. So you can still setup an error page by adding something
> like this in your web.xml file:
> {code}
> 500
> /somepage.jsp
> {code}
> {quote}
> Changes
> - Corrected the explanation of the behavior of the default ExceptionHandler.
> - Improved the grammar.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MYFACES-4027) Increase import range for javax.el-api to include version 3.0 of javax.el-api
[ https://issues.apache.org/jira/browse/MYFACES-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102082#comment-15102082 ] Thomas Andraschko commented on MYFACES-4027: Your patch looks fine but currently noone applied it, so a SNAPSHOT with this change doesn't exist. I can take care of it after my holiday ;) > Increase import range for javax.el-api to include version 3.0 of javax.el-api > - > > Key: MYFACES-4027 > URL: https://issues.apache.org/jira/browse/MYFACES-4027 > Project: MyFaces Core > Issue Type: Improvement > Components: build process >Affects Versions: 2.2.9 >Reporter: Achim Nierbeck > Attachments: myfaces-core-module.patch > > > Right now the version range for javax.el package is [2.2, 3.0), this version > Range makes it impossible to use javax.el in version 3.0. > AFAIK MyFaces should work without issues with version 3.0 of javax el, > therefore the version range needs to be increased. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4033) Weird behavior with form authencation / forward / restore view
[
https://issues.apache.org/jira/browse/MYFACES-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15157688#comment-15157688
]
Thomas Andraschko commented on MYFACES-4033:
I think that
HtmlResponseStateManager#isPostback should also check the HTTP method and not
only the VIEW_STATE_PARAM.
WDYT?
> Weird behavior with form authencation / forward / restore view
> --
>
> Key: MYFACES-4033
> URL: https://issues.apache.org/jira/browse/MYFACES-4033
> Project: MyFaces Core
> Issue Type: Bug
>Reporter: Thomas Andraschko
>Assignee: Leonardo Uribe
>
> Following case:
> 1) visit login.xhtml
> with
>
>
>
>
>
> 2) submit (non-ajax post) with invalid user
> 3) tomcat forwards to the loginError.xhtml
> 4) MyFaces tries to restore the view with the ViewState from login.xhtml
> 5) ViewExpired occurs
> IMO MyFaces should not restore the view after a forward ->
> if (post && forward) {
>-> new view
> }
> else {
>-> restore
> }
> It also works fine in Mojarra.
> [~lu4242] How would you fix it?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MYFACES-4033) Weird behavior with form authencation / forward / restore view
[
https://issues.apache.org/jira/browse/MYFACES-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15158642#comment-15158642
]
Thomas Andraschko commented on MYFACES-4033:
Hmm, you are absolulety right.
I just debugged both mojarra and myfaces and in mojarra the view is just
restored... In MyFaces restoring the view fails (which is correct).
"javax.servlet.error.message" is not set - so we restore the view.
The question is, would it break other cases if we would also check for a
forward before trying to restore the view?
It's working fine in jetty because jetty redirects instead a forward if the
auth fails.
> Weird behavior with form authencation / forward / restore view
> --
>
> Key: MYFACES-4033
> URL: https://issues.apache.org/jira/browse/MYFACES-4033
> Project: MyFaces Core
> Issue Type: Bug
>Reporter: Thomas Andraschko
>Assignee: Leonardo Uribe
>
> Following case:
> 1) visit login.xhtml
> with
>
>
>
>
>
> 2) submit (non-ajax post) with invalid user
> 3) tomcat forwards to the loginError.xhtml
> 4) MyFaces tries to restore the view with the ViewState from login.xhtml
> 5) ViewExpired occurs
> IMO MyFaces should not restore the view after a forward ->
> if (post && forward) {
>-> new view
> }
> else {
>-> restore
> }
> It also works fine in Mojarra.
> [~lu4242] How would you fix it?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MYFACES-4033) Weird behavior with form authencation / forward / restore view
[
https://issues.apache.org/jira/browse/MYFACES-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159731#comment-15159731
]
Thomas Andraschko commented on MYFACES-4033:
Detecting a forward is easy ->
if (request.getAttribute("javax.servlet.forward.request_uri") != null) { //
forward }
I'm just not sure if there is a case when restoring the view after a forward
could be valid. What about url rewrites? do they use forwards internally?
Maybe a valid check is to check the request Url, too (which is
j_security_check).
> Weird behavior with form authencation / forward / restore view
> --
>
> Key: MYFACES-4033
> URL: https://issues.apache.org/jira/browse/MYFACES-4033
> Project: MyFaces Core
> Issue Type: Bug
>Reporter: Thomas Andraschko
>Assignee: Leonardo Uribe
>
> Following case:
> 1) visit login.xhtml
> with
>
>
>
>
>
> 2) submit (non-ajax post) with invalid user
> 3) tomcat forwards to the loginError.xhtml
> 4) MyFaces tries to restore the view with the ViewState from login.xhtml
> 5) ViewExpired occurs
> IMO MyFaces should not restore the view after a forward ->
> if (post && forward) {
>-> new view
> }
> else {
>-> restore
> }
> It also works fine in Mojarra.
> [~lu4242] How would you fix it?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MYFACES-4033) Weird behavior with form authencation / forward / restore view
Thomas Andraschko created MYFACES-4033:
--
Summary: Weird behavior with form authencation / forward / restore
view
Key: MYFACES-4033
URL: https://issues.apache.org/jira/browse/MYFACES-4033
Project: MyFaces Core
Issue Type: Bug
Reporter: Thomas Andraschko
Assignee: Leonardo Uribe
Following case:
1) visit login.xhtml
with
2) submit (non-ajax post) with invalid user
3) tomcat forwards to the loginError.xhtml
4) MyFaces tries to restore the view with the ViewState from login.xhtml
5) ViewExpired occurs
IMO MyFaces should not restore the view after a forward ->
if (post && forward) {
-> new view
}
else {
-> restore
}
It also works fine in Mojarra.
[~lu4242] How would you fix it?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MYFACES-4030) MyFaces CDI support is disabled if non-CDI application is loaded first
[
https://issues.apache.org/jira/browse/MYFACES-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15145414#comment-15145414
]
Thomas Andraschko commented on MYFACES-4030:
shoudln't "fix versions" target 2.2.10 instead of 2.2.10-SNAPSOT?
> MyFaces CDI support is disabled if non-CDI application is loaded first
> --
>
> Key: MYFACES-4030
> URL: https://issues.apache.org/jira/browse/MYFACES-4030
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.2.10-SNAPSHOT
> Environment: WebSphere Liberty 8.5.5.8, Weld 2.3, MyFaces 2.2.8
>Reporter: Hank Ibell
>Assignee: Bill Lucy
>Priority: Minor
> Fix For: 2.2.10-SNAPSHOT
>
> Attachments: myfaces-4030.patch
>
>
> If MyFaces 2.2 is loaded at the server level, MyFaces CDI support is set once
> per server. This causes CDI-enabled JSF applications to not work properly if
> a non-CDI application is loaded first.
> {panel:title=Steps to reproduce the error on WebSphere
> Liberty|bgColor=#e8e8e8}
> 1. Enable the jsf-2.2 and cdi-1.2 features on the WebSphere Liberty server.
> 2. Deploy two JSF applications: one that uses CDI (e.g. a flow built using
> FlowBuilder) and one that does not use CDI.
> 3. Make a request to the non-CDI application first. The message 'MyFaces CDI
> support disabled' should be written to the logs.
> 4. Make a request to the CDI-enabled application. If testing an application
> with a flow built using FlowBuilder, the flow will not be discovered.
> {panel}
> I've investigated the issue and found that MyFaces has two conditions to
> determine CDI availability:
> 1. CDI must be found on the classpath
> 2. The application map must have a bean manager instance
> (Found inside
> org.apache.myfaces.util.ExternalSpecifications#isCDIAvailable()).
> When MyFaces is shared between different applications, basing CDI
> availability on an application's configuration (condition two) is an issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MYFACES-4042) Improve startup time by skipping classpath jar scan for *.faces-config.xml
[ https://issues.apache.org/jira/browse/MYFACES-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15224901#comment-15224901 ] Thomas Andraschko commented on MYFACES-4042: For me it sounds like: If the user doesn't add the FacesServlet to the web.xml, we can skip faces-config.xml scanning. Is there any case that users may add MyFaces as dependency and don't use it? > Improve startup time by skipping classpath jar scan for *.faces-config.xml > -- > > Key: MYFACES-4042 > URL: https://issues.apache.org/jira/browse/MYFACES-4042 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.1.18, 2.2.9 > Environment: WebSphere >Reporter: Bill Lucy >Priority: Minor > Attachments: MYFACES-4042.patch > > > In version 2.1 org.apache.myfaces.ee6.MyFacesContainerInitializer was updated > to scan for faces-config.xml resources in applications JARs during startup, > as part of the process to add a FacesConfig in onStartup(). This is a very > expensive scan, since we have to iterate over every file in every jar on the > app classpath. > This scan is not completely necessary: in the spec we have: > Section 11.4.2 “Application Startup Behavior” > Implementations may check for the presence of a servlet-class definition of > class javax.faces.webapp.FacesServlet in the web application deployment > descriptor as a means to abort the configuration process and reduce startup > time for applications that do not use JavaServer Faces Technology. > Which I interpret to mean that skipping checking the app jars at init time - > for the purpose of adding a dynamic FacesServlet - is valid. Given the > performance hit for the scan, I think adding a context param to disable the > scan would be worthwhile. Something like: > org.apache.myfaces.INITIALIZE_SKIP_JAR_FACES_CONFIG_SCAN > Would this be worthwhile for others? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4042) Improve startup time by skipping classpath jar scan for *.faces-config.xml
[ https://issues.apache.org/jira/browse/MYFACES-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15225008#comment-15225008 ] Thomas Andraschko commented on MYFACES-4042: I'm really not sure why this is required actually. Why not just remove the MyFaces dependency if you don't need JSF in this project? ApplicationsServers like TomEE should have a special integration and skip faces-config.xml scanning if no FacesServlet is defined in the web.xml. > Improve startup time by skipping classpath jar scan for *.faces-config.xml > -- > > Key: MYFACES-4042 > URL: https://issues.apache.org/jira/browse/MYFACES-4042 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.1.18, 2.2.9 > Environment: WebSphere >Reporter: Bill Lucy >Priority: Minor > Attachments: MYFACES-4042.patch > > > In version 2.1 org.apache.myfaces.ee6.MyFacesContainerInitializer was updated > to scan for faces-config.xml resources in applications JARs during startup, > as part of the process to add a FacesConfig in onStartup(). This is a very > expensive scan, since we have to iterate over every file in every jar on the > app classpath. > This scan is not completely necessary: in the spec we have: > Section 11.4.2 “Application Startup Behavior” > Implementations may check for the presence of a servlet-class definition of > class javax.faces.webapp.FacesServlet in the web application deployment > descriptor as a means to abort the configuration process and reduce startup > time for applications that do not use JavaServer Faces Technology. > Which I interpret to mean that skipping checking the app jars at init time - > for the purpose of adding a dynamic FacesServlet - is valid. Given the > performance hit for the scan, I think adding a context param to disable the > scan would be worthwhile. Something like: > org.apache.myfaces.INITIALIZE_SKIP_JAR_FACES_CONFIG_SCAN > Would this be worthwhile for others? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4060) Required attribute of h:inputFile tag is not working
[ https://issues.apache.org/jira/browse/MYFACES-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15415970#comment-15415970 ] Thomas Andraschko commented on MYFACES-4060: +1 > Required attribute of h:inputFile tag is not working > > > Key: MYFACES-4060 > URL: https://issues.apache.org/jira/browse/MYFACES-4060 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.10 >Reporter: Eduardo Breijo > Attachments: MYFACES-4060.patch > > > The required attribute of h:inputFile tag doesn't work when set to "true" and > no file is attached. The action will be executed regardless of the value of > the required attribute. > Example: > > > > > > An error message should be expected/displayed when the required attribute is > set to true, and no file is attached. Instead it is executing the action > without attachments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MYFACES-4088) Add constructor with facesContext to event classes
[ https://issues.apache.org/jira/browse/MYFACES-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-4088. Resolution: Fixed Fix Version/s: 2.3.0 > Add constructor with facesContext to event classes > -- > > Key: MYFACES-4088 > URL: https://issues.apache.org/jira/browse/MYFACES-4088 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-372 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > > https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-807 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYFACES-4086) Deprecate native managed beans annotations
Thomas Andraschko created MYFACES-4086: -- Summary: Deprecate native managed beans annotations Key: MYFACES-4086 URL: https://issues.apache.org/jira/browse/MYFACES-4086 Project: MyFaces Core Issue Type: New Feature Components: JSR-372 Reporter: Thomas Andraschko Assignee: Thomas Andraschko -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYFACES-4085) Constants for "jsf.js", "javax.faces" and postback parameters
[ https://issues.apache.org/jira/browse/MYFACES-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859462#comment-15859462 ] Thomas Andraschko commented on MYFACES-4085: Done > Constants for "jsf.js", "javax.faces" and postback parameters > - > > Key: MYFACES-4085 > URL: https://issues.apache.org/jira/browse/MYFACES-4085 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-372 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko > > http://arjan-tijms.omnifaces.org/p/jsf-23.html#1428 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYFACES-4088) Add constructor with facesContext to event classes
[ https://issues.apache.org/jira/browse/MYFACES-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859548#comment-15859548 ] Thomas Andraschko commented on MYFACES-4088: Done > Add constructor with facesContext to event classes > -- > > Key: MYFACES-4088 > URL: https://issues.apache.org/jira/browse/MYFACES-4088 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-372 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko > > https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-807 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYFACES-4087) Add PostRenderViewEvent
[ https://issues.apache.org/jira/browse/MYFACES-4087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859681#comment-15859681 ] Thomas Andraschko commented on MYFACES-4087: Done > Add PostRenderViewEvent > --- > > Key: MYFACES-4087 > URL: https://issues.apache.org/jira/browse/MYFACES-4087 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-372 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko > > http://arjan-tijms.omnifaces.org/p/jsf-23.html#1135 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYFACES-4084) Implement f:importConstants
Thomas Andraschko created MYFACES-4084: -- Summary: Implement f:importConstants Key: MYFACES-4084 URL: https://issues.apache.org/jira/browse/MYFACES-4084 Project: MyFaces Core Issue Type: Task Components: JSR-372 Reporter: Thomas Andraschko -- This message was sent by Atlassian JIRA (v6.3.15#6346)
