[jira] [Commented] (MYFACES-4648) PushContextImpl - different behaviour when socket is not connected
[
https://issues.apache.org/jira/browse/MYFACES-4648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807207#comment-17807207
]
Thomas Andraschko commented on MYFACES-4648:
+1
could you also check mojarra here?
> PushContextImpl - different behaviour when socket is not connected
> --
>
> Key: MYFACES-4648
> URL: https://issues.apache.org/jira/browse/MYFACES-4648
> Project: MyFaces Core
> Issue Type: Task
> Components: General
>Affects Versions: 4.0.1, 4.0.2, 4.1.0, 5.0.0
>Reporter: Milan Siebenbürger
>Priority: Minor
>
> Hi,
> when sending a message via PushContextImpl, the behaviour differs when using
> methods with or without user specification.
> A new FacesException is thrown when the send() method is used without a user
> specification and without an open channel:
> {code:java}
> throw new FacesException("CDI bean not found for push message");{code}
> When using send() with a user specified, an empty HashMap is returned.
>
> I think the behavior should be the same - either Exception (not recommended)
> or an empty result.
>
> What do you think about this? I am able to prepare a PR (for whatever version
> you need), but let me know what result you chose.
>
> Br
> Milan
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4649) ViewScoped bean handling broken because of refactoring
Thomas Andraschko created MYFACES-4649: -- Summary: ViewScoped bean handling broken because of refactoring Key: MYFACES-4649 URL: https://issues.apache.org/jira/browse/MYFACES-4649 Project: MyFaces Core Issue Type: Bug Reporter: Thomas Andraschko i restored the 2.3.x behavior -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4649) ViewScoped bean handling broken because of refactoring
[ https://issues.apache.org/jira/browse/MYFACES-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-4649. Resolution: Fixed > ViewScoped bean handling broken because of refactoring > -- > > Key: MYFACES-4649 > URL: https://issues.apache.org/jira/browse/MYFACES-4649 > Project: MyFaces Core > Issue Type: Bug >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Major > Fix For: 4.0.2, 4.1.0, 5.0.0 > > > i restored the 2.3.x behavior > this occured because of DeltaSpike putAll values from oldViewMap to > newViewMap on redirect via SecurityAwareViewHandler -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4648) PushContextImpl - different behaviour when socket is not connected
[
https://issues.apache.org/jira/browse/MYFACES-4648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807272#comment-17807272
]
Thomas Andraschko commented on MYFACES-4648:
as long there is no reason, i think we can stick with empty hashmap.
please provide a PR ASAP, we discussed already about the next release
> PushContextImpl - different behaviour when socket is not connected
> --
>
> Key: MYFACES-4648
> URL: https://issues.apache.org/jira/browse/MYFACES-4648
> Project: MyFaces Core
> Issue Type: Task
> Components: General
>Affects Versions: 4.0.1, 4.0.2, 4.1.0, 5.0.0
>Reporter: Milan Siebenbürger
>Priority: Minor
>
> Hi,
> when sending a message via PushContextImpl, the behaviour differs when using
> methods with or without user specification.
> A new FacesException is thrown when the send() method is used without a user
> specification and without an open channel:
> {code:java}
> throw new FacesException("CDI bean not found for push message");{code}
> When using send() with a user specified, an empty HashMap is returned.
>
> I think the behavior should be the same - either Exception (not recommended)
> or an empty result.
>
> What do you think about this? I am able to prepare a PR (for whatever version
> you need), but let me know what result you chose.
>
> Br
> Milan
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MYFACES-4648) PushContextImpl - different behaviour when socket is not connected
[
https://issues.apache.org/jira/browse/MYFACES-4648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved MYFACES-4648.
Resolution: Fixed
Thanks,
Great contribution as always
> PushContextImpl - different behaviour when socket is not connected
> --
>
> Key: MYFACES-4648
> URL: https://issues.apache.org/jira/browse/MYFACES-4648
> Project: MyFaces Core
> Issue Type: Task
> Components: General
>Affects Versions: 4.0.1, 4.0.2, 4.1.0, 5.0.0
>Reporter: Milan Siebenbürger
>Priority: Minor
> Fix For: 4.0.2, 4.1.0, 5.0.0
>
>
> Hi,
> when sending a message via PushContextImpl, the behaviour differs when using
> methods with or without user specification.
> A new FacesException is thrown when the send() method is used without a user
> specification and without an open channel:
> {code:java}
> throw new FacesException("CDI bean not found for push message");{code}
> When using send() with a user specified, an empty HashMap is returned.
>
> I think the behavior should be the same - either Exception (not recommended)
> or an empty result.
>
> What do you think about this? I am able to prepare a PR (for whatever version
> you need), but let me know what result you chose.
>
> Br
> Milan
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MYFACES-4650) UIViewRoot#resetValues called from #processPartialRendering should use VisitHint.SKIP_UNRENDERED
Thomas Andraschko created MYFACES-4650: -- Summary: UIViewRoot#resetValues called from #processPartialRendering should use VisitHint.SKIP_UNRENDERED Key: MYFACES-4650 URL: https://issues.apache.org/jira/browse/MYFACES-4650 Project: MyFaces Core Issue Type: Bug Reporter: Thomas Andraschko -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4650) UIViewRoot#resetValues called from #processPartialRendering should use VisitHint.SKIP_UNRENDERED
[ https://issues.apache.org/jira/browse/MYFACES-4650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-4650. Resolution: Fixed > UIViewRoot#resetValues called from #processPartialRendering should use > VisitHint.SKIP_UNRENDERED > > > Key: MYFACES-4650 > URL: https://issues.apache.org/jira/browse/MYFACES-4650 > Project: MyFaces Core > Issue Type: Bug >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Major > Fix For: 2.3.11, 3.0.3, 4.0.2, 2.3-next-M9, 4.1.0-RC1, 5.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4642) ViewScope doesn't work in non CDI environment
[ https://issues.apache.org/jira/browse/MYFACES-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-4642. Resolution: Fixed > ViewScope doesn't work in non CDI environment > - > > Key: MYFACES-4642 > URL: https://issues.apache.org/jira/browse/MYFACES-4642 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.1 >Reporter: Carsten Dimmek >Assignee: Thomas Andraschko >Priority: Major > Fix For: 5.0.0, 4.1.0-RC2, 4.0.3 > > Attachments: demo.zip, myfaces-viewmap.zip > > > We use Spring Boot with Joinfaces and Myfaces. I noticed that the ViewScope > is not working properly. The controller is re-instantiated with every Ajax > request on the page. I have tried to analyze the problem and suspect it is > because no viewScopeId is created in > org.apache.myfaces.view.ViewScopeProxyMap for the non-CDI case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4653) Faces 4.1 Spec Issue 1838: Remove references to the Java SecurityManager and associated APIs
[ https://issues.apache.org/jira/browse/MYFACES-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825366#comment-17825366 ] Thomas Andraschko commented on MYFACES-4653: please also merge to 5.x > Faces 4.1 Spec Issue 1838: Remove references to the Java SecurityManager and > associated APIs > > > Key: MYFACES-4653 > URL: https://issues.apache.org/jira/browse/MYFACES-4653 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.1.0-RC1, 5.0.0 >Reporter: Paul Nicolucci >Assignee: Paul Nicolucci >Priority: Major > Fix For: 5.0.0, 4.1.0-RC2 > > > Link to specification issue: [https://github.com/jakartaee/faces/issues/1838] > > We need to clean up our references to the SecurityManager and associated APIs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4655) NPE in FacesValidatorCDIWrapper
[
https://issues.apache.org/jira/browse/MYFACES-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827018#comment-17827018
]
Thomas Andraschko commented on MYFACES-4655:
yeah please
you can use the primefaces-test project
> NPE in FacesValidatorCDIWrapper
> ---
>
> Key: MYFACES-4655
> URL: https://issues.apache.org/jira/browse/MYFACES-4655
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.2
> Environment: Eclipse Adoptium jdk-11.0.14.101-hotspot
> Apache Tomcat 10.1.2
> MyFaces 4.0.2
> Weld 4.0.3.Final
>Reporter: Nicola Isotta
>Priority: Major
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
>
> I'm moving one application from Mojarra to MyFaces.
> One of the page fails on submit because of a NullPointerException in
> FacesValidatorCDIWrapper.
> Debugging I found out it happens on a validator attached to a composite
> component using the for attribute.
> I'll try to arrange a standalone reproducer, meanwhile here's the stack trace:
> {code:java}
> java.lang.NullPointerException: null
> at
> org.apache.myfaces.cdi.wrapper.FacesValidatorCDIWrapper.validate(FacesValidatorCDIWrapper.java:59)
> ~[myfaces-impl-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.core.api.shared.ComponentUtils.callValidators(ComponentUtils.java:245)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIInput.validateValue(UIInput.java:463)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UISelectOne.validateValue(UISelectOne.java:166)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> org.primefaces.component.selectonemenu.SelectOneMenu.validateValue(SelectOneMenu.java:197)
> ~[primefaces-13.0.7-jakarta.jar:13.0.7]
> at jakarta.faces.component.UIInput.validate(UIInput.java:717)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIInput.processValidators(UIInput.java:297)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UISelectOne.processValidators(UISelectOne.java:116)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1372)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIForm.processValidators(UIForm.java:200)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIViewRoot._processValidatorsDefault(UIViewRoot.java:1758)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIViewRoot$ProcessValidatorPhaseProcessor.process(UIViewRoot.java:1866)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIViewRoot._process(UIViewRoot.java:1714)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIViewRoot.processValidators(UIViewRoot.java:972)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:39)
> ~[myfaces-impl-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:172)
> [myfaces-impl-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:125)
> [myfaces-impl-4.0.2.jar:4.0.2]
> at jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:223)
> [myfaces-api-4.0.2.jar:4.0.2] {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4655) NPE in FacesValidatorCDIWrapper
[
https://issues.apache.org/jira/browse/MYFACES-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827041#comment-17827041
]
Thomas Andraschko commented on MYFACES-4655:
would you like to prepare a PR?
> NPE in FacesValidatorCDIWrapper
> ---
>
> Key: MYFACES-4655
> URL: https://issues.apache.org/jira/browse/MYFACES-4655
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.2
> Environment: Eclipse Adoptium jdk-11.0.14.101-hotspot
> Apache Tomcat 10.1.2
> MyFaces 4.0.2
> Weld 4.0.3.Final
>Reporter: Nicola Isotta
>Priority: Major
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
> Attachments: primefaces-test.zip
>
>
> I'm moving one application from Mojarra to MyFaces.
> One of the page fails on submit because of a NullPointerException in
> FacesValidatorCDIWrapper.
> I'll try to arrange a standalone reproducer, meanwhile here's the stack trace:
> {code:java}
> java.lang.NullPointerException: null
> at
> org.apache.myfaces.cdi.wrapper.FacesValidatorCDIWrapper.validate(FacesValidatorCDIWrapper.java:59)
> ~[myfaces-impl-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.core.api.shared.ComponentUtils.callValidators(ComponentUtils.java:245)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIInput.validateValue(UIInput.java:463)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UISelectOne.validateValue(UISelectOne.java:166)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> org.primefaces.component.selectonemenu.SelectOneMenu.validateValue(SelectOneMenu.java:197)
> ~[primefaces-13.0.7-jakarta.jar:13.0.7]
> at jakarta.faces.component.UIInput.validate(UIInput.java:717)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIInput.processValidators(UIInput.java:297)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UISelectOne.processValidators(UISelectOne.java:116)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1372)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIForm.processValidators(UIForm.java:200)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIViewRoot._processValidatorsDefault(UIViewRoot.java:1758)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIViewRoot$ProcessValidatorPhaseProcessor.process(UIViewRoot.java:1866)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIViewRoot._process(UIViewRoot.java:1714)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIViewRoot.processValidators(UIViewRoot.java:972)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:39)
> ~[myfaces-impl-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:172)
> [myfaces-impl-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:125)
> [myfaces-impl-4.0.2.jar:4.0.2]
> at jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:223)
> [myfaces-api-4.0.2.jar:4.0.2] {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4656) Component with overriden isRequired method does not evaluate plain string value
[
https://issues.apache.org/jira/browse/MYFACES-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827556#comment-17827556
]
Thomas Andraschko commented on MYFACES-4656:
a deeper research and PR would be welcome
i currently dont have much time for open source
> Component with overriden isRequired method does not evaluate plain string
> value
> ---
>
> Key: MYFACES-4656
> URL: https://issues.apache.org/jira/browse/MYFACES-4656
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: chaloma1
>Priority: Minor
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
> Attachments: primefaces-test-git.zip
>
>
> Component with overriden isRequired() method using "required" instead
> PropertyKeys.required string as in UIInput parent class (you can add default
> value here if attribute is not found or set). Works with #\{true} or
> #\{xxxController.isComponentRequired} {*}but not with plain string like
> "true"{*}.
> See ThirdComponent in attached example. You can execute the sample with mvn
> jetty:run -Pmyfaces40 command and hit [http://localhost:8080/primefaces-test]
> to run the page.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4656) Component with overriden isRequired method does not evaluate plain string value
[
https://issues.apache.org/jira/browse/MYFACES-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828441#comment-17828441
]
Thomas Andraschko commented on MYFACES-4656:
Added a unit test for it, which is currently disabled as it fails
> Component with overriden isRequired method does not evaluate plain string
> value
> ---
>
> Key: MYFACES-4656
> URL: https://issues.apache.org/jira/browse/MYFACES-4656
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: chaloma1
>Priority: Minor
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
> Attachments: primefaces-test-git.zip
>
>
> Component with overriden isRequired() method using "required" instead
> PropertyKeys.required string as in UIInput parent class (you can add default
> value here if attribute is not found or set). Works with #\{true} or
> #\{xxxController.isComponentRequired} {*}but not with plain string like
> "true"{*}.
> See ThirdComponent in attached example. You can execute the sample with mvn
> jetty:run -Pmyfaces40 command and hit [http://localhost:8080/primefaces-test]
> to run the page.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4656) Component with overriden isRequired method does not evaluate plain string value
[
https://issues.apache.org/jira/browse/MYFACES-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828445#comment-17828445
]
Thomas Andraschko commented on MYFACES-4656:
TBH i think your case is just invalid
the base setRequired uses the enum as key, your overwritten as string as key
this just cant match
if you add
```
@Override
public void setRequired(boolean required)
{
getStateHelper().put("required", required );
}
```
its working fine
> Component with overriden isRequired method does not evaluate plain string
> value
> ---
>
> Key: MYFACES-4656
> URL: https://issues.apache.org/jira/browse/MYFACES-4656
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: chaloma1
>Priority: Minor
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
> Attachments: primefaces-test-git.zip
>
>
> Component with overriden isRequired() method using "required" instead
> PropertyKeys.required string as in UIInput parent class (you can add default
> value here if attribute is not found or set). Works with #\{true} or
> #\{xxxController.isComponentRequired} {*}but not with plain string like
> "true"{*}.
> See ThirdComponent in attached example. You can execute the sample with mvn
> jetty:run -Pmyfaces40 command and hit [http://localhost:8080/primefaces-test]
> to run the page.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4656) Component with overriden isRequired method does not evaluate plain string value
[
https://issues.apache.org/jira/browse/MYFACES-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828445#comment-17828445
]
Thomas Andraschko edited comment on MYFACES-4656 at 3/19/24 4:52 PM:
-
TBH i think your case is just invalid
the base setRequired uses the enum as key, your overwritten as string as key
this just cant match
if you add
{code:java}
@Override
public void setRequired(boolean required)
{
getStateHelper().put("required", required );
}
{code}
its working fine
was (Author: tandraschko):
TBH i think your case is just invalid
the base setRequired uses the enum as key, your overwritten as string as key
this just cant match
if you add
```
@Override
public void setRequired(boolean required)
{
getStateHelper().put("required", required );
}
```
its working fine
> Component with overriden isRequired method does not evaluate plain string
> value
> ---
>
> Key: MYFACES-4656
> URL: https://issues.apache.org/jira/browse/MYFACES-4656
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: chaloma1
>Priority: Minor
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
> Attachments: primefaces-test-git.zip
>
>
> Component with overriden isRequired() method using "required" instead
> PropertyKeys.required string as in UIInput parent class (you can add default
> value here if attribute is not found or set). Works with #\{true} or
> #\{xxxController.isComponentRequired} {*}but not with plain string like
> "true"{*}.
> See ThirdComponent in attached example. You can execute the sample with mvn
> jetty:run -Pmyfaces40 command and hit [http://localhost:8080/primefaces-test]
> to run the page.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MYFACES-4656) Component with overriden isRequired method does not evaluate plain string value
[
https://issues.apache.org/jira/browse/MYFACES-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved MYFACES-4656.
Resolution: Invalid
> Component with overriden isRequired method does not evaluate plain string
> value
> ---
>
> Key: MYFACES-4656
> URL: https://issues.apache.org/jira/browse/MYFACES-4656
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: chaloma1
>Priority: Minor
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
> Attachments: primefaces-test-git.zip
>
>
> Component with overriden isRequired() method using "required" instead
> PropertyKeys.required string as in UIInput parent class (you can add default
> value here if attribute is not found or set). Works with #\{true} or
> #\{xxxController.isComponentRequired} {*}but not with plain string like
> "true"{*}.
> See ThirdComponent in attached example. You can execute the sample with mvn
> jetty:run -Pmyfaces40 command and hit [http://localhost:8080/primefaces-test]
> to run the page.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4656) Component with overriden isRequired method does not evaluate plain string value
[
https://issues.apache.org/jira/browse/MYFACES-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828445#comment-17828445
]
Thomas Andraschko edited comment on MYFACES-4656 at 3/19/24 4:53 PM:
-
TBH i think your case is just invalid
the base setRequired uses the enum as key, your overwritten getRequired a
string as key
this just cant match - getter and setter need to be in sync
if you add
{code:java}
@Override
public void setRequired(boolean required)
{
getStateHelper().put("required", required );
}
{code}
its working fine
was (Author: tandraschko):
TBH i think your case is just invalid
the base setRequired uses the enum as key, your overwritten as string as key
this just cant match
if you add
{code:java}
@Override
public void setRequired(boolean required)
{
getStateHelper().put("required", required );
}
{code}
its working fine
> Component with overriden isRequired method does not evaluate plain string
> value
> ---
>
> Key: MYFACES-4656
> URL: https://issues.apache.org/jira/browse/MYFACES-4656
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: chaloma1
>Priority: Minor
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
> Attachments: primefaces-test-git.zip
>
>
> Component with overriden isRequired() method using "required" instead
> PropertyKeys.required string as in UIInput parent class (you can add default
> value here if attribute is not found or set). Works with #\{true} or
> #\{xxxController.isComponentRequired} {*}but not with plain string like
> "true"{*}.
> See ThirdComponent in attached example. You can execute the sample with mvn
> jetty:run -Pmyfaces40 command and hit [http://localhost:8080/primefaces-test]
> to run the page.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MYFACES-4655) Cannot resolver managed FacesValidator with empty value
[
https://issues.apache.org/jira/browse/MYFACES-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved MYFACES-4655.
Resolution: Fixed
Thanks for the great contribution!
> Cannot resolver managed FacesValidator with empty value
> ---
>
> Key: MYFACES-4655
> URL: https://issues.apache.org/jira/browse/MYFACES-4655
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.2
> Environment: Eclipse Adoptium jdk-11.0.14.101-hotspot
> Apache Tomcat 10.1.2
> MyFaces 4.0.2
> Weld 4.0.3.Final
>Reporter: Nicola Isotta
>Priority: Major
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
> Attachments: primefaces-test.zip
>
>
> I'm moving one application from Mojarra to MyFaces.
> One of the page fails on submit because of a NullPointerException in
> FacesValidatorCDIWrapper.
> I'll try to arrange a standalone reproducer, meanwhile here's the stack trace:
> {code:java}
> java.lang.NullPointerException: null
> at
> org.apache.myfaces.cdi.wrapper.FacesValidatorCDIWrapper.validate(FacesValidatorCDIWrapper.java:59)
> ~[myfaces-impl-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.core.api.shared.ComponentUtils.callValidators(ComponentUtils.java:245)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIInput.validateValue(UIInput.java:463)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UISelectOne.validateValue(UISelectOne.java:166)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> org.primefaces.component.selectonemenu.SelectOneMenu.validateValue(SelectOneMenu.java:197)
> ~[primefaces-13.0.7-jakarta.jar:13.0.7]
> at jakarta.faces.component.UIInput.validate(UIInput.java:717)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIInput.processValidators(UIInput.java:297)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UISelectOne.processValidators(UISelectOne.java:116)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1372)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIForm.processValidators(UIForm.java:200)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1379)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIViewRoot._processValidatorsDefault(UIViewRoot.java:1758)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIViewRoot$ProcessValidatorPhaseProcessor.process(UIViewRoot.java:1866)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at jakarta.faces.component.UIViewRoot._process(UIViewRoot.java:1714)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> jakarta.faces.component.UIViewRoot.processValidators(UIViewRoot.java:972)
> ~[myfaces-api-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:39)
> ~[myfaces-impl-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:172)
> [myfaces-impl-4.0.2.jar:4.0.2]
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:125)
> [myfaces-impl-4.0.2.jar:4.0.2]
> at jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:223)
> [myfaces-api-4.0.2.jar:4.0.2] {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4659) Hidden field autocomplete="off" is not valid anymore
[ https://issues.apache.org/jira/browse/MYFACES-4659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834909#comment-17834909 ] Thomas Andraschko commented on MYFACES-4659: +1 > Hidden field autocomplete="off" is not valid anymore > > > Key: MYFACES-4659 > URL: https://issues.apache.org/jira/browse/MYFACES-4659 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Melloware >Priority: Minor > Fix For: 5.0.0, 4.1.0-RC2, 4.0.3 > > > See Mojarra Explanation: [https://github.com/eclipse-ee4j/mojarra/issues/5434] > > This was an old Firefox hack and I propose we inverse > "o.a.m.AUTOCOMPLETE_OFF_VIEW_STATE" value to not have the "autocomplete="off" > by default > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4660) WebSockets - view destroying + multiple tabs/windows
[ https://issues.apache.org/jira/browse/MYFACES-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836599#comment-17836599 ] Thomas Andraschko edited comment on MYFACES-4660 at 4/12/24 1:06 PM: - 1) +1, sounds good 2) sorry but i'm not enough into that code actually to give you good suggestions. However, a breaking change is not a problem IMO as 4.0+ is quite new and yeah its "public" but no official API. i would target 4.0, 4.1 and 5.0 which this change. was (Author: tandraschko): 1) +1, sounds good 2) sorry but i'm not enough into that code actually to give you good suggestions. However, a breaking change is not a problem IMO as 4.0+ is quite new and yeah its "public" but no official API. > WebSockets - view destroying + multiple tabs/windows > > > Key: MYFACES-4660 > URL: https://issues.apache.org/jira/browse/MYFACES-4660 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 5.0.0 >Reporter: Milan Siebenbürger >Priority: Minor > > Hello, > We have identified two (hopefully minor) bugs while using WebSockets. > 1. destroying SessionScope channelToken when destroying ViewScope bean > If the user reaches the NUMBER_OF_VIEWS_IN_SESSION limit, the ViewScope bean > (which holds channelTokens) is automatically destroyed (@PreDestroy). > Additionally, any channelToken from the parent sessionScope is destroyed, > even if it is still in use. Unfortunately, this destruction occurs after a > new view is created, so the component is rendered, the WebSocket session is > connected, but the channelToken in the WebsocketScopeManager is destroyed. > The solution to this issue could be simple. The destruction of the > sessionScope channelToken could be left to the automatic destruction of the > SessionScope. We have been testing this solution for several weeks, and it > seems to be working fine. > > 2. using application in multiple tabs / browser windows (with same http > session) > When a user is using the application in more than one tab/window within the > same HTTP session, the user session channels are duplicated (with the same > channelToken) and connected to the same user identification, resulting in two > or more WebSocket sessions. Push messages are then sent to all > tokens/sessions. So far, everything is working as expected. > However, when one of the views is destroyed (i.e., a tab/window is closed), > the connected WebSocket session is also destroyed (which is expected). > Unfortunately, this also will cause user connection to be removed . Since we > don't track how many times the user is using this particular channelToken, > the WebSocket connections in the other tabs/windows are also disrupted. > A potential solution to this issue could involve tracking the number of times > the user starts using the channelToken. We could then remove the user > connection after all instances of its usage are destroyed, or, alternatively, > when the SessionScope object is destroyed. > Unfortunately, implementing this solution would cause a breaking change. It > would involve replacing the Set holding channelTokens with a HashMap that > also keeps track of the number of usages (refer to > WebsocketSessionManager.java:62). Since the method getUserMap is public and > may be used by others (such as ourselves, for implementing WebSocket > heartbeat), they would need to update their code accordingly with the new > version of MyFaces. An alternative approach could be implemented using > another collection to hold the usage count of channelTokens. However, this > method may not be as elegant, although it would not necessitate users to > modify their applications. > So, the questions: > * which of these to implement? > * and to which version (5.0? or 4.X?) > > Of course, I will prepare the changes in the form of a pull request to check > the changes > > Milan -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4660) WebSockets - view destroying + multiple tabs/windows
[ https://issues.apache.org/jira/browse/MYFACES-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836599#comment-17836599 ] Thomas Andraschko commented on MYFACES-4660: 1) +1, sounds good 2) sorry but i'm not enough into that code actually to give you good suggestions. However, a breaking change is not a problem IMO as 4.0+ is quite new and yeah its "public" but no official API. > WebSockets - view destroying + multiple tabs/windows > > > Key: MYFACES-4660 > URL: https://issues.apache.org/jira/browse/MYFACES-4660 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 5.0.0 >Reporter: Milan Siebenbürger >Priority: Minor > > Hello, > We have identified two (hopefully minor) bugs while using WebSockets. > 1. destroying SessionScope channelToken when destroying ViewScope bean > If the user reaches the NUMBER_OF_VIEWS_IN_SESSION limit, the ViewScope bean > (which holds channelTokens) is automatically destroyed (@PreDestroy). > Additionally, any channelToken from the parent sessionScope is destroyed, > even if it is still in use. Unfortunately, this destruction occurs after a > new view is created, so the component is rendered, the WebSocket session is > connected, but the channelToken in the WebsocketScopeManager is destroyed. > The solution to this issue could be simple. The destruction of the > sessionScope channelToken could be left to the automatic destruction of the > SessionScope. We have been testing this solution for several weeks, and it > seems to be working fine. > > 2. using application in multiple tabs / browser windows (with same http > session) > When a user is using the application in more than one tab/window within the > same HTTP session, the user session channels are duplicated (with the same > channelToken) and connected to the same user identification, resulting in two > or more WebSocket sessions. Push messages are then sent to all > tokens/sessions. So far, everything is working as expected. > However, when one of the views is destroyed (i.e., a tab/window is closed), > the connected WebSocket session is also destroyed (which is expected). > Unfortunately, this also will cause user connection to be removed . Since we > don't track how many times the user is using this particular channelToken, > the WebSocket connections in the other tabs/windows are also disrupted. > A potential solution to this issue could involve tracking the number of times > the user starts using the channelToken. We could then remove the user > connection after all instances of its usage are destroyed, or, alternatively, > when the SessionScope object is destroyed. > Unfortunately, implementing this solution would cause a breaking change. It > would involve replacing the Set holding channelTokens with a HashMap that > also keeps track of the number of usages (refer to > WebsocketSessionManager.java:62). Since the method getUserMap is public and > may be used by others (such as ourselves, for implementing WebSocket > heartbeat), they would need to update their code accordingly with the new > version of MyFaces. An alternative approach could be implemented using > another collection to hold the usage count of channelTokens. However, this > method may not be as elegant, although it would not necessitate users to > modify their applications. > So, the questions: > * which of these to implement? > * and to which version (5.0? or 4.X?) > > Of course, I will prepare the changes in the form of a pull request to check > the changes > > Milan -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4659) Hidden field autocomplete="off" is not valid anymore
[ https://issues.apache.org/jira/browse/MYFACES-4659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836631#comment-17836631 ] Thomas Andraschko commented on MYFACES-4659: [~melloware]you need to set "fix versions" correctly > Hidden field autocomplete="off" is not valid anymore > > > Key: MYFACES-4659 > URL: https://issues.apache.org/jira/browse/MYFACES-4659 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Melloware >Priority: Minor > Fix For: 5.0.0, 4.1.0-RC2, 4.0.3 > > > See Mojarra Explanation: [https://github.com/eclipse-ee4j/mojarra/issues/5434] > > This was an old Firefox hack and I propose we inverse > "o.a.m.AUTOCOMPLETE_OFF_VIEW_STATE" value to not have the "autocomplete="off" > by default > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4661) SearchExpressions: Infinite Loop with SubView
[
https://issues.apache.org/jira/browse/MYFACES-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17837765#comment-17837765
]
Thomas Andraschko commented on MYFACES-4661:
is it the same with current 4.0 SNAPSHOT?
i think it should actually just fail with "not found exception" as ":subview1"
just doesnt exist, its ":form:subview1"
> SearchExpressions: Infinite Loop with SubView
> -
>
> Key: MYFACES-4661
> URL: https://issues.apache.org/jira/browse/MYFACES-4661
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.2, 4.1.0-RC1
>Reporter: Melloware
>Priority: Major
> Attachments: subview.zip
>
>
> Attached is reproducible example using only core JSF code.
> [^subview.zip]
>
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> ^The subview `render=":subview1:txtString"` gets stuck an infinite loop while
> `render="subview1:txtString"` works fine.^
> ^The request for the failed infinite loop...^
> {code:java}
> javax.faces.partial.render"j_id__v_0" {code}
> ^Running this same code with Mojarra 2.3 using `mvn clean jetty:run
> -Pmojarra23` the button works fine and the request looks like...^
> ^^
> {code:java}
> javax.faces.partial.render"frmTest:subview1:txtString" {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4661) SearchExpressions: Infinite Loop with SubView
[
https://issues.apache.org/jira/browse/MYFACES-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17837768#comment-17837768
]
Thomas Andraschko commented on MYFACES-4661:
reminds me of: https://issues.apache.org/jira/browse/MYFACES-4624
> SearchExpressions: Infinite Loop with SubView
> -
>
> Key: MYFACES-4661
> URL: https://issues.apache.org/jira/browse/MYFACES-4661
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.2, 4.1.0-RC1
>Reporter: Melloware
>Priority: Major
> Attachments: subview.zip
>
>
> Attached is reproducible example using only core JSF code.
> [^subview.zip]
>
> {code:java}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> ^The subview `render=":subview1:txtString"` gets stuck an infinite loop while
> `render="subview1:txtString"` works fine.^
> ^The request for the failed infinite loop...^
> {code:java}
> javax.faces.partial.render"j_id__v_0" {code}
> ^Running this same code with Mojarra 2.3 using `mvn clean jetty:run
> -Pmojarra23` the button works fine and the request looks like...^
> ^^
> {code:java}
> javax.faces.partial.render"frmTest:subview1:txtString" {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4666) ClassUtils.simpleClassForName Throws ClassNotFoundException
[
https://issues.apache.org/jira/browse/MYFACES-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844686#comment-17844686
]
Thomas Andraschko commented on MYFACES-4666:
You add declared a servlet in web.xml but its not loadable - why should we
ignore the exception?
> ClassUtils.simpleClassForName Throws ClassNotFoundException
> ---
>
> Key: MYFACES-4666
> URL: https://issues.apache.org/jira/browse/MYFACES-4666
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 4.1.0-RC1
>Reporter: Volodymyr Siedlecki
>Priority: Trivial
>
> We noticed a new exception in Faces 4.1:
> {code:java}
> jakarta.faces.FacesException: java.lang.ClassNotFoundException: XXX
> at
> org.apache.myfaces.util.lang.ClassUtils.simpleClassForName(ClassUtils.java:265)
> at
> org.apache.myfaces.application.FacesServletMappingUtils.isFacesServlet(FacesServletMappingUtils.java:177)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.checkForFacesServlet(MyFacesContainerInitializer.java:330)
> at
> org.apache.myfaces.webapp.MyFacesContainerInitializer.onStartup(MyFacesContainerInitializer.java:143){code}
> This did not occur in 4.0. It only introduced with this change:
> [https://github.com/apache/myfaces/commit/e7d8521ee9214ff1dce24ed6fc2b8627e6461213#diff-67a433d1677376ea6270fd619b75ff47cb51a57f6ca067aef0077ff202c4eacdR177]
> true is now passed into simpleClassForName which throws the exception:
> [https://github.com/apache/myfaces/blob/2fa694a96f8c734a15ab4a46ad87ac52b1101b2a/impl/src/main/java/org/apache/myfaces/util/lang/ClassUtils.java#L253]
> Was this intentional for any specific scenario? Is an exception appropriate
> here? We didn't have this before, so I'm wondering if this is needed in 4.1?
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4667) UIData#invokeOnComponent does not find components
[
https://issues.apache.org/jira/browse/MYFACES-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848207#comment-17848207
]
Thomas Andraschko commented on MYFACES-4667:
isnt it? https://github.com/jakartaee/faces/issues/1905
> UIData#invokeOnComponent does not find components
> -
>
> Key: MYFACES-4667
> URL: https://issues.apache.org/jira/browse/MYFACES-4667
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3.10
>Reporter: SteGr
>Priority: Major
>
> While working an a bug in [mojarra implementation|#issuecomment-2115154280]]
> I found an [old primefaces
> issue|https://github.com/primefaces/primefaces/issues/9245#issuecomment-2122507698]
> which was somehow related to my issue. Using the reproducer of that PF
> issue, I was able to really find the root cause of the issue and that even
> myfaces is affected - contrary to what was assumed at the time.
>
> *What happens?*
> A {{p:datatable}} with {{p:column*s*}} was updated by the backend using
> {{{}PrimeFaces#Ajax#update{}}}. The implementation used
> {{UIComponent#invokeOnComponent}} to find the component of the given
> clientId. As {{p:dataTable}} relies on {{UIData}} of myfaces, {{p:columns}}
> won't be handled. Nothing could be found and {{PrimeFaces#Ajax#update}} falls
> back to just forwarding the given clientId.
> *Why does it happen?*
> Like mojarra, myfaces filters the children on processing using {{{}instanceof
> UIColumn{}}}. But {{p:columns}} does not extend that class. Therefore
> {{p:columns}} is not a candiate and is simply ignored.
> *Possible fix* (not yet tested)
> Remove the check.
> *How to reproduce*
> Use the [reproducer
> |https://github.com/primefaces/primefaces/files/9664695/primefaces-test.zip]
> and change the PROJECT_STAGE to Development. Run the project using the
> myfaces23 profile. You should get a lot of logging entries like
> {quote}Mai 21, 2024 2:53:41 PM org.primefaces.PrimeFaces$Ajax update
> WARNUNG: PrimeFaces.current().ajax().update() called but component cant be
> resolved! Expression will just be added to the renderIds: \{0}
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4677) Security Vulnerability CVE-2023-24998 FileUpload
[ https://issues.apache.org/jira/browse/MYFACES-4677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871737#comment-17871737 ] Thomas Andraschko commented on MYFACES-4677: Yeah Tomahawk is not active anymore since many years, sorry > Security Vulnerability CVE-2023-24998 FileUpload > > > Key: MYFACES-4677 > URL: https://issues.apache.org/jira/browse/MYFACES-4677 > Project: MyFaces Core > Issue Type: Improvement > Components: build process >Reporter: Himanshu Gupta >Priority: Critical > Original Estimate: 504h > Remaining Estimate: 504h > > Upgrade to FileUpload 1.5 and provide a way to set > FileUploadBase#setFileCountMax to a value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4677) Security Vulnerability CVE-2023-24998 FileUpload
[ https://issues.apache.org/jira/browse/MYFACES-4677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-4677. Resolution: Invalid Also wrong jira project > Security Vulnerability CVE-2023-24998 FileUpload > > > Key: MYFACES-4677 > URL: https://issues.apache.org/jira/browse/MYFACES-4677 > Project: MyFaces Core > Issue Type: Improvement > Components: build process >Reporter: Himanshu Gupta >Priority: Critical > Original Estimate: 504h > Remaining Estimate: 504h > > Upgrade to FileUpload 1.5 and provide a way to set > FileUploadBase#setFileCountMax to a value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4677) Security Vulnerability Apache commons-fileupload
[ https://issues.apache.org/jira/browse/MYFACES-4677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871792#comment-17871792 ] Thomas Andraschko commented on MYFACES-4677: As i already said, Tomahawk is dead since many years I suggest migrate to primefacea > Security Vulnerability Apache commons-fileupload > - > > Key: MYFACES-4677 > URL: https://issues.apache.org/jira/browse/MYFACES-4677 > Project: MyFaces Core > Issue Type: Improvement > Components: build process >Reporter: Himanshu Gupta >Priority: Critical > Original Estimate: 504h > Remaining Estimate: 504h > > Apache Commons FileUpload before 1.5 does not limit the number of request > parts to be processed resulting in the possibility of an attacker triggering > a DoS with a malicious upload or series of uploads. Note that, like all of > the file upload limits, the new configuration option > (FileUploadBase#setFileCountMax) is not enabled by default and must be > explicitly configured. : [https://nvd.nist.gov/vuln/detail/CVE-2023-24998] > Upgrade to FileUpload 1.5 and provide a way to set > FileUploadBase#setFileCountMax to a value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4677) Security Vulnerability Apache commons-fileupload
[ https://issues.apache.org/jira/browse/MYFACES-4677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871792#comment-17871792 ] Thomas Andraschko edited comment on MYFACES-4677 at 8/7/24 9:35 PM: As i already said, Tomahawk is dead since many years I suggest migrate to primefaces was (Author: tandraschko): As i already said, Tomahawk is dead since many years I suggest migrate to primefacea > Security Vulnerability Apache commons-fileupload > - > > Key: MYFACES-4677 > URL: https://issues.apache.org/jira/browse/MYFACES-4677 > Project: MyFaces Core > Issue Type: Improvement > Components: build process >Reporter: Himanshu Gupta >Priority: Critical > Original Estimate: 504h > Remaining Estimate: 504h > > Apache Commons FileUpload before 1.5 does not limit the number of request > parts to be processed resulting in the possibility of an attacker triggering > a DoS with a malicious upload or series of uploads. Note that, like all of > the file upload limits, the new configuration option > (FileUploadBase#setFileCountMax) is not enabled by default and must be > explicitly configured. : [https://nvd.nist.gov/vuln/detail/CVE-2023-24998] > Upgrade to FileUpload 1.5 and provide a way to set > FileUploadBase#setFileCountMax to a value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4678) Getting NPE FaceletStateValueExpression.getWrapped(jakarta.el.ELContext)
[
https://issues.apache.org/jira/browse/MYFACES-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17874864#comment-17874864
]
Thomas Andraschko commented on MYFACES-4678:
We need a reproducer, i cant help otherwise
> Getting NPE FaceletStateValueExpression.getWrapped(jakarta.el.ELContext)
>
>
> Key: MYFACES-4678
> URL: https://issues.apache.org/jira/browse/MYFACES-4678
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
> Environment: Tomcat 10.1, MyFaces 4.0.2, Weld 5.1.2, Primefaces 14.0.4
>Reporter: Robin Jansohn
>Priority: Major
>
> Getting a weird NPE when switching dialogs but only if I am in
> jakarta.faces.PROJECT_STAGE=Production. In Development everything works. I'll
> try to create a reproducer, for now I'll just attach the stacktrace. Maybe
> someone can already give some insights why this might be happening.
> {noformat}
> SEVERE: Cannot invoke
> "jakarta.el.ValueExpression.getValue(jakarta.el.ELContext)" because the
> return value of
> "org.apache.myfaces.view.facelets.el.FaceletStateValueExpression.getWrapped(jakarta.el.ELContext)"
> is null
> java.lang.NullPointerException: Cannot invoke
> "jakarta.el.ValueExpression.getValue(jakarta.el.ELContext)" because the
> return value of
> "org.apache.myfaces.view.facelets.el.FaceletStateValueExpression.getWrapped(jakarta.el.ELContext)"
> is null
> at
> org.apache.myfaces.view.facelets.el.FaceletStateValueExpression.getValue(FaceletStateValueExpression.java:114)
> at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:74)
> at org.apache.el.parser.AstEqual.getValue(AstEqual.java:37)
> at
> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:170)
> at
> org.jboss.weld.module.web.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
> at
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:100)
> at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:74)
> at org.apache.el.parser.AstOr.getValue(AstOr.java:37)
> at org.apache.el.parser.AstOr.getValue(AstOr.java:37)
> at
> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:170)
> at
> org.jboss.weld.module.web.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
> at
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:100)
> at
> org.apache.myfaces.view.facelets.tag.TagAttributeImpl.getObject(TagAttributeImpl.java:462)
> at
> org.apache.myfaces.view.facelets.tag.TagAttributeImpl.getBoolean(TagAttributeImpl.java:138)
> at
> org.apache.myfaces.view.facelets.tag.jstl.core.IfHandler.apply(IfHandler.java:111)
> at
> jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:57)
> at
> org.apache.myfaces.view.facelets.tag.faces.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:362)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:52)
> at
> jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:57)
> at
> org.apache.myfaces.view.facelets.tag.faces.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:362)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:52)
> at
> jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:57)
> at
> org.apache.myfaces.view.facelets.tag.faces.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:362)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:52)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:57)
> at
> org.apache.myfaces.view.facelets.tag.faces.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:362)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:52)
> at
> jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
> at
> org.apache.myfaces.view.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:147)
> at
> org.apache.
[jira] [Resolved] (MYFACES-4675) Faces #1936: resetValues() visit clientIds if not EditableValueHolder
[ https://issues.apache.org/jira/browse/MYFACES-4675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-4675. Resolution: Fixed > Faces #1936: resetValues() visit clientIds if not EditableValueHolder > - > > Key: MYFACES-4675 > URL: https://issues.apache.org/jira/browse/MYFACES-4675 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.2, 4.1.0-RC2 >Reporter: Melloware >Assignee: Melloware >Priority: Major > Fix For: 5.0.0, 4.0.3, 4.1.0-RC3 > > > See Faces issue: https://github.com/jakartaee/faces/issues/1936 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4678) Getting NPE FaceletStateValueExpression.getWrapped(jakarta.el.ELContext)
[
https://issues.apache.org/jira/browse/MYFACES-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877375#comment-17877375
]
Thomas Andraschko commented on MYFACES-4678:
[~melloware] could you try to find the breaking version / commit?
> Getting NPE FaceletStateValueExpression.getWrapped(jakarta.el.ELContext)
>
>
> Key: MYFACES-4678
> URL: https://issues.apache.org/jira/browse/MYFACES-4678
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
> Environment: Tomcat 10.1, MyFaces 4.0.2, Weld 5.1.2, Primefaces 14.0.4
>Reporter: Robin Jansohn
>Priority: Major
> Attachments: myfaces-4678.zip, myfaces-bug.zip
>
>
> Getting a weird NPE when switching dialogs but only if I am in
> jakarta.faces.PROJECT_STAGE=Production. In Development everything works. I'll
> try to create a reproducer, for now I'll just attach the stacktrace. Maybe
> someone can already give some insights why this might be happening.
> {noformat}
> SEVERE: Cannot invoke
> "jakarta.el.ValueExpression.getValue(jakarta.el.ELContext)" because the
> return value of
> "org.apache.myfaces.view.facelets.el.FaceletStateValueExpression.getWrapped(jakarta.el.ELContext)"
> is null
> java.lang.NullPointerException: Cannot invoke
> "jakarta.el.ValueExpression.getValue(jakarta.el.ELContext)" because the
> return value of
> "org.apache.myfaces.view.facelets.el.FaceletStateValueExpression.getWrapped(jakarta.el.ELContext)"
> is null
> at
> org.apache.myfaces.view.facelets.el.FaceletStateValueExpression.getValue(FaceletStateValueExpression.java:114)
> at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:74)
> at org.apache.el.parser.AstEqual.getValue(AstEqual.java:37)
> at
> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:170)
> at
> org.jboss.weld.module.web.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
> at
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:100)
> at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:74)
> at org.apache.el.parser.AstOr.getValue(AstOr.java:37)
> at org.apache.el.parser.AstOr.getValue(AstOr.java:37)
> at
> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:170)
> at
> org.jboss.weld.module.web.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
> at
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:100)
> at
> org.apache.myfaces.view.facelets.tag.TagAttributeImpl.getObject(TagAttributeImpl.java:462)
> at
> org.apache.myfaces.view.facelets.tag.TagAttributeImpl.getBoolean(TagAttributeImpl.java:138)
> at
> org.apache.myfaces.view.facelets.tag.jstl.core.IfHandler.apply(IfHandler.java:111)
> at
> jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:57)
> at
> org.apache.myfaces.view.facelets.tag.faces.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:362)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:52)
> at
> jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:57)
> at
> org.apache.myfaces.view.facelets.tag.faces.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:362)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:52)
> at
> jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:57)
> at
> org.apache.myfaces.view.facelets.tag.faces.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:362)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:52)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:57)
> at
> org.apache.myfaces.view.facelets.tag.faces.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:362)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:52)
> at
> jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
> at
> org.apache.myfaces.view.facelets.tag.u
[jira] [Commented] (MYFACES-4678) Getting NPE FaceletStateValueExpression.getWrapped(jakarta.el.ELContext)
[
https://issues.apache.org/jira/browse/MYFACES-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877379#comment-17877379
]
Thomas Andraschko commented on MYFACES-4678:
if its just the default mode difference, we could maybe just revert it
i thought i do something good :D
> Getting NPE FaceletStateValueExpression.getWrapped(jakarta.el.ELContext)
>
>
> Key: MYFACES-4678
> URL: https://issues.apache.org/jira/browse/MYFACES-4678
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
> Environment: Tomcat 10.1, MyFaces 4.0.2, Weld 5.1.2, Primefaces 14.0.4
>Reporter: Robin Jansohn
>Priority: Major
> Attachments: myfaces-4678.zip, myfaces-bug.zip
>
>
> Getting a weird NPE when switching dialogs but only if I am in
> jakarta.faces.PROJECT_STAGE=Production. In Development everything works. I'll
> try to create a reproducer, for now I'll just attach the stacktrace. Maybe
> someone can already give some insights why this might be happening.
> {noformat}
> SEVERE: Cannot invoke
> "jakarta.el.ValueExpression.getValue(jakarta.el.ELContext)" because the
> return value of
> "org.apache.myfaces.view.facelets.el.FaceletStateValueExpression.getWrapped(jakarta.el.ELContext)"
> is null
> java.lang.NullPointerException: Cannot invoke
> "jakarta.el.ValueExpression.getValue(jakarta.el.ELContext)" because the
> return value of
> "org.apache.myfaces.view.facelets.el.FaceletStateValueExpression.getWrapped(jakarta.el.ELContext)"
> is null
> at
> org.apache.myfaces.view.facelets.el.FaceletStateValueExpression.getValue(FaceletStateValueExpression.java:114)
> at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:74)
> at org.apache.el.parser.AstEqual.getValue(AstEqual.java:37)
> at
> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:170)
> at
> org.jboss.weld.module.web.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
> at
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:100)
> at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:74)
> at org.apache.el.parser.AstOr.getValue(AstOr.java:37)
> at org.apache.el.parser.AstOr.getValue(AstOr.java:37)
> at
> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:170)
> at
> org.jboss.weld.module.web.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
> at
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:100)
> at
> org.apache.myfaces.view.facelets.tag.TagAttributeImpl.getObject(TagAttributeImpl.java:462)
> at
> org.apache.myfaces.view.facelets.tag.TagAttributeImpl.getBoolean(TagAttributeImpl.java:138)
> at
> org.apache.myfaces.view.facelets.tag.jstl.core.IfHandler.apply(IfHandler.java:111)
> at
> jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:57)
> at
> org.apache.myfaces.view.facelets.tag.faces.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:362)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:52)
> at
> jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:57)
> at
> org.apache.myfaces.view.facelets.tag.faces.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:362)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:52)
> at
> jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:57)
> at
> org.apache.myfaces.view.facelets.tag.faces.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:362)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:52)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:57)
> at
> org.apache.myfaces.view.facelets.tag.faces.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:362)
> at
> jakarta.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:52)
> at
> jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
> at
>
[jira] [Commented] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[
https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877729#comment-17877729
]
Thomas Andraschko commented on MYFACES-4679:
AFAIR Mojarra behaves like this:
onBlur both listener & actionListener is called, only 1 ajax request is done.
so the question is more a spec question:
{code:xml}
{code}
should it invoke the action or not onBlur?
> MYFACES-4606 Causes Multiple Events To Queue
>
>
> Key: MYFACES-4679
> URL: https://issues.apache.org/jira/browse/MYFACES-4679
> Project: MyFaces Core
> Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: MYFACES-4679.zip
>
>
> Easier to demonstrate via the attached app (note that ajax tags have a blur
> event).
> 1) Deploy application with MYFACES-4606 applied.
> 2) Visit index.xhtml
> 3) Click down on the first button (don't let go)
> 4 Move the cursor elsewhere and then let the click go.
> 5) Click anywhere on the page to trigger the blur event (unfocus the button).
> 6) Repeat with the second button
> With the second button, both the listener and confirm actions to occur. Even
> though, the button wasn't actually clicked.
> In my view, only the listener event should occur, not the confirm actions.
> However, by adding the issuing element to the request, JSF thinks the button
> was clicked after all.
> In summary:
> Before 4606:
> Button 1:
> nothing called
> Button 2:
> listener called
> With 4606:
> Button 1:
> confirm called
> Button 2:
> listener called
> confirm called
> The activate action check is here:
> [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65]
> The "isSubmitted" method return true for paramMap.containsKey(clientId) which
> is what the 4606 fix did (add the client id).
> *This there a way to keep the older behavior for this scenario (pre-4606)?*
> Additionally, I've seen the multiple invocations for the listener / confirm,
> but I can't pin point the problem (could be some other button click
> combination).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4679) MYFACES-4606 Causes Multiple Events To Queue
[
https://issues.apache.org/jira/browse/MYFACES-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877729#comment-17877729
]
Thomas Andraschko edited comment on MYFACES-4679 at 8/29/24 2:36 PM:
-
AFAIR Mojarra behaves like this:
onBlur both listener & actionListener is called, only 1 ajax request is done.
so the question is more a spec question:
{code:xml}
{code}
should it invoke the action or not onBlur?
As far as i understand you: 2.3.10 does NOT invoke the action, 2.3.11 does.
was (Author: tandraschko):
AFAIR Mojarra behaves like this:
onBlur both listener & actionListener is called, only 1 ajax request is done.
so the question is more a spec question:
{code:xml}
{code}
should it invoke the action or not onBlur?
> MYFACES-4606 Causes Multiple Events To Queue
>
>
> Key: MYFACES-4679
> URL: https://issues.apache.org/jira/browse/MYFACES-4679
> Project: MyFaces Core
> Issue Type: Bug
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: MYFACES-4679.zip
>
>
> Easier to demonstrate via the attached app (note that ajax tags have a blur
> event).
> 1) Deploy application with MYFACES-4606 applied.
> 2) Visit index.xhtml
> 3) Click down on the first button (don't let go)
> 4 Move the cursor elsewhere and then let the click go.
> 5) Click anywhere on the page to trigger the blur event (unfocus the button).
> 6) Repeat with the second button
> With the second button, both the listener and confirm actions to occur. Even
> though, the button wasn't actually clicked.
> In my view, only the listener event should occur, not the confirm actions.
> However, by adding the issuing element to the request, JSF thinks the button
> was clicked after all.
> In summary:
> Before 4606:
> Button 1:
> nothing called
> Button 2:
> listener called
> With 4606:
> Button 1:
> confirm called
> Button 2:
> listener called
> confirm called
> The activate action check is here:
> [https://github.com/apache/myfaces/blob/2.3.x/shared/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java#L65]
> The "isSubmitted" method return true for paramMap.containsKey(clientId) which
> is what the 4606 fix did (add the client id).
> *This there a way to keep the older behavior for this scenario (pre-4606)?*
> Additionally, I've seen the multiple invocations for the listener / confirm,
> but I can't pin point the problem (could be some other button click
> combination).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[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;
---
--
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-tabpanel&focusedCommentId=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;
> ---
>
> id="selectLocaleMenu"
> value="#{localeController.selectedLocale}"
> onchange="this.form.submit()"
> converter="localeConverter">
> value="#{allLocalesController.locales}"
> var="locale"
> itemLabel="#{locale.name}"
> itemValue="#{locale}"/>
>
>
--
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-tabpanel&focusedCommentId=13049384#comment-13049384 ] Thomas Andraschko commented on EXTCDI-118: -- Did anyone created a ticket in jboss jira for this issue or is there a workaround available? I can not get any information on this issue which is very weird because it is not possible to use simple @ViewScoped bean... > 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] [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-tabpanel&focusedCommentId=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] (EXTCDI-296) Allow errorView navigation in all cases
Thomas Andraschko created EXTCDI-296: Summary: Allow errorView navigation in all cases Key: EXTCDI-296 URL: https://issues.apache.org/jira/browse/EXTCDI-296 Project: MyFaces CODI Issue Type: Improvement Components: JEE-JSF20-Module Affects Versions: 1.0.5 Reporter: Thomas Andraschko We cache some of our pages and therefore sometimes the error page will be cached instead the original page. It should be possible to always allow navigation via redirect to the ErrorPage. A new config option should be added. See: SecurityUtils#processApplicationSecurityException -- 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-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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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 org.apache.myfaces.view.fac
[jira] [Commented] (MYFACES-3605) Expression ClassCastException
[ https://issues.apache.org/jira/browse/MYFACES-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 >
[jira] [Commented] (MYFACES-3655) add pluggable Serialization strategies
[ https://issues.apache.org/jira/browse/MYFACES-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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:
>
> appManagerBean
>
> com.ibm.ws.jsf.beans.AppManagerBean
> application
>
>
>
> emailBean
>
> com.ibm.ws.jsf.beans.EmailBean
> session
>
>
> viewScopedBean
>
> com.ibm.ws.jsf.beans.ViewScopedManagedBean
> view
>
>
> emailBean
> #{emailBean}
>
>
> appManagerBean
> #{appManagerBean}
>
>
>
> 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
> ://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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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 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-tabpanel&focusedCommentId=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 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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. > >javax.faces.CLIENT_WINDOW_MODE >url > > > 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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:
javax.servlet
javax.servlet-api
3.1.0
?
> 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] [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-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] [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] [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] [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-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] [Commented] (MYFACES-4014) Log required startup time
[ https://issues.apache.org/jira/browse/MYFACES-4014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [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] [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] [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&focusedCommentId=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: --- 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&focusedCommentId=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] [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-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&focusedCommentId=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] [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&focusedCommentId=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&focusedCommentId=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] [Commented] (MYFACES-3803) Success messages (FacesMessage)
[
https://issues.apache.org/jira/browse/MYFACES-3803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-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&focusedCommentId=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-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&focusedCommentId=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&focusedCommentId=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)
