[jira] [Created] (MYFACES-4085) Constants for "jsf.js", "javax.faces" and postback parameters

[Thomas Andraschko (JIRA)]

Thomas Andraschko created MYFACES-4085:
--

 Summary: Constants for "jsf.js", "javax.faces" and postback 
parameters
 Key: MYFACES-4085
 URL: https://issues.apache.org/jira/browse/MYFACES-4085
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-372
Reporter: Thomas Andraschko
Assignee: Thomas Andraschko


http://arjan-tijms.omnifaces.org/p/jsf-23.html#1428



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4086) Deprecate native managed beans annotations

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859443#comment-15859443
 ] 

Thomas Andraschko commented on MYFACES-4086:


Done

> Deprecate native managed beans annotations
> --
>
> Key: MYFACES-4086
> URL: https://issues.apache.org/jira/browse/MYFACES-4086
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4075) SearchExpression API

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859444#comment-15859444
 ] 

Thomas Andraschko commented on MYFACES-4075:


Done

> SearchExpression API
> 
>
> Key: MYFACES-4075
> URL: https://issues.apache.org/jira/browse/MYFACES-4075
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
>
> There is a proposal from PrimeFaces guys to include a search expression api 
> to locate components in cases like f:ajax execute/render attributes, 
> h:message for attribute and others.
> The idea comes from here:
> http://blog.primefaces.org/?p=2740
> The idea is support a syntax like this in the attributes:
> 
> :
> ::
> @:
> id:@
> @()
> @(,)
> There is a patch for this I have been working over the last weeks, but still 
> require more tests and update the components in MyFaces Core 2.3 to use the 
> new API.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4088) Add constructor with facesContext to event classes

[Thomas Andraschko (JIRA)]

Thomas Andraschko created MYFACES-4088:
--

 Summary: Add constructor with facesContext to event classes
 Key: MYFACES-4088
 URL: https://issues.apache.org/jira/browse/MYFACES-4088
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-372
Reporter: Thomas Andraschko
Assignee: Thomas Andraschko






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4087) Add PostRenderViewEvent

[Thomas Andraschko (JIRA)]

Thomas Andraschko created MYFACES-4087:
--

 Summary: Add PostRenderViewEvent
 Key: MYFACES-4087
 URL: https://issues.apache.org/jira/browse/MYFACES-4087
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-372
Reporter: Thomas Andraschko
Assignee: Thomas Andraschko


http://arjan-tijms.omnifaces.org/p/jsf-23.html#1135



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4089) Add Iterable support in UIData and UIRepeat

[Thomas Andraschko (JIRA)]

Thomas Andraschko created MYFACES-4089:
--

 Summary: Add Iterable support in UIData and UIRepeat
 Key: MYFACES-4089
 URL: https://issues.apache.org/jira/browse/MYFACES-4089
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-372
Reporter: Thomas Andraschko






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4090) Add Map support in UIData and UIRepeat

[Thomas Andraschko (JIRA)]

Thomas Andraschko created MYFACES-4090:
--

 Summary: Add Map support in UIData and UIRepeat
 Key: MYFACES-4090
 URL: https://issues.apache.org/jira/browse/MYFACES-4090
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-372
Reporter: Thomas Andraschko






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4091) Add custom type support in UIData and UIRepeat

[Thomas Andraschko (JIRA)]

Thomas Andraschko created MYFACES-4091:
--

 Summary: Add custom type support in UIData and UIRepeat
 Key: MYFACES-4091
 URL: https://issues.apache.org/jira/browse/MYFACES-4091
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-372
Reporter: Thomas Andraschko






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4086) Deprecate native managed beans annotations

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko resolved MYFACES-4086.

   Resolution: Fixed
Fix Version/s: 2.3.0

> Deprecate native managed beans annotations
> --
>
> Key: MYFACES-4086
> URL: https://issues.apache.org/jira/browse/MYFACES-4086
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
> Fix For: 2.3.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4087) Add PostRenderViewEvent

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko resolved MYFACES-4087.

Resolution: Fixed

> Add PostRenderViewEvent
> ---
>
> Key: MYFACES-4087
> URL: https://issues.apache.org/jira/browse/MYFACES-4087
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
> Fix For: 2.3.0
>
>
> http://arjan-tijms.omnifaces.org/p/jsf-23.html#1135



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4085) Constants for "jsf.js", "javax.faces" and postback parameters

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko resolved MYFACES-4085.

   Resolution: Fixed
Fix Version/s: 2.3.0

> Constants for "jsf.js", "javax.faces" and postback parameters
> -
>
> Key: MYFACES-4085
> URL: https://issues.apache.org/jira/browse/MYFACES-4085
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
> Fix For: 2.3.0
>
>
> http://arjan-tijms.omnifaces.org/p/jsf-23.html#1428



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4075) SearchExpression API

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko resolved MYFACES-4075.

   Resolution: Fixed
Fix Version/s: 2.3.0

> SearchExpression API
> 
>
> Key: MYFACES-4075
> URL: https://issues.apache.org/jira/browse/MYFACES-4075
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> There is a proposal from PrimeFaces guys to include a search expression api 
> to locate components in cases like f:ajax execute/render attributes, 
> h:message for attribute and others.
> The idea comes from here:
> http://blog.primefaces.org/?p=2740
> The idea is support a syntax like this in the attributes:
> 
> :
> ::
> @:
> id:@
> @()
> @(,)
> There is a patch for this I have been working over the last weeks, but still 
> require more tests and update the components in MyFaces Core 2.3 to use the 
> new API.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4077) GRAVE - Exception loading sessions from persistent storage

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15691343#comment-15691343
 ] 

Thomas Andraschko commented on MYFACES-4077:


Please provide a description, exception, logfile or example.
Does it work with older 2.2.x versions?

> GRAVE - Exception loading sessions from persistent storage
> --
>
> Key: MYFACES-4077
> URL: https://issues.apache.org/jira/browse/MYFACES-4077
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.2.11
> Environment: GRAVE - Exception loading sessions from persistent 
> storage 
>Reporter: Joanna Ochoa
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MYFACES-4076) ajax event listeners not called

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682942#comment-15682942
 ] 

Thomas Andraschko commented on MYFACES-4076:


Should be the duplicate of: https://issues.apache.org/jira/browse/MYFACES-4068

> ajax event listeners not called
> ---
>
> Key: MYFACES-4076
> URL: https://issues.apache.org/jira/browse/MYFACES-4076
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Romain Manni-Bucau
>
> Issue inherited from TOMEE-1973



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MYFACES-4133) Don't deserialize the client provided ViewState if the state saving method is server

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127468#comment-16127468
 ] 

Thomas Andraschko commented on MYFACES-4133:


Did you debugged this?
AFAIR only a view-state-id is sent to the client but serialization still happen 
if org.apache.myfaces.SERIALIZE_STATE_IN_SESSION is set (default is true).

> Don't deserialize the client provided ViewState if the state saving method is 
> server
> 
>
> Key: MYFACES-4133
> URL: https://issues.apache.org/jira/browse/MYFACES-4133
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.2.12
>Reporter: Peter Stöckli
>
> Currently the ViewState provided by the user is deserialized via Java 
> deserialization even when the {{javax.faces.STATE_SAVING_METHOD}} is set to 
> {{server}} (the default).
> The deserialization in this case is unecessary and most likely even slower 
> than just sending the ViewState Id directly.
> If a developer now disables the ViewState encryption by setting 
> {{org.apache.myfaces.USE_ENCRYPTION}} to {{false}} (against the [MyFaces 
> security advice|https://wiki.apache.org/myfaces/Secure_Your_Application]) he 
> might have unintentionally introduced a dangerous remote code execution (RCE) 
> vulnerability as described 
> [here|https://www.alphabot.com/security/blog/2017/java/Misconfigured-JSF-ViewStates-can-lead-to-severe-RCE-vulnerabilities.html].
> This has been discussed before on [Issue 
> MYFACES-4021|https://issues.apache.org/jira/browse/MYFACES-4021].



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4133) Don't deserialize the ViewState-ID if the state saving method is server

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128488#comment-16128488
 ] 

Thomas Andraschko commented on MYFACES-4133:


I see - now i understand your problem (also renamed the title).
[~lu4242] WDYT about this one? Why do we serialize the id? It's really not 
required.

> Don't deserialize the ViewState-ID if the state saving method is server
> ---
>
> Key: MYFACES-4133
> URL: https://issues.apache.org/jira/browse/MYFACES-4133
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.2.12
>Reporter: Peter Stöckli
>
> Currently the ViewState-ID provided by the user is deserialized via Java 
> deserialization even when the {{javax.faces.STATE_SAVING_METHOD}} is set to 
> {{server}} (the default).
> The deserialization in this case is unecessary and most likely even slower 
> than just sending the ViewState Id directly.
> If a developer now disables the ViewState encryption by setting 
> {{org.apache.myfaces.USE_ENCRYPTION}} to {{false}} (against the [MyFaces 
> security advice|https://wiki.apache.org/myfaces/Secure_Your_Application]) he 
> might have unintentionally introduced a dangerous remote code execution (RCE) 
> vulnerability as described 
> [here|https://www.alphabot.com/security/blog/2017/java/Misconfigured-JSF-ViewStates-can-lead-to-severe-RCE-vulnerabilities.html].
> This has been discussed before on [Issue 
> MYFACES-4021|https://issues.apache.org/jira/browse/MYFACES-4021].



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYFACES-3350) Error data payload attribute names

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko updated MYFACES-3350:
---
Resolution: Fixed
  Assignee: Thomas Andraschko
Status: Resolved  (was: Patch Available)

Applied it (for now) just in 2.3.0 

> Error data payload attribute names
> --
>
> Key: MYFACES-3350
> URL: https://issues.apache.org/jira/browse/MYFACES-3350
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-314
>Affects Versions: 2.0.9, 2.1.3
>Reporter: Keith Wong
>Assignee: Thomas Andraschko
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: Impl.js, jsf.js, MYFACES-3350-1.patch
>
>
> According to JSF 2.0 and 2.1 spec section 14.4.2 table 14-6, the attributes 
> of error data payload are:
>   type
>   status
>   description
>   source
>   responseCode
>   responseXML
>   responseText
>   errorName
>   errorMessage
> However, the attributes errorName and errorMessage are named as 
> serverErrorName and serverErrorMessage respectively.  I have identified the 
> changes and attached as follows.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (MYFACES-3147) message of ViewExpiredException

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko resolved MYFACES-3147.

Resolution: Fixed

Improved the message but i think we must not translate it as it's just a 
internal exception which should never be read by a enduser.

> message of ViewExpiredException
> ---
>
> Key: MYFACES-3147
> URL: https://issues.apache.org/jira/browse/MYFACES-3147
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-314
>Affects Versions: 2.0.5
>Reporter: Gerhard Petracek
>Assignee: Leonardo Uribe
>Priority: Minor
> Fix For: 2.3.0
>
>
> #1 the message isn't internationalized
> the message is hardcoded:
> throw new ViewExpiredException("No saved view state could be found for the 
> view identifier: " + viewId, viewId)
> #2 the message doesn't make a lot of sense
> #2.1 #getMessage concatenate two strings without a blank
> #2.2 the original message text gets concatenated with the view-id and 
> #getMessage adds the view-id again to the beginning of the message.
> this results in a message which isn't very useful - e.g.:
> /page.xhtmlNo saved view state could be found for the view identifier: 
> /page.xhtml
> -> since ViewExpiredException also provides #getViewId we can remove the 
> overridden #getMessage completely.
> workaround:
> just use the exception as a marker and use a custom message



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4082) Composite binding don't works ...

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128821#comment-16128821
 ] 

Thomas Andraschko commented on MYFACES-4082:


Yep, replicated it.
[~lu4242] Could you give me a hint where this should be handled? I never touch 
the MyFaces code in this area.

> Composite binding don't works ...
> -
>
> Key: MYFACES-4082
> URL: https://issues.apache.org/jira/browse/MYFACES-4082
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.2.3, 2.2.11
> Environment: Debian 8.2
> JDK 1.8
> Netbeans 8.1
>Reporter: NCister
>Priority: Critical
>
> I've just tried to set binding of a simple composite.
> It don't works :-(
> To manage the componentType methods from user page the only way is to use 
> ViewRoot.findComponent .



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3008) Select components should honor javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128788#comment-16128788
 ] 

Thomas Andraschko commented on MYFACES-3008:


It's right that it is not honored at this place but it's honored before in 
UIInput#validate which is also used for h:select*. So the question is just: 
Should we pass null or "" to the converter?

So, i would close it for now as:
- over 6 years old
- there is no example or use-case in the description
- I can't find the mailing list entry

> Select components should honor 
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
> --
>
> Key: MYFACES-3008
> URL: https://issues.apache.org/jira/browse/MYFACES-3008
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.0.2, 2.0.3
> Environment: Glassfish v3, myfaces core 2.0.2
>Reporter: Jay Palaniappan
>Assignee: Thomas Andraschko
>
> javax.faces.component.UIInput.getConvertedValue converts empty String to null 
> even when javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set 
> as false.
> When I dug deeper I narrowed down the issue to the method 
> org.apache.myfaces.shared_impl.renderkit.RendererUtils.getConvertedUISelectOneValue
>  where if the submitted value is an empty string the submittedvalue is set to 
> null. I also understand that this logic was put in place to solve the issue 
> no. 1759 for version 1.2.2 but in JSF 2.0 the empty string to null conversion 
> is handled globally using context parameter 
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (MYFACES-3844) move StartupServletContextListener config to web-fragment.xml

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko resolved MYFACES-3844.

Resolution: Fixed

> move StartupServletContextListener config to web-fragment.xml
> -
>
> Key: MYFACES-3844
> URL: https://issues.apache.org/jira/browse/MYFACES-3844
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: JSR-344
>Affects Versions: 2.2.0
>Reporter: Gerhard Petracek
>Assignee: Thomas Andraschko
> Fix For: 2.3.0
>
> Attachments: MYFACES-3844.patch
>
>
> users who need to use servlet 2.5 + myfaces-core 2.2+ can still add the 
> listener to the web.xml



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3844) move StartupServletContextListener config to web-fragment.xml

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127001#comment-16127001
 ] 

Thomas Andraschko commented on MYFACES-3844:


[~lu4242] WDYT about this one? I would apply it in 2.3 as it makes sense.

> move StartupServletContextListener config to web-fragment.xml
> -
>
> Key: MYFACES-3844
> URL: https://issues.apache.org/jira/browse/MYFACES-3844
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: JSR-344
>Affects Versions: 2.2.0
>Reporter: Gerhard Petracek
>Assignee: Leonardo Uribe
> Attachments: MYFACES-3844.patch
>
>
> users who need to use servlet 2.5 + myfaces-core 2.2+ can still add the 
> listener to the web.xml



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (MYFACES-3163) [perf] review working with SelectItem(s)

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko resolved MYFACES-3163.

Resolution: Fixed

> [perf] review working with SelectItem(s)
> 
>
> Key: MYFACES-3163
> URL: https://issues.apache.org/jira/browse/MYFACES-3163
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: General
> Environment: myfaces core trunk
>Reporter: Martin Kočí
>Assignee: Thomas Andraschko
>Priority: Minor
> Fix For: 2.3.0
>
>
> review methods for performance:
> HtmlRendererUtils.renderSelectOptions
> RendererUtils.getSelectItemList
> RendererUtils.internalGetSelectItemList



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYFACES-3528) CLONE - Performance Improvements

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-3528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko updated MYFACES-3528:
---
Resolution: Won't Fix
Status: Resolved  (was: Patch Available)

As 1.x is in maintenance mode and this is "just" a improvement, i would close 
this for now.

> CLONE - Performance Improvements
> 
>
> Key: MYFACES-3528
> URL: https://issues.apache.org/jira/browse/MYFACES-3528
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 1.1.9
>Reporter: Krashan Brahmanjara
>Assignee: Martin Marinschek
> Fix For: 1.1.11-SNAPSHOT
>
> Attachments: ApplicationImpl.java, _ComponentAttributesMap.java
>
>
> Last week I did some JMeter testing, profiling and code checking on MyFaces 
> to try increase the overall performance. Here are my suggestions for 
> improvement:
> *) _ComponentAttributesMap
> I introduced a cache for maps with component attributes. This cache avoids 
> rebuilding the map for every instance of the same component class. It is 
> implemented using a WeakHashMap to allow the GC to remove entries that are 
> not referenced in any instance.
> *) UIComponentBase
> Made a few changes in isIdValid as it is called quite often. The new id is 
> now checked against the old id and if it is the same it is assumed as valid 
> (avoids checking chars). Additionally I use isLetterOrDigit() and access 
> string chars directly insted of fetching an array first.
> *) ImplicitObjectResolver
> I replaced List with Map to avoid iteration over lists.
> *) HtmlResponseWriterImpl
> Use new method of HTMLEncoder for char[]
> *) HTMLEncoder
> Improved performance of encode mthod and added a new one that takes a char[] 
> und directly writes to a writer.
> *) UnicodeEncoder
> Replaced StringBuffer with StringBuilder.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3163) [perf] review working with SelectItem(s)

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16121751#comment-16121751
 ] 

Thomas Andraschko commented on MYFACES-3163:


I just found 2 iterator-loops which can be replaced by a normal for loop to 
avoid the iterator instance. Will apply this for 2.3.

> [perf] review working with SelectItem(s)
> 
>
> Key: MYFACES-3163
> URL: https://issues.apache.org/jira/browse/MYFACES-3163
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: General
> Environment: myfaces core trunk
>Reporter: Martin Kočí
>Assignee: Martin Kočí
>Priority: Minor
>
> review methods for performance:
> HtmlRendererUtils.renderSelectOptions
> RendererUtils.getSelectItemList
> RendererUtils.internalGetSelectItemList



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3435) [perf] _DeltaList: use ArrayList as parent

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1612#comment-1612
 ] 

Thomas Andraschko commented on MYFACES-3435:


[~lu4242] Not sure!
I checked our applications and on _SMALL_ views, MyFaces creates around ~350 
_DeltaLists, which means mean the patch could save around ~350 ArrayList 
instances of we change from wrapping to inheritance.
For multiple users and on bigger views, this are a lot of ArrayList instances 
we could just save.

> [perf] _DeltaList: use ArrayList as parent
> --
>
> Key: MYFACES-3435
> URL: https://issues.apache.org/jira/browse/MYFACES-3435
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: General
>Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT
>Reporter: Martin Kočí
>Assignee: Martin Kočí
>Priority: Minor
> Attachments: _ComponentChildrenList2.java, MYFACES-3435-2.patch, 
> MYFACES-3435-7.patch, MYFACES-3435.patch
>
>
> Two internal classes _DeltaList in API:
> 1) now use delegation pattern, but are always initialized with an ArrayList 
> instance -> use inheritance and  ArrayList as parent -> improvement in memory 
> area, reduces number of GCed object in one request/response of (_DeltaList 
> instances/2) 
> 2) initialize expected size of _DeltaList (for example, number of validators 
> per one component is perhaps never 10, use: new _DeltaList(5))
> 3) use indexes in 'for' instead of iterator (java.util.RandomAccess) ->  
> improvement in performance



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3435) [perf] _DeltaList: use ArrayList as parent

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123240#comment-16123240
 ] 

Thomas Andraschko commented on MYFACES-3435:


[~lu4242] It seems that none of those patches were applied in the past. Do you 
think we should do it? IMO the patches are looking good and inheritance seems 
nicer as wrapping for me.

> [perf] _DeltaList: use ArrayList as parent
> --
>
> Key: MYFACES-3435
> URL: https://issues.apache.org/jira/browse/MYFACES-3435
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: General
>Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT
>Reporter: Martin Kočí
>Assignee: Martin Kočí
>Priority: Minor
> Attachments: _ComponentChildrenList2.java, MYFACES-3435-2.patch, 
> MYFACES-3435-7.patch, MYFACES-3435.patch
>
>
> Two internal classes _DeltaList in API:
> 1) now use delegation pattern, but are always initialized with an ArrayList 
> instance -> use inheritance and  ArrayList as parent -> improvement in memory 
> area, reduces number of GCed object in one request/response of (_DeltaList 
> instances/2) 
> 2) initialize expected size of _DeltaList (for example, number of validators 
> per one component is perhaps never 10, use: new _DeltaList(5))
> 3) use indexes in 'for' instead of iterator (java.util.RandomAccess) ->  
> improvement in performance



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3435) [perf] _DeltaList: use ArrayList as parent

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123374#comment-16123374
 ] 

Thomas Andraschko commented on MYFACES-3435:


Yep, i would also only do something for 2.3.
I didn't checked the View Pooling till now. Would you like to do this ticket? 
otherwise i could check it.

> [perf] _DeltaList: use ArrayList as parent
> --
>
> Key: MYFACES-3435
> URL: https://issues.apache.org/jira/browse/MYFACES-3435
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: General
>Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT
>Reporter: Martin Kočí
>Assignee: Martin Kočí
>Priority: Minor
> Attachments: _ComponentChildrenList2.java, MYFACES-3435-2.patch, 
> MYFACES-3435-7.patch, MYFACES-3435.patch
>
>
> Two internal classes _DeltaList in API:
> 1) now use delegation pattern, but are always initialized with an ArrayList 
> instance -> use inheritance and  ArrayList as parent -> improvement in memory 
> area, reduces number of GCed object in one request/response of (_DeltaList 
> instances/2) 
> 2) initialize expected size of _DeltaList (for example, number of validators 
> per one component is perhaps never 10, use: new _DeltaList(5))
> 3) use indexes in 'for' instead of iterator (java.util.RandomAccess) ->  
> improvement in performance



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3435) [perf] _DeltaList: use ArrayList as parent

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125609#comment-16125609
 ] 

Thomas Andraschko commented on MYFACES-3435:


I didn't find anything special which requires the wrapping.
My applications are working still fine with and without viewpooling.
Applied the new inheritance for _DeltaList and _ComponentChildrenList. 
_DeltaList is much cleaner now.


> [perf] _DeltaList: use ArrayList as parent
> --
>
> Key: MYFACES-3435
> URL: https://issues.apache.org/jira/browse/MYFACES-3435
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: General
>Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT
>Reporter: Martin Kočí
>Assignee: Martin Kočí
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: _ComponentChildrenList2.java, MYFACES-3435-2.patch, 
> MYFACES-3435-7.patch, MYFACES-3435.patch
>
>
> Two internal classes _DeltaList in API:
> 1) now use delegation pattern, but are always initialized with an ArrayList 
> instance -> use inheritance and  ArrayList as parent -> improvement in memory 
> area, reduces number of GCed object in one request/response of (_DeltaList 
> instances/2) 
> 2) initialize expected size of _DeltaList (for example, number of validators 
> per one component is perhaps never 10, use: new _DeltaList(5))
> 3) use indexes in 'for' instead of iterator (java.util.RandomAccess) ->  
> improvement in performance



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4130) CDI @ManagedProperty does not work with all types

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125590#comment-16125590
 ] 

Thomas Andraschko commented on MYFACES-4130:


JFY: Your commit breaks my applications as you included a EL-Impl without the 
right scope. I changed the scope and looks better now.

> CDI @ManagedProperty does not work with all types
> -
>
> Key: MYFACES-4130
> URL: https://issues.apache.org/jira/browse/MYFACES-4130
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
>Assignee: Eduardo Breijo
> Fix For: 2.3.0
>
> Attachments: MYFACES-4130.patch, MYFACES-4130-with-test.patch
>
>
> CDI Replacement for @ManagedProperty does not work with primitives, 
> ParameterizedType or arrays.
> For example:
> @Inject
> @ManagedProperty("#{testBean.list}")
> private List listManagedProperty;
> javax.faces.FacesException: java.lang.ClassNotFoundException: 
> java.util.List
>   at 
> org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:218)
>   at 
> org.apache.myfaces.cdi.bean.DynamicManagedPropertyProducer.(DynamicManagedPropertyProducer.java:58)
>   at 
> org.apache.myfaces.cdi.bean.ManagedPropertyExtension.afterBean(ManagedPropertyExtension.java:62)
> @Inject
> @ManagedProperty("#{testBean.number}")
> private int numberManagedProperty;
> javax.faces.FacesException: java.lang.ClassNotFoundException: int
>   at 
> org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:218)
>   at 
> org.apache.myfaces.cdi.bean.DynamicManagedPropertyProducer.(DynamicManagedPropertyProducer.java:58)
>   at 
> org.apache.myfaces.cdi.bean.ManagedPropertyExtension.afterBean(ManagedPropertyExtension.java:62)
> @Inject
> @ManagedProperty("#{testBean.stringArray}")
> private String[] stringArrayManagedProperty;
> javax.faces.FacesException: java.lang.ClassNotFoundException: 
> java.lang.String[]
>   at 
> org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:218)
>   at 
> org.apache.myfaces.cdi.bean.DynamicManagedPropertyProducer.(DynamicManagedPropertyProducer.java:58)
>   at 
> org.apache.myfaces.cdi.bean.ManagedPropertyExtension.afterBean(ManagedPropertyExtension.java:62)
> I've attached a patch. If no objections by Wednesday close of business I'll 
> commit it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYFACES-3435) [perf] _DeltaList: use ArrayList as parent

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko updated MYFACES-3435:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> [perf] _DeltaList: use ArrayList as parent
> --
>
> Key: MYFACES-3435
> URL: https://issues.apache.org/jira/browse/MYFACES-3435
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: General
>Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT
>Reporter: Martin Kočí
>Assignee: Martin Kočí
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: _ComponentChildrenList2.java, MYFACES-3435-2.patch, 
> MYFACES-3435-7.patch, MYFACES-3435.patch
>
>
> Two internal classes _DeltaList in API:
> 1) now use delegation pattern, but are always initialized with an ArrayList 
> instance -> use inheritance and  ArrayList as parent -> improvement in memory 
> area, reduces number of GCed object in one request/response of (_DeltaList 
> instances/2) 
> 2) initialize expected size of _DeltaList (for example, number of validators 
> per one component is perhaps never 10, use: new _DeltaList(5))
> 3) use indexes in 'for' instead of iterator (java.util.RandomAccess) ->  
> improvement in performance



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4123) [per] expensive call on javax.faces.validator.BeanValidator.validate()

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125633#comment-16125633
 ] 

Thomas Andraschko commented on MYFACES-4123:


[~eduardobreijo] Where did you read that a validator must be instantiated each 
time in the specs?

> [per] expensive call on javax.faces.validator.BeanValidator.validate()
> --
>
> Key: MYFACES-4123
> URL: https://issues.apache.org/jira/browse/MYFACES-4123
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.0.24, 2.2.12
>Reporter: Eduardo Breijo
>  Labels: performance
>
> Currently the javax.faces.validator.BeanValidator.validate() method performs 
> the following check:
>     // Initialize Bean Validation.
>     ValidatorFactory validatorFactory = createValidatorFactory(context);
>     javax.validation.Validator validator = 
> createValidator(validatorFactory, context);
>     BeanDescriptor beanDescriptor = 
> validator.getConstraintsForClass(valueBaseClass);
>     if (!beanDescriptor.isBeanConstrained()) 
> {
>     return;
>     }
>     
> What we have experienced is that the call to 
> "validator.getConstraintsForClass(valueBaseClass)" is very expensive on the 
> initial call for a particular class. Due to this, the returned BeanDescriptor 
> object is cached by the validator object in some implementations of 
> BeanValidation.
> To take advantage of this caching the same validator object needs to be 
> reused. Currently the javax.faces.validator.BeanValidator.validate() creates 
> a new javax.validation.Validator
> object with each call. A new validator is necessary to get the correct 
> message interpolator set based upon the current context (the locale is pulled 
> from the FacesContext).
> However, for the purposes of checking BeanDescriptor.isBeanConstrained(), the 
> message interpolator does not matter. Therefore, caching a validator object 
> for
> the getConstraintsForClass() call should be safe, and greatly improve overall 
> performance.
> The only solution I've thought of so far requires an update to the JSF 
> specification that allow for the validator to be stored in the application 
> map under a spec defined key for the sole purpose of the call to 
> getConstraintsForClass. This would be similar to obtaining a validatorFactory 
> where it is stored on the application map under the spec defined 
> VALIDATOR_FACTORY_KEY on the BeanValidator.
> It would be interesting if we could come up with an implementation specific 
> way to increase performance in this area or if the only way to fix this is by 
> opening a JSF spec issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (MYFACES-3130) [PERF] Avoid unnecessary AbstractList$Itr instances

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko resolved MYFACES-3130.

   Resolution: Fixed
Fix Version/s: 2.3.0

> [PERF] Avoid unnecessary AbstractList$Itr instances
> ---
>
> Key: MYFACES-3130
> URL: https://issues.apache.org/jira/browse/MYFACES-3130
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: JSR-314
> Environment: myfaces core trunk
>Reporter: Martin Kočí
>Assignee: Martin Kočí
> Fix For: 2.3.0
>
> Attachments: MYFACES-3130-example.patch, MYFACES-3130-part2.patch, 
> UIViewRoot-MYFACES-3130.patch
>
>
> Similar issue: MYFACES-3129
> loop from java 5:
> for (Object object: objects)
> creates new instance of AbstractList$Itr, if objects are instance of 
> ArrayList. 
> Similar situation is with explicit .iterator() call.
> In my testcases, it is about ~ 100 000 instances per request/response. 
> Creation itself is cheap, but triggers GC lately.
> I suggest to use old index-style for (i = 0; i < childCount;   i++) if 
> possible. Are there any rawbacks of index-based iteration? 
> Children is List and as implementation detail we  know that it is instance of 
> ArrayList.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3130) [PERF] Avoid unnecessary AbstractList$Itr instances

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125689#comment-16125689
 ] 

Thomas Andraschko commented on MYFACES-3130:


I would close this one. All loops are looking good now.

> [PERF] Avoid unnecessary AbstractList$Itr instances
> ---
>
> Key: MYFACES-3130
> URL: https://issues.apache.org/jira/browse/MYFACES-3130
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: JSR-314
> Environment: myfaces core trunk
>Reporter: Martin Kočí
>Assignee: Martin Kočí
> Fix For: 2.3.0
>
> Attachments: MYFACES-3130-example.patch, MYFACES-3130-part2.patch, 
> UIViewRoot-MYFACES-3130.patch
>
>
> Similar issue: MYFACES-3129
> loop from java 5:
> for (Object object: objects)
> creates new instance of AbstractList$Itr, if objects are instance of 
> ArrayList. 
> Similar situation is with explicit .iterator() call.
> In my testcases, it is about ~ 100 000 instances per request/response. 
> Creation itself is cheap, but triggers GC lately.
> I suggest to use old index-style for (i = 0; i < childCount;   i++) if 
> possible. Are there any rawbacks of index-based iteration? 
> Children is List and as implementation detail we  know that it is instance of 
> ArrayList.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MYFACES-4135) Use Java8 instead of commons

[Thomas Andraschko (JIRA)]

Thomas Andraschko created MYFACES-4135:
--

 Summary: Use Java8 instead of commons
 Key: MYFACES-4135
 URL: https://issues.apache.org/jira/browse/MYFACES-4135
 Project: MyFaces Core
  Issue Type: Bug
Reporter: Thomas Andraschko
Assignee: Thomas Andraschko
Priority: Minor


e.g. Base64 - will check other used parts



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4134) Update to commons-collections 4

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16130114#comment-16130114
 ] 

Thomas Andraschko commented on MYFACES-4134:


basically +1
but we should check if it's still required. We have many commons dependencies - 
some of them are not required anymore with java8 (like Base64).

> Update to commons-collections 4
> ---
>
> Key: MYFACES-4134
> URL: https://issues.apache.org/jira/browse/MYFACES-4134
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.3.0-beta
>Reporter: Dennis Kieselhorst
>Priority: Minor
> Fix For: 2.3.0
>
>
> Should we update to commons-collection 4 for 2.3.0? If nobody objects, I can 
> do the changes...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4134) Update to commons-collections 4

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16130262#comment-16130262
 ] 

Thomas Andraschko edited comment on MYFACES-4134 at 8/17/17 11:11 AM:
--

I already started the work here: 
https://issues.apache.org/jira/browse/MYFACES-4135
I think we can get rid of Collections and Coded probably. Digester and 
BeanUtils requires a lot of more work.

Predicate and filter could be replaced a simple loop + simple interface 
probably.


was (Author: tandraschko):
I already started the work here: 
https://issues.apache.org/jira/browse/MYFACES-4135
I think we can get rid of Collections and Coded probably. Digester and 
BeanUtils requires a lot of more work.

> Update to commons-collections 4
> ---
>
> Key: MYFACES-4134
> URL: https://issues.apache.org/jira/browse/MYFACES-4134
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.3.0-beta
>Reporter: Dennis Kieselhorst
>Priority: Minor
> Fix For: 2.3.0
>
>
> Should we update to commons-collection 4 for 2.3.0? If nobody objects, I can 
> do the changes...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4134) Update to commons-collections 4

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16130262#comment-16130262
 ] 

Thomas Andraschko commented on MYFACES-4134:


I already started the work here: 
https://issues.apache.org/jira/browse/MYFACES-4135
I think we can get rid of Collections and Coded probably. Digester and 
BeanUtils requires a lot of more work.

> Update to commons-collections 4
> ---
>
> Key: MYFACES-4134
> URL: https://issues.apache.org/jira/browse/MYFACES-4134
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.3.0-beta
>Reporter: Dennis Kieselhorst
>Priority: Minor
> Fix For: 2.3.0
>
>
> Should we update to commons-collection 4 for 2.3.0? If nobody objects, I can 
> do the changes...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYFACES-4124) Wrong user properties map is used when using and onOpen method is invoked

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko updated MYFACES-4124:
---
   Resolution: Fixed
 Assignee: Thomas Andraschko
Fix Version/s: 2.3.0
   Status: Resolved  (was: Patch Available)

> Wrong user properties map is used when using  and onOpen method 
> is invoked
> ---
>
> Key: MYFACES-4124
> URL: https://issues.apache.org/jira/browse/MYFACES-4124
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
> Environment: WebSphere Application Server Liberty profile
>Reporter: Eduardo Breijo
>Assignee: Thomas Andraschko
> Fix For: 2.3.0
>
> Attachments: MYFACES-4124.patch
>
>
> The  tag does not work due to a wrong object being used to get 
> user properties map when the onOpen method from EndpointImpl is called. 
> Currently, the WEBSOCKET_VALID key is stored in the user properties map of 
> ServerEndpointConfig. When the onOpen method is called, it tries to retrieve 
> the value stored for this key, but it is trying to get it from the wrong user 
> properties map, that is, from the Session map, instead of getting it from the 
> EndpointConfig user properties map.
> A patch has been provided to fix this issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4123) Performance improvement needed due to expensive call on javax.faces.validator.BeanValidator.validate()

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16089492#comment-16089492
 ] 

Thomas Andraschko commented on MYFACES-4123:


[~lu4242] WDYT leo?

> Performance improvement needed due to expensive call on 
> javax.faces.validator.BeanValidator.validate()
> --
>
> Key: MYFACES-4123
> URL: https://issues.apache.org/jira/browse/MYFACES-4123
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.0.24, 2.2.12
>Reporter: Eduardo Breijo
>  Labels: performance
>
> Currently the javax.faces.validator.BeanValidator.validate() method performs 
> the following check:
>     // Initialize Bean Validation.
>     ValidatorFactory validatorFactory = createValidatorFactory(context);
>     javax.validation.Validator validator = 
> createValidator(validatorFactory, context);
>     BeanDescriptor beanDescriptor = 
> validator.getConstraintsForClass(valueBaseClass);
>     if (!beanDescriptor.isBeanConstrained()) 
> {
>     return;
>     }
>     
> What we have experienced is that the call to 
> "validator.getConstraintsForClass(valueBaseClass)" is very expensive on the 
> initial call for a particular class. Due to this, the returned BeanDescriptor 
> object is cached by the validator object in some implementations of 
> BeanValidation.
> To take advantage of this caching the same validator object needs to be 
> reused. Currently the javax.faces.validator.BeanValidator.validate() creates 
> a new javax.validation.Validator
> object with each call. A new validator is necessary to get the correct 
> message interpolator set based upon the current context (the locale is pulled 
> from the FacesContext).
> However, for the purposes of checking BeanDescriptor.isBeanConstrained(), the 
> message interpolator does not matter. Therefore, caching a validator object 
> for
> the getConstraintsForClass() call should be safe, and greatly improve overall 
> performance.
> The only solution I've thought of so far requires an update to the JSF 
> specification that allow for the validator to be stored in the application 
> map under a spec defined key for the sole purpose of the call to 
> getConstraintsForClass. This would be similar to obtaining a validatorFactory 
> where it is stored on the application map under the spec defined 
> VALIDATOR_FACTORY_KEY on the BeanValidator.
> It would be interesting if we could come up with an implementation specific 
> way to increase performance in this area or if the only way to fix this is by 
> opening a JSF spec issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4124) Wrong user properties map is used when using and onOpen method is invoked

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16089501#comment-16089501
 ] 

Thomas Andraschko commented on MYFACES-4124:


Looks fine for me, thanks for the patch!

> Wrong user properties map is used when using  and onOpen method 
> is invoked
> ---
>
> Key: MYFACES-4124
> URL: https://issues.apache.org/jira/browse/MYFACES-4124
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
> Environment: WebSphere Application Server Liberty profile
>Reporter: Eduardo Breijo
> Attachments: MYFACES-4124.patch
>
>
> The  tag does not work due to a wrong object being used to get 
> user properties map when the onOpen method from EndpointImpl is called. 
> Currently, the WEBSOCKET_VALID key is stored in the user properties map of 
> ServerEndpointConfig. When the onOpen method is called, it tries to retrieve 
> the value stored for this key, but it is trying to get it from the wrong user 
> properties map, that is, from the Session map, instead of getting it from the 
> EndpointConfig user properties map.
> A patch has been provided to fix this issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4125) Response committed too early due to flush from StateWriter

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16096263#comment-16096263
 ] 

Thomas Andraschko commented on MYFACES-4125:


I think we should wait on Leo's input here.

> Response committed too early due to flush from StateWriter
> --
>
> Key: MYFACES-4125
> URL: https://issues.apache.org/jira/browse/MYFACES-4125
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.2.12
>Reporter: Eduardo Breijo
> Attachments: server.log, StateWriter.war
>
>
> We've found a problem where it seems that MyFaces is flushing output too 
> early in the RENDER_RESPONSE PHASE. As a result the response is committed 
> before we have a chance to handle an error in that phase. 
> This is because the renderView method from FaceletViewDeclarationLanguage 
> calls writer.endDocument() which ends up calling the flush() method from 
> StateWriter. This commit behavior is different between 2.0 and 2.2.  It looks 
> like a flush() was empty on 2.0, and now a call was added, which causes the 
> issue we are seeing.
> Here's a sample app:
> 1) Drive a request: localhost:9080/StateWriter/index.xhtml
> 2) You should be able to see in the logs that response was committed, so 
> redirect to error.xhtml cannot be performed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4126) Implicit objects flowScope and view cannot be injected using CDI

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16098251#comment-16098251
 ] 

Thomas Andraschko commented on MYFACES-4126:


It's available in core -> 
\current23\core\impl\src\main\java\org\apache\myfaces\cdi\faces ;)

> Implicit objects flowScope and view cannot be injected using CDI
> 
>
> Key: MYFACES-4126
> URL: https://issues.apache.org/jira/browse/MYFACES-4126
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
>Assignee: Eduardo Breijo
> Attachments: MYFACES-4126.patch
>
>
> The implicit objects {code:java}#{flowScope}{code} annotated @FlowMap and 
> {code:java}#{view}{code} which results in UIViewRoot cannot be injected using 
> CDI.
> For example:
> @Inject
> private UIViewRoot viewRoot;
> @Inject
> @FlowMap
> private Map flowMap;
> The above results in the following errors respectively:
> An exception occurred while starting the application ELImplicitObjectsViaCDI. 
> The exception message was: 
> com.ibm.ws.container.service.state.StateChangeException: 
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied 
> dependencies for type UIViewRoot with qualifiers @Default
>   at injection point [BackedAnnotatedField] @Inject private 
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.viewRoot
> An exception occurred while starting the application ELImplicitObjectsViaCDI. 
> The exception message was: 
> com.ibm.ws.container.service.state.StateChangeException: 
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied 
> dependencies for type Map with qualifiers @FlowMap
>   at injection point [BackedAnnotatedField] @Inject @FlowMap private 
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.flowMap
> A patch is provided.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4126) Implicit objects flowScope and view cannot be injected using CDI

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16098311#comment-16098311
 ] 

Thomas Andraschko commented on MYFACES-4126:


I don't think this class is available in CODI.

> Implicit objects flowScope and view cannot be injected using CDI
> 
>
> Key: MYFACES-4126
> URL: https://issues.apache.org/jira/browse/MYFACES-4126
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
>Assignee: Eduardo Breijo
> Attachments: MYFACES-4126.patch
>
>
> The implicit objects {code:java}#{flowScope}{code} annotated @FlowMap and 
> {code:java}#{view}{code} which results in UIViewRoot cannot be injected using 
> CDI.
> For example:
> @Inject
> private UIViewRoot viewRoot;
> @Inject
> @FlowMap
> private Map flowMap;
> The above results in the following errors respectively:
> An exception occurred while starting the application ELImplicitObjectsViaCDI. 
> The exception message was: 
> com.ibm.ws.container.service.state.StateChangeException: 
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied 
> dependencies for type UIViewRoot with qualifiers @Default
>   at injection point [BackedAnnotatedField] @Inject private 
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.viewRoot
> An exception occurred while starting the application ELImplicitObjectsViaCDI. 
> The exception message was: 
> com.ibm.ws.container.service.state.StateChangeException: 
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied 
> dependencies for type Map with qualifiers @FlowMap
>   at injection point [BackedAnnotatedField] @Inject @FlowMap private 
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.flowMap
> A patch is provided.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106595#comment-16106595
 ] 

Thomas Andraschko commented on MYFACES-3525:


I like your patch much more as the initial patch BUT we should check the specs 
in detail.
As bill already commented, our default behavior looks aligned with the specs.
Not sure if it's correct to follow mojarra when the spec's hasn't been changed.
Maybe we should trigger this at the specs mailing list.


> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects 
> display behavior for required fields
> --
>
> Key: MYFACES-3525
> URL: https://issues.apache.org/jira/browse/MYFACES-3525
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.0.12, 2.1.18, 2.2.12, 2.3.0-beta
>Reporter: VS
>Assignee: Leonardo Uribe
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT
>
> Attachments: MYFACES-3525.patch, 
> MYFACES-3525-setsubmittedValueagain.patch
>
>
> Inconsistent behavior for required field validation when 
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to true 
> versus false
> To observe behavior:
> 1. Set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to true in 
> web.xml
> 2. Create JSF Page:
> 
> 
>  required="true"
> requiredMessage="You must enter a first name"/>
> 
> 
> 3. Create Managed Bean:
> @ManagedBean
> public class Page1Controller
> {
> public String getFirstName()
> { return "Default Value"; }
> public void setFirstName(String value)
> { // no-op (for example purposes only) }
> 4. Load JSF page, blank out value in the input field and click Submit
> 5. Error message is displayed, however the value in the input field (which 
> you formerly blanked out) is now reset back to its original value.
> 6. Change the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL 
> setting to false and re-run the test.
> 7. Note that the value in the input field remains blank.
> Behavior is inconsistent and should be fixed 
> (javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL setting of true 
> or false should not result in inconsistent behavior with required fields)
> 
> To state in a different way:
> When INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is TRUE, and you blank 
> out a value for a required field that had previously been populated by the 
> model, submit the form, you will see the OLD data from the model in the 
> field. However, if that field had had a format validation applied to it and 
> the user submits the form with a format validation error, the OLD data is NOT 
> shown in the field (instead, the submitted/invalid data is shown). The same 
> should happen for required field validation errors. The field should show the 
> "blank" data and not the original model data. In order to get the correct 
> behavior, the developer has to currently set 
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to false. But they should not 
> have to do this... whether INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is 
> true or false, the behavior of showing the blank field that the user 
> submitted should be the same.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4065) Did not handled empty string while creating the resource

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119566#comment-16119566
 ] 

Thomas Andraschko commented on MYFACES-4065:


[~wtlucy] looks fine for me, feel free to commit.

> Did not handled empty string while creating the resource
> 
>
> Key: MYFACES-4065
> URL: https://issues.apache.org/jira/browse/MYFACES-4065
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.2.3
> Environment: Windows, Tomcat
>Reporter: Madhavi T
>Priority: Minor
> Attachments: MYFACES-4065.patch
>
>
> java.lang.StringIndexOutOfBoundsException: String index out of range: 0
>   at java.lang.String.charAt(Unknown Source)
>   at 
> org.apache.myfaces.application.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:118)
>   at 
> javax.faces.application.ResourceHandlerWrapper.createResource(ResourceHandlerWrapper.java:47)
>   at 
> org.apache.myfaces.custom.captcha.CAPTCHAResourceHandlerWrapper.createResource(CAPTCHAResourceHandlerWrapper.java:83)
>   at 
> org.apache.myfaces.tomahawk.resource.UncompressedResourceHandlerWrapper.createResource(UncompressedResourceHandlerWrapper.java:109)
>   at 
> org.apache.myfaces.tomahawk.resource.UncompressedResourceHandlerWrapper.createResource(UncompressedResourceHandlerWrapper.java:61)
>   at 
> org.apache.myfaces.tomahawk.resource.UncompressedResourceHandlerWrapper.createResource(UncompressedResourceHandlerWrapper.java:55)
>   at 
> javax.faces.application.ResourceHandlerWrapper.createResource(ResourceHandlerWrapper.java:35)
>   at 
> org.apache.myfaces.application.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:568)
>   at 
> javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:59)
>   at 
> org.apache.myfaces.custom.captcha.CAPTCHAResourceHandlerWrapper.handleResourceRequest(CAPTCHAResourceHandlerWrapper.java:212)
>   at 
> javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:59)
>   at 
> javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:59)
>   at 
> org.primefaces.application.resource.PrimeResourceHandler.handleResourceRequest(PrimeResourceHandler.java:87)
>   at javax.faces.webapp.FacesServlet.service(FacesServlet.java:190)
>   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.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:357)
>   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:217)
>   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:616)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
>   at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518)
>   at 
> org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java:844)
>   at 
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:673)
>   at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1500)
>   at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1456)
>   at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>   at 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>   at java.lang.Thread.run(Unknown Source)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (MYFACES-3170) [perf] use initialCapacity for ArrayList

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko resolved MYFACES-3170.

Resolution: Not A Problem

it's already used in many places (also already in UIInput like mentioned in the 
description) - i would close it for now.

> [perf] use initialCapacity for ArrayList
> 
>
> Key: MYFACES-3170
> URL: https://issues.apache.org/jira/browse/MYFACES-3170
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: General
> Environment: myfaces trunk
>Reporter: Martin Kočí
>Assignee: Martin Kočí
>Priority: Minor
>
> new ArrayList() creates Object [10]  and in some situation it is not 
> necessary. For example, UIInput.addValidator allocates ArrayList of size ten 
> but in real usage nobody adds 10 validators to one component.
> Analyze usage of new ArrayList() and myfaces code and use initialCapacity if 
> possible.
> i



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (MYFACES-2869) Ajaxified h:selectBooleanCheckbox not working in IE8

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-2869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko resolved MYFACES-2869.

Resolution: Workaround

IE8 requires event=click and the functionality is fine with event=click. Will 
close this.

> Ajaxified h:selectBooleanCheckbox not working in IE8
> 
>
> Key: MYFACES-2869
> URL: https://issues.apache.org/jira/browse/MYFACES-2869
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-314
>Affects Versions: 2.0.0, 2.0.1, 2.0.2-SNAPSHOT
>Reporter: Michael Kurz
> Attachments: MYFACES-2869.zip
>
>
> I have an ajaxified h:selectBooleanCheckbox like this:
> 
> 
> 
> The value change listener toggles a boolean flag and the component with the 
> id "textBox" is re-rendered. This works fine with FF, Safari and Chrome but 
> not with IE8. The resaon for this is that the default onchange event is not 
> working correctly in IE8. In IE8 onchange is not triggered before the 
> component looses the focus. So I have to click the component and then again 
> outside the component to hav the ajax request sent.
> A workaround for this is to set the event to click manually:
> 
> 
> 
> The question now is, should we change the default event for 
> HtmlSelectBooleanCheckbox from change to click (or more precisely the mapping 
> of valueChange from change to click)? I quickly scanned the spec but I found 
> nothing helpful.
> Mojarra seems to render an onclick attribute by default. But what is kind of 
> funny - with event="click" on f:ajax it stops working...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3459) RegexValidator does not provide label and pattern for first usage of RegexValidator.NOT_MATCHED

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119737#comment-16119737
 ] 

Thomas Andraschko commented on MYFACES-3459:


[~lu4242] i think we can just commit the patch?

> RegexValidator does not provide label and pattern for first usage of 
> RegexValidator.NOT_MATCHED
> ---
>
> Key: MYFACES-3459
> URL: https://issues.apache.org/jira/browse/MYFACES-3459
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.1.5
> Environment: myfaces trunk
>Reporter: Martin Kočí
>Assignee: Martin Kočí
>Priority: Trivial
> Attachments: myfaces-1244836.patch, MYFACES-3459.patch
>
>
> RegexValidator uses javax.faces.validator.RegexValidator.NOT_MATCHED 2x:
> javax.faces.validator.RegexValidator.NOT_MATCHED= the passed value is not a 
> String, or when the pattern does not match the passed value.
> the first usage for" if (value instanceof String)" check does not provide 
> args for {0} {1} in message.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4062) Building site (Tobago) crashes

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119738#comment-16119738
 ] 

Thomas Andraschko commented on MYFACES-4062:


[~lofwyr] Whats with that ticket? isn't it already fixed?

> Building site (Tobago) crashes
> --
>
> Key: MYFACES-4062
> URL: https://issues.apache.org/jira/browse/MYFACES-4062
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: website
>Reporter: Udo Schnurpfeil
>Assignee: Udo Schnurpfeil
>Priority: Minor
>
> The error message is 
> {code}
> ...
> [DEBUG] Processing Velocity for template META-INF/maven/site.vm on
> compatibility.apt
> [ERROR] Parser Exception: META-INF/maven/site.vm
> org.apache.velocity.runtime.parser.ParseException: Encountered "1.0" at
> line 357, column 51.
> Was expecting one of:
>  ...
>  ...
> "-" ...
> ...
> im META-INF/maven/site.vm aus myfaces-site-skin-4-SNAPSHOT.jar sthet in
> Zeile 357:
> #set ( $documentHeader = " encoding=\"UTF-8\"?>" )
> {code}
> The problem is, that with current plugins in velocity the Char " inside of "" 
> must be escaped with doube ", not with a backslash.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (MYFACES-4132) Search expression doesn't work as expected when expression is id:keyword

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko resolved MYFACES-4132.

Resolution: Fixed

> Search expression doesn't work as expected when expression is id:keyword
> 
>
> Key: MYFACES-4132
> URL: https://issues.apache.org/jira/browse/MYFACES-4132
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
> Fix For: 2.3.0
>
> Attachments: ComponentSearchExpression.war, 
> MYFACES-4132-unittest.patch
>
>
> When a component search is done using an expression of this type 
> "id:keyword", the resolved id is unexpected. 
> I have provided a test app:
> 1) Deploy the app on tomcat
> 2) Drive a request: 
> http://localhost:8080/ComponentSearchExpression/index.xhtml
> 3) When you check this response message: "TEST resolveComponent with search 
> expression 'form1:@parent' -> form1" we should expect that the expression 
> "form1:@parent" resolves to "body" and not "form1".
> 4) Another example in that same test: Check the page source and look for 
> "Body Child(1)" which is an outputLabel, the search expression used in the 
> for attribute is "body:@child(1)" and this should resolve to "form1" but 
> instead it is resolving to "body"
> Tested this app using mojarra and it works as expected.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4132) Search expression doesn't work as expected when expression is id:keyword

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16118576#comment-16118576
 ] 

Thomas Andraschko commented on MYFACES-4132:


Thanks for the unittest - it's fixed!

> Search expression doesn't work as expected when expression is id:keyword
> 
>
> Key: MYFACES-4132
> URL: https://issues.apache.org/jira/browse/MYFACES-4132
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
> Fix For: 2.3.0
>
> Attachments: ComponentSearchExpression.war, 
> MYFACES-4132-unittest.patch
>
>
> When a component search is done using an expression of this type 
> "id:keyword", the resolved id is unexpected. 
> I have provided a test app:
> 1) Deploy the app on tomcat
> 2) Drive a request: 
> http://localhost:8080/ComponentSearchExpression/index.xhtml
> 3) When you check this response message: "TEST resolveComponent with search 
> expression 'form1:@parent' -> form1" we should expect that the expression 
> "form1:@parent" resolves to "body" and not "form1".
> 4) Another example in that same test: Check the page source and look for 
> "Body Child(1)" which is an outputLabel, the search expression used in the 
> for attribute is "body:@child(1)" and this should resolve to "form1" but 
> instead it is resolving to "body"
> Tested this app using mojarra and it works as expected.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4053) PartialViewContextImpl does not fully implement the requirements outlined in section 2.2.6.1 of the JSF 2.2 Spec

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16118608#comment-16118608
 ] 

Thomas Andraschko commented on MYFACES-4053:


[~ngriffin7a] Would you like to prepare a patch here?

> PartialViewContextImpl does not fully implement the requirements outlined in 
> section 2.2.6.1 of the JSF 2.2 Spec
> 
>
> Key: MYFACES-4053
> URL: https://issues.apache.org/jira/browse/MYFACES-4053
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-344
>Affects Versions: 2.2.10
>Reporter: Neil Griffin
>
> [JAVASERVERFACES_SPEC_PUBLIC-1069|https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1069]
>  introduced new requirements for compatibility with portlet environments. 
> This resulted in an update to section 2.2.6.1 of the Spec titled "Render 
> Response Partial Processing".



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3145) Myfaces h:commandButton errors on Mozilla >3.6 when using Javascript form.submit()

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16118584#comment-16118584
 ] 

Thomas Andraschko commented on MYFACES-3145:


If it would be still up-to-date, not sure if we can do anything there. Will 
close it for now.

> Myfaces h:commandButton errors on Mozilla >3.6 when using Javascript 
> form.submit()
> --
>
> Key: MYFACES-3145
> URL: https://issues.apache.org/jira/browse/MYFACES-3145
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: website
>Affects Versions: 1.1.10-SNAPSHOT
> Environment: Myfaces 1.1.10 on Tomcat 6.0.x
>Reporter: suresh t
>Assignee: Thomas Andraschko
>
> submitting commandButton buttons using javascript code 
> "document.getElementById('jsfsearch').submit()" doesn't send all values in 
> the form to the tomcat when using Mozilla. whereas the same code works on IE.
> ===
>  
>   onclick
> ="return submitSearch();" action="#{searchController.simple}" 
> value="#{searchmes
> sages['simplesearch']}"/>
>   "search_Srch1" value="#{searchController.vSrch1}"  rendered="#{searchContr
> oller.searchparameter1}" />
> 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4132) Search expression doesn't work as expected when expression is id:keyword

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16118461#comment-16118461
 ] 

Thomas Andraschko commented on MYFACES-4132:


Could you please create a unit test for it? we have many unit tests for search 
expressions.

> Search expression doesn't work as expected when expression is id:keyword
> 
>
> Key: MYFACES-4132
> URL: https://issues.apache.org/jira/browse/MYFACES-4132
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
> Attachments: ComponentSearchExpression.war
>
>
> When a component search is done using an expression of this type 
> "id:keyword", the resolved id is unexpected. 
> I have provided a test app:
> 1) Deploy the app on tomcat
> 2) Drive a request: 
> http://localhost:8080/ComponentSearchExpression/index.xhtml
> 3) When you check this response message: "TEST resolveComponent with search 
> expression 'form1:@parent' -> form1" we should expect that the expression 
> "form1:@parent" resolves to "body" and not "form1".
> 4) Another example in that same test: Check the page source and look for 
> "Body Child(1)" which is an outputLabel, the search expression used in the 
> for attribute is "body:@child(1)" and this should resolve to "form1" but 
> instead it is resolving to "body"
> Tested this app using mojarra and it works as expected.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MYFACES-4137) Apply NetBeans performance hints

[Thomas Andraschko (JIRA)]

Thomas Andraschko created MYFACES-4137:
--

 Summary: Apply NetBeans performance hints
 Key: MYFACES-4137
 URL: https://issues.apache.org/jira/browse/MYFACES-4137
 Project: MyFaces Core
  Issue Type: Improvement
Reporter: Thomas Andraschko
Assignee: Thomas Andraschko


Like
- boxing already boxed value
- getClass instead .class
- indexOf with character instead of string



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (MYFACES-4137) Apply NetBeans performance hints

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko resolved MYFACES-4137.

Resolution: Fixed

> Apply NetBeans performance hints
> 
>
> Key: MYFACES-4137
> URL: https://issues.apache.org/jira/browse/MYFACES-4137
> Project: MyFaces Core
>  Issue Type: Improvement
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
> Fix For: 2.3.0
>
>
> Like
> - boxing already boxed value
> - getClass instead .class
> - indexOf with character instead of string



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4133) Don't deserialize the ViewState-ID if the state saving method is server

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16133048#comment-16133048
 ] 

Thomas Andraschko commented on MYFACES-4133:


1) makes sense
2) i think it's valid to disable encryption if server-side state is used
3) using a better default algorithm makes sense but this should be another jira 
issue

> Don't deserialize the ViewState-ID if the state saving method is server
> ---
>
> Key: MYFACES-4133
> URL: https://issues.apache.org/jira/browse/MYFACES-4133
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.2.12
>Reporter: Peter Stöckli
>
> Currently the ViewState-ID provided by the user is deserialized via Java 
> deserialization even when the {{javax.faces.STATE_SAVING_METHOD}} is set to 
> {{server}} (the default).
> The deserialization in this case is unecessary and most likely even slower 
> than just sending the ViewState Id directly.
> If a developer now disables the ViewState encryption by setting 
> {{org.apache.myfaces.USE_ENCRYPTION}} to {{false}} (against the [MyFaces 
> security advice|https://wiki.apache.org/myfaces/Secure_Your_Application]) he 
> might have unintentionally introduced a dangerous remote code execution (RCE) 
> vulnerability as described 
> [here|https://www.alphabot.com/security/blog/2017/java/Misconfigured-JSF-ViewStates-can-lead-to-severe-RCE-vulnerabilities.html].
> This has been discussed before on [Issue 
> MYFACES-4021|https://issues.apache.org/jira/browse/MYFACES-4021].



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4133) Don't deserialize the ViewState-ID if the state saving method is server

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16133048#comment-16133048
 ] 

Thomas Andraschko edited comment on MYFACES-4133 at 8/18/17 2:47 PM:
-

1) makes sense
2) i think it's valid to disable encryption if server-side state is used - or 
do i miss something [~lu4242]?
3) using a better default algorithm makes sense but this should be another jira 
issue


was (Author: tandraschko):
1) makes sense
2) i think it's valid to disable encryption if server-side state is used
3) using a better default algorithm makes sense but this should be another jira 
issue

> Don't deserialize the ViewState-ID if the state saving method is server
> ---
>
> Key: MYFACES-4133
> URL: https://issues.apache.org/jira/browse/MYFACES-4133
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.2.12
>Reporter: Peter Stöckli
>
> Currently the ViewState-ID provided by the user is deserialized via Java 
> deserialization even when the {{javax.faces.STATE_SAVING_METHOD}} is set to 
> {{server}} (the default).
> The deserialization in this case is unecessary and most likely even slower 
> than just sending the ViewState Id directly.
> If a developer now disables the ViewState encryption by setting 
> {{org.apache.myfaces.USE_ENCRYPTION}} to {{false}} (against the [MyFaces 
> security advice|https://wiki.apache.org/myfaces/Secure_Your_Application]) he 
> might have unintentionally introduced a dangerous remote code execution (RCE) 
> vulnerability as described 
> [here|https://www.alphabot.com/security/blog/2017/java/Misconfigured-JSF-ViewStates-can-lead-to-severe-RCE-vulnerabilities.html].
> This has been discussed before on [Issue 
> MYFACES-4021|https://issues.apache.org/jira/browse/MYFACES-4021].



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4123) Performance improvement needed due to expensive call on javax.faces.validator.BeanValidator.validate()

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16058131#comment-16058131
 ] 

Thomas Andraschko commented on MYFACES-4123:


In PF we cache the Validator instance. In older versions we cached the 
ValidatorFactory instance.
AFAIK hibernate caches their internal metadata on ValidatorFactory level, 
whereas bval caches their internal stuff on Validator level.

> Performance improvement needed due to expensive call on 
> javax.faces.validator.BeanValidator.validate()
> --
>
> Key: MYFACES-4123
> URL: https://issues.apache.org/jira/browse/MYFACES-4123
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.0.24, 2.2.12
>Reporter: Eduardo Breijo
>  Labels: performance
>
> Currently the javax.faces.validator.BeanValidator.validate() method performs 
> the following check:
>     // Initialize Bean Validation.
>     ValidatorFactory validatorFactory = createValidatorFactory(context);
>     javax.validation.Validator validator = 
> createValidator(validatorFactory, context);
>     BeanDescriptor beanDescriptor = 
> validator.getConstraintsForClass(valueBaseClass);
>     if (!beanDescriptor.isBeanConstrained()) 
> {
>     return;
>     }
>     
> What we have experienced is that the call to 
> "validator.getConstraintsForClass(valueBaseClass)" is very expensive on the 
> initial call for a particular class. Due to this, the returned BeanDescriptor 
> object is cached by the validator object in some implementations of 
> BeanValidation.
> To take advantage of this caching the same validator object needs to be 
> reused. Currently the javax.faces.validator.BeanValidator.validate() creates 
> a new javax.validation.Validator
> object with each call. A new validator is necessary to get the correct 
> message interpolator set based upon the current context (the locale is pulled 
> from the FacesContext).
> However, for the purposes of checking BeanDescriptor.isBeanConstrained(), the 
> message interpolator does not matter. Therefore, caching a validator object 
> for
> the getConstraintsForClass() call should be safe, and greatly improve overall 
> performance.
> The only solution I've thought of so far requires an update to the JSF 
> specification that allow for the validator to be stored in the application 
> map under a spec defined key for the sole purpose of the call to 
> getConstraintsForClass. This would be similar to obtaining a validatorFactory 
> where it is stored on the application map under the spec defined 
> VALIDATOR_FACTORY_KEY on the BeanValidator.
> It would be interesting if we could come up with an implementation specific 
> way to increase performance in this area or if the only way to fix this is by 
> opening a JSF spec issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4121) Fix javadoc for 2.3 branch and update maven-javadoc-plugin

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039337#comment-16039337
 ] 

Thomas Andraschko commented on MYFACES-4121:


+1 Dennis

> Fix javadoc for 2.3 branch and update maven-javadoc-plugin 
> ---
>
> Key: MYFACES-4121
> URL: https://issues.apache.org/jira/browse/MYFACES-4121
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
>Priority: Blocker
>
> MyFaces 2.3 branch requires Java 8 and an updated maven-javadoc-plugin. The 
> problem is the new versions are more strict to generate the javadoc, so we 
> need to check the javadoc and fix its generation.
> This is a blocker issue for beta release, since we cannot generate all 
> artifacts without fix this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4152) Add missing @Override

[Thomas Andraschko (JIRA)]

Thomas Andraschko created MYFACES-4152:
--

 Summary: Add missing @Override
 Key: MYFACES-4152
 URL: https://issues.apache.org/jira/browse/MYFACES-4152
 Project: MyFaces Core
  Issue Type: Improvement
Affects Versions: 2.3.0-beta
Reporter: Thomas Andraschko
Assignee: Thomas Andraschko
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16165273#comment-16165273
 ] 

Thomas Andraschko commented on MYFACES-3525:


Just tried mojarra and the input is also empty after submitting a empty value. 
Therefor -1 to change the behavior in MyFaces as it breaks compatibility.
As leo said, it should be fixed at spec level.

> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects 
> display behavior for required fields
> --
>
> Key: MYFACES-3525
> URL: https://issues.apache.org/jira/browse/MYFACES-3525
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.0.12, 2.1.18, 2.2.12, 2.3.0-beta
>Reporter: VS
>Assignee: Leonardo Uribe
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT
>
> Attachments: MYFACES-3525.patch, 
> MYFACES-3525-setsubmittedValueagain.patch
>
>
> Inconsistent behavior for required field validation when 
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to true 
> versus false
> To observe behavior:
> 1. Set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to true in 
> web.xml
> 2. Create JSF Page:
> 
> 
>  required="true"
> requiredMessage="You must enter a first name"/>
> 
> 
> 3. Create Managed Bean:
> @ManagedBean
> public class Page1Controller
> {
> public String getFirstName()
> { return "Default Value"; }
> public void setFirstName(String value)
> { // no-op (for example purposes only) }
> 4. Load JSF page, blank out value in the input field and click Submit
> 5. Error message is displayed, however the value in the input field (which 
> you formerly blanked out) is now reset back to its original value.
> 6. Change the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL 
> setting to false and re-run the test.
> 7. Note that the value in the input field remains blank.
> Behavior is inconsistent and should be fixed 
> (javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL setting of true 
> or false should not result in inconsistent behavior with required fields)
> 
> To state in a different way:
> When INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is TRUE, and you blank 
> out a value for a required field that had previously been populated by the 
> model, submit the form, you will see the OLD data from the model in the 
> field. However, if that field had had a format validation applied to it and 
> the user submits the form with a format validation error, the OLD data is NOT 
> shown in the field (instead, the submitted/invalid data is shown). The same 
> should happen for required field validation errors. The field should show the 
> "blank" data and not the original model data. In order to get the correct 
> behavior, the developer has to currently set 
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to false. But they should not 
> have to do this... whether INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is 
> true or false, the behavior of showing the blank field that the user 
> submitted should be the same.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4141) JSF 2.3 Spec Issue 1436 - MyFaces Implementation requires Server Push functionality

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16165276#comment-16165276
 ] 

Thomas Andraschko commented on MYFACES-4141:


As long as we detect new resources and render it via:

   

MyFaces is fine for me. There is no websocket required.

> JSF 2.3 Spec Issue 1436 - MyFaces Implementation requires Server Push 
> functionality
> ---
>
> Key: MYFACES-4141
> URL: https://issues.apache.org/jira/browse/MYFACES-4141
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
> Fix For: 2.3.0
>
>
> The following spec issue does not look to be implemented in the MyFaces 
> 2.3.0-beta: https://github.com/javaee/javaserverfaces-spec/issues/1436
> The following text was added to the JSF 2.3 specification section 2.2.6 
> "Render Response":
> If running on a container that supports Servlet 4.0 or later, after any 
> dynamic component manipulations have been
> completed, any resources that have been added to the UIViewRoot, such as 
> scripts, images, or stylesheets, and any
> inline images, must be pushed to the client using the Servlet Server Push 
> API. All of the pushes must be started
> before any of the HTML of the response is rendered to the client.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4141) JSF 2.3 Spec Issue 1436 - MyFaces Implementation requires Server Push functionality

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16165218#comment-16165218
 ] 

Thomas Andraschko commented on MYFACES-4141:


+1 Leo
I think we can close this one as its implemented the same in Mojarra and 
MyFaces.
Would someone create a spec ticket for this? Im not sure why this functionality 
is specified in the specs but not implemented in mojarra.

> JSF 2.3 Spec Issue 1436 - MyFaces Implementation requires Server Push 
> functionality
> ---
>
> Key: MYFACES-4141
> URL: https://issues.apache.org/jira/browse/MYFACES-4141
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
> Fix For: 2.3.0
>
>
> The following spec issue does not look to be implemented in the MyFaces 
> 2.3.0-beta: https://github.com/javaee/javaserverfaces-spec/issues/1436
> The following text was added to the JSF 2.3 specification section 2.2.6 
> "Render Response":
> If running on a container that supports Servlet 4.0 or later, after any 
> dynamic component manipulations have been
> completed, any resources that have been added to the UIViewRoot, such as 
> scripts, images, or stylesheets, and any
> inline images, must be pushed to the client using the Servlet Server Push 
> API. All of the pushes must be started
> before any of the HTML of the response is rendered to the client.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4157) Myfaces parses commented code from xhtml and throws property not found exception

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16176362#comment-16176362
 ] 

Thomas Andraschko commented on MYFACES-4157:


Use facelets.SKIP_COMMENTS ;)

> Myfaces parses commented code from xhtml and throws property not found 
> exception
> 
>
> Key: MYFACES-4157
> URL: https://issues.apache.org/jira/browse/MYFACES-4157
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Dora Rajappan
>Priority: Minor
>
> Myfaces parses commented code from xhtml and throws property not found 
> exception.
> Myfaces should ignore commented code.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4153) h:selectOneRadio when rendered inside h:panelGroup which is right aligned stands out from the group

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169731#comment-16169731
 ] 

Thomas Andraschko commented on MYFACES-4153:


Will you provide a patch? A example app would be great if not ;)

> h:selectOneRadio when rendered inside h:panelGroup which is right aligned 
> stands out from the group
> ---
>
> Key: MYFACES-4153
> URL: https://issues.apache.org/jira/browse/MYFACES-4153
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3.0-beta
>Reporter: Dora Rajappan
>Priority: Minor
>
> h:selectOneRadio when rendered inside h:panelGroup which is right aligned 
> stands out from the group towards the left since it gets rendered as html 
> table. This is same behaviour for mojarra 2.2 also.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4154) The browser (chrome) always show the previous page name while its on the current page rendered properly

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169730#comment-16169730
 ] 

Thomas Andraschko commented on MYFACES-4154:


Will you provide a patch? A example app would be great if not ;)

> The browser (chrome) always show the previous page name while its on the 
> current page rendered properly
> ---
>
> Key: MYFACES-4154
> URL: https://issues.apache.org/jira/browse/MYFACES-4154
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Dora Rajappan
>Priority: Minor
>
> The browser (chrome) always show the previous page name while its on the 
> current page rendered properly . This bug is already logged in jira not sure 
> of the bug id. Not sure its browser problem  or jsf. Not checked this with 
> mojarra also.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4160) ViewState not written for Ajax request

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16192541#comment-16192541
 ] 

Thomas Andraschko commented on MYFACES-4160:


cool! :)

> ViewState not written for Ajax request
> --
>
> Key: MYFACES-4160
> URL: https://issues.apache.org/jira/browse/MYFACES-4160
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
> Fix For: 2.3.0
>
>
> If you run the application from MYFACES-4156 via mvn jetty:run, the 
> viewStateId isn't rendered again after the first ajax request.
> Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it 
> skips.
> [~lu4242] Could you please check that?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4160) ViewState not written for Ajax request

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196217#comment-16196217
 ] 

Thomas Andraschko commented on MYFACES-4160:


Also, AFAIR, in PrimeFaces we completly ignore the id attribute of 
partial-response. Not sure if it's correct but PF is working without in a 
normal servlet container + it's working fine in portlets.
We just dynamically prepend the paramater namespace to the dynamic post params 
like "javax.faces.partial.render"

> ViewState not written for Ajax request
> --
>
> Key: MYFACES-4160
> URL: https://issues.apache.org/jira/browse/MYFACES-4160
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
> Fix For: 2.3.0
>
>
> If you run the application from MYFACES-4156 via mvn jetty:run, the 
> viewStateId isn't rendered again after the first ajax request.
> Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it 
> skips.
> [~lu4242] Could you please check that?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4160) ViewState not written for Ajax request

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196191#comment-16196191
 ] 

Thomas Andraschko commented on MYFACES-4160:


+1 to commit it if the sample app in 
https://issues.apache.org/jira/browse/MYFACES-4156 is working fine (you just 
need to download + do mvn clean package jetty:run)

Which JSF - CDI example do you mean? But +1 for a new issue, seems like a real 
error.

Also not sure if we can correctly test the namespaced paramter case as this is 
only used in portlets. Not sure if any portlet container is using MyFaces.


> ViewState not written for Ajax request
> --
>
> Key: MYFACES-4160
> URL: https://issues.apache.org/jira/browse/MYFACES-4160
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
> Fix For: 2.3.0
>
>
> If you run the application from MYFACES-4156 via mvn jetty:run, the 
> viewStateId isn't rendered again after the first ajax request.
> Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it 
> skips.
> [~lu4242] Could you please check that?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4160) ViewState not written for Ajax request

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196210#comment-16196210
 ] 

Thomas Andraschko commented on MYFACES-4160:


Hmm, how did it work in 2.2?
I'm also not sure if we talk about the same "namespacing". I talk about this 
one: https://issues.apache.org/jira/browse/MYFACES-4053



> ViewState not written for Ajax request
> --
>
> Key: MYFACES-4160
> URL: https://issues.apache.org/jira/browse/MYFACES-4160
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
> Fix For: 2.3.0
>
>
> If you run the application from MYFACES-4156 via mvn jetty:run, the 
> viewStateId isn't rendered again after the first ajax request.
> Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it 
> skips.
> [~lu4242] Could you please check that?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196210#comment-16196210
 ] 

Thomas Andraschko edited comment on MYFACES-4160 at 10/8/17 4:38 PM:
-

Hmm, how did it work in 2.2?
I'm also not sure if we talk about the same "namespacing". I talk about this 
one: https://issues.apache.org/jira/browse/MYFACES-4053
I thought that viewroot namespacing should also only happen in portlet 
environments.



was (Author: tandraschko):
Hmm, how did it work in 2.2?
I'm also not sure if we talk about the same "namespacing". I talk about this 
one: https://issues.apache.org/jira/browse/MYFACES-4053



> ViewState not written for Ajax request
> --
>
> Key: MYFACES-4160
> URL: https://issues.apache.org/jira/browse/MYFACES-4160
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
> Fix For: 2.3.0
>
>
> If you run the application from MYFACES-4156 via mvn jetty:run, the 
> viewStateId isn't rendered again after the first ajax request.
> Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it 
> skips.
> [~lu4242] Could you please check that?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197153#comment-16197153
 ] 

Thomas Andraschko commented on MYFACES-4162:


So https://issues.apache.org/jira/projects/MYFACES/issues/MYFACES-4154 is also 
fixed?

> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197062#comment-16197062
 ] 

Thomas Andraschko edited comment on MYFACES-4162 at 10/9/17 2:33 PM:
-

so the navigation is triggered but not via redirect (e.g. ?faces-redirect=true)?
Does the server return a update id="javax.faces.ViewRoot"? (It also happens 
when using update=@all)


was (Author: tandraschko):
so the navigation is triggered but not via redirect (e.g. ?faces-redirect=true)?
Does the server return a update id="javax.faces.ViewRoot"?

> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197062#comment-16197062
 ] 

Thomas Andraschko commented on MYFACES-4162:


so the navigation is triggered but not via redirect (e.g. ?faces-redirect=true)?
Does the server return a update id="javax.faces.ViewRoot"?

> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198517#comment-16198517
 ] 

Thomas Andraschko commented on MYFACES-4162:


Ok, so we also set the status of MYFACES-4154 as fixed?

> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197308#comment-16197308
 ] 

Thomas Andraschko commented on MYFACES-4162:


All right. I will try to have a look at this. Leo seems away since some 
weeks/months.

> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4037) RuntimePermissions required for protected packages when security manager enabled

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198573#comment-16198573
 ] 

Thomas Andraschko commented on MYFACES-4037:


No response since 1,5 years. Should we close it?

> RuntimePermissions required for protected packages when security manager 
> enabled
> 
>
> Key: MYFACES-4037
> URL: https://issues.apache.org/jira/browse/MYFACES-4037
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.2.9
> Environment: Tomcat 8
>Reporter: Neil Richards
>
> Deploying myfaces-example-simple-1.1.14.war with security manager enabled 
> causes AccessControlExceptions as follows:
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass Security 
> Violation, attempt to use Restricted Class: 
> org.apache.catalina.servlets.DefaultServlet
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" 
> "accessClassInPackage.org.apache.catalina.servlets")
>  java.security.AccessControlException: access denied 
> ("java.lang.RuntimePermission" 
> "accessClassInPackage.org.apache.catalina.servlets")
> at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at 
> java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at 
> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1564)
> at 
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1243)
> at 
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1142)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at 
> org.apache.myfaces.ee6.MyFacesContainerInitializer.isDelegatedFacesServlet(MyFacesContainerInitializer.java:280)
> at 
> org.apache.myfaces.ee6.MyFacesContainerInitializer.onStartup(MyFacesContainerInitializer.java:150)
> at 
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5244)
> at 
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147)
> at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725)
> at 
> org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:131)
> at 
> org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:153)
> at 
> org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:143)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:699)
> at 
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717)
> at 
> org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:939)
> at 
> org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1812)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass Security 
> Violation, attempt to use Restricted Class: 
> org.apache.jasper.compiler.JspRuntimeContext
> java.security.AccessControlException: access denied 
> ("java.lang.RuntimePermission" 
> "accessClassInPackage.org.apache.jasper.compiler")
> at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at 
> java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at 
> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1564)
> at 
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1243)
> at 
> org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1142)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at 
> org.apache.myfaces.webapp.Jsp21FacesInitializer.getJspFactory(Jsp21FacesInitializer.java:88)
> at 
> org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:62)
> at 
> org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:172)
> 

[jira] [Updated] (MYFACES-4065) Did not handled empty string while creating the resource

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko updated MYFACES-4065:
---
Resolution: Fixed
  Assignee: Thomas Andraschko
Status: Resolved  (was: Patch Available)

> Did not handled empty string while creating the resource
> 
>
> Key: MYFACES-4065
> URL: https://issues.apache.org/jira/browse/MYFACES-4065
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.2.3
> Environment: Windows, Tomcat
>Reporter: Madhavi T
>Assignee: Thomas Andraschko
>Priority: Minor
> Fix For: 2.2.13, 2.3.0
>
> Attachments: MYFACES-4065.patch
>
>
> java.lang.StringIndexOutOfBoundsException: String index out of range: 0
>   at java.lang.String.charAt(Unknown Source)
>   at 
> org.apache.myfaces.application.ResourceHandlerImpl.createResource(ResourceHandlerImpl.java:118)
>   at 
> javax.faces.application.ResourceHandlerWrapper.createResource(ResourceHandlerWrapper.java:47)
>   at 
> org.apache.myfaces.custom.captcha.CAPTCHAResourceHandlerWrapper.createResource(CAPTCHAResourceHandlerWrapper.java:83)
>   at 
> org.apache.myfaces.tomahawk.resource.UncompressedResourceHandlerWrapper.createResource(UncompressedResourceHandlerWrapper.java:109)
>   at 
> org.apache.myfaces.tomahawk.resource.UncompressedResourceHandlerWrapper.createResource(UncompressedResourceHandlerWrapper.java:61)
>   at 
> org.apache.myfaces.tomahawk.resource.UncompressedResourceHandlerWrapper.createResource(UncompressedResourceHandlerWrapper.java:55)
>   at 
> javax.faces.application.ResourceHandlerWrapper.createResource(ResourceHandlerWrapper.java:35)
>   at 
> org.apache.myfaces.application.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:568)
>   at 
> javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:59)
>   at 
> org.apache.myfaces.custom.captcha.CAPTCHAResourceHandlerWrapper.handleResourceRequest(CAPTCHAResourceHandlerWrapper.java:212)
>   at 
> javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:59)
>   at 
> javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:59)
>   at 
> org.primefaces.application.resource.PrimeResourceHandler.handleResourceRequest(PrimeResourceHandler.java:87)
>   at javax.faces.webapp.FacesServlet.service(FacesServlet.java:190)
>   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.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:357)
>   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:217)
>   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:616)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
>   at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518)
>   at 
> org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java:844)
>   at 
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:673)
>   at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1500)
>   at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1456)
>   at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>   at 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>   at 

[jira] [Commented] (MYFACES-4055) Localized JSF error and information messages not displayed

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198566#comment-16198566
 ] 

Thomas Andraschko commented on MYFACES-4055:


[~lu4242] I think it doesn't hurt if check for for webapplication resources 
first?!

> Localized JSF error and information messages not displayed
> --
>
> Key: MYFACES-4055
> URL: https://issues.apache.org/jira/browse/MYFACES-4055
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-344
>Affects Versions: 2.2.10
> Environment: Java 8, TomEE 7, Primefaces 6.0, Omnifaces 2.3
>Reporter: Petras
>  Labels: localization, messages
> Attachments: full-submit.png, partial-submit.png
>
>
> I have localized JSF error and information messages as described in JSR-344 
> Section "2.5.2.4 Localized Application Messages", which defines how 
> applications may provide own JSF messages,  and prepared resource bundle 
> "javax.faces.Messages". In _faces-config.xml_ I set:
> {{javax.faces.Messages}}.
> But these resources are not always used, when value validation in UI input 
> component fail. Consider the following snippet which illustrates the issue. 
> It contains 2 input text fields, the first one has "required" attribute. The 
> second field is validated using Bean Validation framework:
> {code:xml}
> 
> 
> 
> 
> 
> 
>  value="#{validationModel.requiredClient}" required="true"/>
> 
> 
> 
> 
>  value="#{validationModel.requiredAnnotated}" />
> 
> 
> 
> 
> 
>  actionListener="#{validationModel.save}" >
> 
> 
> 
> 
> {code}
> The backing bean:
> {code:java}
> @Named @RequestScoped
> public class ValidationModel implements DecisionProcessable {
> @NotNull @Length(min = 1, max = 64)
> private String requiredAnnotated;
> private String requiredClient;
> // getters and setters
> public void save() {
> System.out.println(this);
> }
> }
> {code}
> If I click the button "Save", which performs full submit, I get localized 
> error message. If I click "Save (ajax)", which performs partial submit with 
> ajax, the JSF validation error message is not localized.
> I did some debugging and noticed that validation logic uses {{_MessageUtils}} 
> class to obtain resource bundle for the messages, but this utility class uses 
> FacesContext class ClassLoader to find resource bundle. The problem is that 
> this ClassLoader does not always refer to web application classloader. When 
> the partial submit is performed, it refers to Tomcat common classloader, 
> which surely does not see web application resources.
> The fix probably would be the same as implemented in {{MessageUtils}}, which 
> uses Thread.currentThread().getContextClassLoader() on ResourceBundle 
> (MYFACES-338).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (MYFACES-4154) The browser (chrome) always show the previous page name while its on the current page rendered properly

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko resolved MYFACES-4154.

Resolution: Not A Problem

See https://issues.apache.org/jira/browse/MYFACES-4162

> The browser (chrome) always show the previous page name while its on the 
> current page rendered properly
> ---
>
> Key: MYFACES-4154
> URL: https://issues.apache.org/jira/browse/MYFACES-4154
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Dora Rajappan
> Attachments: mf23test.zip
>
>
> The browser (chrome) always show the previous page name while its on the 
> current page rendered properly . This bug is already logged in jira not sure 
> of the bug id. Not sure its browser problem  or jsf. Not checked this with 
> mojarra also.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MYFACES-4122) Auto scroll doesn't work anymore for some environment

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko updated MYFACES-4122:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Fixed in core. Not sure if we need to fix this in tomahawk, too. [~lu4242]?

> Auto scroll doesn't work anymore for some environment
> -
>
> Key: MYFACES-4122
> URL: https://issues.apache.org/jira/browse/MYFACES-4122
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.2.12
>Reporter: Taro App
>Assignee: Thomas Andraschko
> Fix For: 2.0.25, 2.1.19, 2.2.13, 2.3.0
>
> Attachments: HtmlJavaScriptUtils.java.patch
>
>
> Auto Scroll doesn't work anymore for some environment. This is because auto 
> scroll code assumes scroll position to be integer value where some browsers 
> begin to return floating numbers. See 
> org.apache.myfaces.shared.renderkit.html.HtmlJavaScriptUtils.getAutoScrollFunction
>  where it parses scroll positions assuming they are integers, and if not, it 
> ignores those values and prints out error "Error getting y offset for 
> autoscroll feature. Bad param value"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3805) check handling of serializable converters and validators

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198575#comment-16198575
 ] 

Thomas Andraschko commented on MYFACES-3805:


Is this still an issue for 2.3 or can we close it?

> check handling of serializable converters and validators
> 
>
> Key: MYFACES-3805
> URL: https://issues.apache.org/jira/browse/MYFACES-3805
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-344
>Affects Versions: 2.2.0
>Reporter: Gerhard Petracek
>Assignee: Leonardo Uribe
>
> it doesn't work as specified in paragraph 7.8.1.
> once we change something here, we also have to handle it for MYFACES-3797.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4163) h:commandScript execute attribute does not have a default value

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203420#comment-16203420
 ] 

Thomas Andraschko commented on MYFACES-4163:


[~werpu] Could have a look at the commandScript? The ajax request itself works 
fine, also the action on the server side is executed but the firefox console 
gives this error:
getAttributeNode() sollte nicht mehr verwendet werden. Verwenden Sie 
stattdessen getAttribute().  jsf.js.xhtml:1:67765

and

TypeError: this._Dom is undefined
Stack-Trace:
_applyJSFArtifactValueToForm/<@http://localhost:8080/javax.faces.resource/jsf.js.xhtml?ln=javax.faces:1:91505
arrForEach@http://localhost:8080/javax.faces.resource/jsf.js.xhtml?ln=javax.faces:1:40040
_applyJSFArtifactValueToForm@http://localhost:8080/javax.faces.resource/jsf.js.xhtml?ln=javax.faces:1:91469
_updateJSFClientArtifacts@http://localhost:8080/javax.faces.resource/jsf.js.xhtml?ln=javax.faces:1:92089
fixViewStates@http://localhost:8080/javax.faces.resource/jsf.js.xhtml?ln=javax.faces:1:91005
processResponse@http://localhost:8080/javax.faces.resource/jsf.js.xhtml?ln=javax.faces:1:90589
response@http://localhost:8080/javax.faces.resource/jsf.js.xhtml?ln=javax.faces:1:109187
jsf.ajaxhttp://localhost:8080/javax.faces.resource/jsf.js.xhtml?ln=javax.faces:1:113449
onsuccess@http://localhost:8080/javax.faces.resource/jsf.js.xhtml?ln=javax.faces:1:85007
hitch/<@http://localhost:8080/javax.faces.resource/jsf.js.xhtml?ln=javax.faces:1:38871

> h:commandScript execute attribute does not have a default value
> ---
>
> Key: MYFACES-4163
> URL: https://issues.apache.org/jira/browse/MYFACES-4163
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Assignee: Thomas Andraschko
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: CommandScript.war
>
>
> The vdldoc for the h:commandScript component state that "@this" should be the 
> default value for the "execute" attribute. 
> The excerpt from the execute attribute description in 
> vdldocs/facelets/h/commandScript.html is:
> ---
> This is a space separated list of client identifiers of components that will 
> participate in the "execute" portion of the Request Processing Lifecycle. If 
> a literal is specified the identifiers must be space delimited. Any of the 
> keywords "@this", "@form", "@all", "@none" may be specified in the identifier 
> list. *If not specified, the default value of "@this" is assumed.* For 
> example, @this clientIdOne clientIdTwo.
> ---
> When I specify the component like this (without an execute attribute):
> {code:java}
> 
>  action="#{commandScriptBean.testCommandScript('success')}" render=":output1" 
> autorun="true"/>
> 
> 
> {code}
> I receive the following exception:
> {noformat}
>  java.lang.NullPointerException
>   at 
> org.apache.myfaces.renderkit.html.HtmlCommandScriptRenderer.getCollectionFromSpaceSplitString(HtmlCommandScriptRenderer.java:690)
>   at 
> org.apache.myfaces.renderkit.html.HtmlCommandScriptRenderer.encodeBegin(HtmlCommandScriptRenderer.java:144)
>   at 
> javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:597)
>   at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:527)
>   at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551)
>   at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551)
>   at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551)
>   at 
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1898)
>   at 
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:315)
>   at 
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:73)
>   at 
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:117)
>   at 
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:267)
>   at javax.faces.webapp.FacesServlet.service(FacesServlet.java:206)
> {noformat}
> When I try the same example using the Mojarra RI, it works as expected.  
> I tried this with the MyFaces 2.3.0-beta and also several snapshots however, 
> the issue still occurs.  The latest snapshot I tried was the 
> 20171010.124738-264 version of the impl.  
> I will upload a sample application to help reproduce the issue.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (MYFACES-4163) h:commandScript execute attribute does not have a default value

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko reopened MYFACES-4163:


> h:commandScript execute attribute does not have a default value
> ---
>
> Key: MYFACES-4163
> URL: https://issues.apache.org/jira/browse/MYFACES-4163
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Assignee: Thomas Andraschko
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: CommandScript.war
>
>
> The vdldoc for the h:commandScript component state that "@this" should be the 
> default value for the "execute" attribute. 
> The excerpt from the execute attribute description in 
> vdldocs/facelets/h/commandScript.html is:
> ---
> This is a space separated list of client identifiers of components that will 
> participate in the "execute" portion of the Request Processing Lifecycle. If 
> a literal is specified the identifiers must be space delimited. Any of the 
> keywords "@this", "@form", "@all", "@none" may be specified in the identifier 
> list. *If not specified, the default value of "@this" is assumed.* For 
> example, @this clientIdOne clientIdTwo.
> ---
> When I specify the component like this (without an execute attribute):
> {code:java}
> 
>  action="#{commandScriptBean.testCommandScript('success')}" render=":output1" 
> autorun="true"/>
> 
> 
> {code}
> I receive the following exception:
> {noformat}
>  java.lang.NullPointerException
>   at 
> org.apache.myfaces.renderkit.html.HtmlCommandScriptRenderer.getCollectionFromSpaceSplitString(HtmlCommandScriptRenderer.java:690)
>   at 
> org.apache.myfaces.renderkit.html.HtmlCommandScriptRenderer.encodeBegin(HtmlCommandScriptRenderer.java:144)
>   at 
> javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:597)
>   at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:527)
>   at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551)
>   at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551)
>   at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551)
>   at 
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1898)
>   at 
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:315)
>   at 
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:73)
>   at 
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:117)
>   at 
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:267)
>   at javax.faces.webapp.FacesServlet.service(FacesServlet.java:206)
> {noformat}
> When I try the same example using the Mojarra RI, it works as expected.  
> I tried this with the MyFaces 2.3.0-beta and also several snapshots however, 
> the issue still occurs.  The latest snapshot I tried was the 
> 20171010.124738-264 version of the impl.  
> I will upload a sample application to help reproduce the issue.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4163) h:commandScript execute attribute does not have a default value

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203405#comment-16203405
 ] 

Thomas Andraschko commented on MYFACES-4163:


Fixed it but in generall, we should reimplement the whole renderer.
It's a copy of the AjaxBehaviorRenderer and most of that code is actually not 
required.

> h:commandScript execute attribute does not have a default value
> ---
>
> Key: MYFACES-4163
> URL: https://issues.apache.org/jira/browse/MYFACES-4163
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: CommandScript.war
>
>
> The vdldoc for the h:commandScript component state that "@this" should be the 
> default value for the "execute" attribute. 
> The excerpt from the execute attribute description in 
> vdldocs/facelets/h/commandScript.html is:
> ---
> This is a space separated list of client identifiers of components that will 
> participate in the "execute" portion of the Request Processing Lifecycle. If 
> a literal is specified the identifiers must be space delimited. Any of the 
> keywords "@this", "@form", "@all", "@none" may be specified in the identifier 
> list. *If not specified, the default value of "@this" is assumed.* For 
> example, @this clientIdOne clientIdTwo.
> ---
> When I specify the component like this (without an execute attribute):
> {code:java}
> 
>  action="#{commandScriptBean.testCommandScript('success')}" render=":output1" 
> autorun="true"/>
> 
> 
> {code}
> I receive the following exception:
> {noformat}
>  java.lang.NullPointerException
>   at 
> org.apache.myfaces.renderkit.html.HtmlCommandScriptRenderer.getCollectionFromSpaceSplitString(HtmlCommandScriptRenderer.java:690)
>   at 
> org.apache.myfaces.renderkit.html.HtmlCommandScriptRenderer.encodeBegin(HtmlCommandScriptRenderer.java:144)
>   at 
> javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:597)
>   at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:527)
>   at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551)
>   at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551)
>   at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551)
>   at 
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1898)
>   at 
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:315)
>   at 
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:73)
>   at 
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:117)
>   at 
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:267)
>   at javax.faces.webapp.FacesServlet.service(FacesServlet.java:206)
> {noformat}
> When I try the same example using the Mojarra RI, it works as expected.  
> I tried this with the MyFaces 2.3.0-beta and also several snapshots however, 
> the issue still occurs.  The latest snapshot I tried was the 
> 20171010.124738-264 version of the impl.  
> I will upload a sample application to help reproduce the issue.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (MYFACES-4163) h:commandScript execute attribute does not have a default value

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko resolved MYFACES-4163.

Resolution: Fixed
  Assignee: Thomas Andraschko

> h:commandScript execute attribute does not have a default value
> ---
>
> Key: MYFACES-4163
> URL: https://issues.apache.org/jira/browse/MYFACES-4163
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Assignee: Thomas Andraschko
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: CommandScript.war
>
>
> The vdldoc for the h:commandScript component state that "@this" should be the 
> default value for the "execute" attribute. 
> The excerpt from the execute attribute description in 
> vdldocs/facelets/h/commandScript.html is:
> ---
> This is a space separated list of client identifiers of components that will 
> participate in the "execute" portion of the Request Processing Lifecycle. If 
> a literal is specified the identifiers must be space delimited. Any of the 
> keywords "@this", "@form", "@all", "@none" may be specified in the identifier 
> list. *If not specified, the default value of "@this" is assumed.* For 
> example, @this clientIdOne clientIdTwo.
> ---
> When I specify the component like this (without an execute attribute):
> {code:java}
> 
>  action="#{commandScriptBean.testCommandScript('success')}" render=":output1" 
> autorun="true"/>
> 
> 
> {code}
> I receive the following exception:
> {noformat}
>  java.lang.NullPointerException
>   at 
> org.apache.myfaces.renderkit.html.HtmlCommandScriptRenderer.getCollectionFromSpaceSplitString(HtmlCommandScriptRenderer.java:690)
>   at 
> org.apache.myfaces.renderkit.html.HtmlCommandScriptRenderer.encodeBegin(HtmlCommandScriptRenderer.java:144)
>   at 
> javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:597)
>   at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:527)
>   at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551)
>   at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551)
>   at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551)
>   at 
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1898)
>   at 
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:315)
>   at 
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:73)
>   at 
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:117)
>   at 
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:267)
>   at javax.faces.webapp.FacesServlet.service(FacesServlet.java:206)
> {noformat}
> When I try the same example using the Mojarra RI, it works as expected.  
> I tried this with the MyFaces 2.3.0-beta and also several snapshots however, 
> the issue still occurs.  The latest snapshot I tried was the 
> 20171010.124738-264 version of the impl.  
> I will upload a sample application to help reproduce the issue.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4163) h:commandScript execute attribute does not have a default value

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205512#comment-16205512
 ] 

Thomas Andraschko commented on MYFACES-4163:


Great thanks!

> h:commandScript execute attribute does not have a default value
> ---
>
> Key: MYFACES-4163
> URL: https://issues.apache.org/jira/browse/MYFACES-4163
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Assignee: Werner Punz
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: CommandScript.war, index.xhtml
>
>
> The vdldoc for the h:commandScript component state that "@this" should be the 
> default value for the "execute" attribute. 
> The excerpt from the execute attribute description in 
> vdldocs/facelets/h/commandScript.html is:
> ---
> This is a space separated list of client identifiers of components that will 
> participate in the "execute" portion of the Request Processing Lifecycle. If 
> a literal is specified the identifiers must be space delimited. Any of the 
> keywords "@this", "@form", "@all", "@none" may be specified in the identifier 
> list. *If not specified, the default value of "@this" is assumed.* For 
> example, @this clientIdOne clientIdTwo.
> ---
> When I specify the component like this (without an execute attribute):
> {code:java}
> 
>  action="#{commandScriptBean.testCommandScript('success')}" render=":output1" 
> autorun="true"/>
> 
> 
> {code}
> I receive the following exception:
> {noformat}
>  java.lang.NullPointerException
>   at 
> org.apache.myfaces.renderkit.html.HtmlCommandScriptRenderer.getCollectionFromSpaceSplitString(HtmlCommandScriptRenderer.java:690)
>   at 
> org.apache.myfaces.renderkit.html.HtmlCommandScriptRenderer.encodeBegin(HtmlCommandScriptRenderer.java:144)
>   at 
> javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:597)
>   at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:527)
>   at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551)
>   at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551)
>   at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551)
>   at 
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1898)
>   at 
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:315)
>   at 
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:73)
>   at 
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:117)
>   at 
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:267)
>   at javax.faces.webapp.FacesServlet.service(FacesServlet.java:206)
> {noformat}
> When I try the same example using the Mojarra RI, it works as expected.  
> I tried this with the MyFaces 2.3.0-beta and also several snapshots however, 
> the issue still occurs.  The latest snapshot I tried was the 
> 20171010.124738-264 version of the impl.  
> I will upload a sample application to help reproduce the issue.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4058) ProtectedViewException for a protectedview access while checking the OriginHeader for appContextPath

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205516#comment-16205516
 ] 

Thomas Andraschko commented on MYFACES-4058:


I wonder how its working in Mojarra? Do they also not follow to spec for 100% 
in this case?
 If possible, we should always try to avoid new context params.

> ProtectedViewException for a protectedview access while checking the 
> OriginHeader for appContextPath
> 
>
> Key: MYFACES-4058
> URL: https://issues.apache.org/jira/browse/MYFACES-4058
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.2.6
> Environment: Windows, JSF 2.2
>Reporter: Dinesh Kumar A S
> Attachments: MYFACES-4058.patch
>
>
> Getting ProtectedViewException while accessing a protectedview/xhtml, while 
> checking the OriginHeader for appContextPath..
> SO reference : 
> http://stackoverflow.com/questions/38308431/jsf-2-2-protectedviewexception-due-to-origin-header-and-appcontextpath-mismatch
> Any help is much appreciated.
> Does the "Origin" request-header is supposed to have the appContextPath in 
> the path/urlInfo ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3816) missing window-handling for initial requests

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205553#comment-16205553
 ] 

Thomas Andraschko commented on MYFACES-3816:


I would close it for now.
DeltaSpike delivers much better CLIENTWINDOW modes and it can be easily used.
We should not do the same in MyFaces Core as DeltaSpike also works fine for 
Mojarra.
I think the JSF API is fine here, just doesn't cover all cases. We may try to 
include the DeltaSpike modes into JSF.next.
WDYT?

> missing window-handling for initial requests
> 
>
> Key: MYFACES-3816
> URL: https://issues.apache.org/jira/browse/MYFACES-3816
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-344
>Affects Versions: 2.2.0-beta
>Reporter: Gerhard Petracek
>Assignee: Leonardo Uribe
>
> for an initial request there is no window-id added to the url.
> (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
> -> in case of a page refresh a new window-id will be created and it isn't 
> possible to get back the original one. that can also happen with a 
> page-refresh after multiple requests, if only ajax requests are used.
> that's a major issue for all scopes based on the window-id.
> it can be done with an initial redirect (default in codi) or js (with html5 
> compliant browsers)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3881) CLIENT_WINDOW_MODE generates new windowid even if one exists

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205552#comment-16205552
 ] 

Thomas Andraschko commented on MYFACES-3881:


I would close it for now.
DeltaSpike delivers much better CLIENTWINDOW modes and it can be easily used.
We should not do the same in MyFaces Core as DeltaSpike also works fine for 
Mojarra.
I think the JSF API is fine here, just doesn't cover all cases. We may try to 
include the DeltaSpike modes into JSF.next.
WDYT?

> 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.4.14#64029)

[jira] [Commented] (MYFACES-4153) h:selectOneRadio when rendered inside h:panelGroup which is right aligned stands out from the group

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205549#comment-16205549
 ] 

Thomas Andraschko commented on MYFACES-4153:


No problem. It's known that selectOneRadio renders table, so you just have to 
use correct styling.

> h:selectOneRadio when rendered inside h:panelGroup which is right aligned 
> stands out from the group
> ---
>
> Key: MYFACES-4153
> URL: https://issues.apache.org/jira/browse/MYFACES-4153
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3.0-beta
>Reporter: Dora Rajappan
>Priority: Minor
> Attachments: login.xhtml, mf23test.zip
>
>
> h:selectOneRadio when rendered inside h:panelGroup which is right aligned 
> stands out from the group towards the left since it gets rendered as html 
> table. This is same behaviour for mojarra 2.2 also.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4154) The browser (chrome) always show the previous page name while its on the current page rendered properly

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16193443#comment-16193443
 ] 

Thomas Andraschko commented on MYFACES-4154:


What about a small example?

> The browser (chrome) always show the previous page name while its on the 
> current page rendered properly
> ---
>
> Key: MYFACES-4154
> URL: https://issues.apache.org/jira/browse/MYFACES-4154
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Dora Rajappan
>Priority: Minor
>
> The browser (chrome) always show the previous page name while its on the 
> current page rendered properly . This bug is already logged in jira not sure 
> of the bug id. Not sure its browser problem  or jsf. Not checked this with 
> mojarra also.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4153) h:selectOneRadio when rendered inside h:panelGroup which is right aligned stands out from the group

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16193446#comment-16193446
 ] 

Thomas Andraschko commented on MYFACES-4153:


What about a small example? There are many bean references in your code which i 
can't use. It's surely a small bug which can be replicated with a very small 
xhtml, without any beans.
JFYI: If you would provide a example with this quality in PF, i would just 
close the issue. If someone is willing to solve a issue in his freetime(!), i 
think can expect a good & small example, which shoudln't be much effort for you.

> h:selectOneRadio when rendered inside h:panelGroup which is right aligned 
> stands out from the group
> ---
>
> Key: MYFACES-4153
> URL: https://issues.apache.org/jira/browse/MYFACES-4153
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.3.0-beta
>Reporter: Dora Rajappan
>Priority: Minor
> Attachments: login.xhtml
>
>
> h:selectOneRadio when rendered inside h:panelGroup which is right aligned 
> stands out from the group towards the left since it gets rendered as html 
> table. This is same behaviour for mojarra 2.2 also.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4127) Unexpected exception thrown when FlowMap is injected on a RequestScoped bean

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159439#comment-16159439
 ] 

Thomas Andraschko commented on MYFACES-4127:


[~lu4242] I checked the case and i think we must use @FlowScoped for the 
producer. However, it's not that easy as @FlowScopd can't be used on method.
So probably we must create a second internal FlowScoped or create dynamic 
producer bean. The first approach would be easier.

Maybe you have a good idea to implement this.

> Unexpected exception thrown when FlowMap is injected on a RequestScoped bean
> 
>
> Key: MYFACES-4127
> URL: https://issues.apache.org/jira/browse/MYFACES-4127
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: ConfigItems.java, ELImplicitObjectsViaCDI.war, 
> ELImplicitObjectsViaCDI.war.zip
>
>
> When @FlowMap is injected on a RequestScoped bean, and you try to use that 
> object (which should be null since we are not inside of a flow), an 
> unexpected exception is thrown. This was noted after JIRA issue: 
> https://issues.apache.org/jira/browse/MYFACES-4126
> Caused by: org.jboss.weld.exceptions.IllegalProductException: WELD-52: 
> Cannot return null from a non-dependent producer method: Producer for 
> Producer Method [Map] with qualifiers [@FlowMap @Any] 
> declared as [[UnbackedAnnotatedMethod] @Produces @FlowMap @ApplicationScoped 
> public 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap()] 
> declared on Managed Bean [class 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer] with qualifiers 
> [@Any @Default]
>   at 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap(ApplicationScopeObjectProducer.java:73)
>   StackTrace:
>   at 
> org.jboss.weld.bean.AbstractProducerBean.checkReturnValue(AbstractProducerBean.java:136)
>   at [internal classes]
>   at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
>   at 
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
>   at [internal classes]
>   at java.lang.String.valueOf(String.java:2994)
>   at java.lang.StringBuilder.append(StringBuilder.java:131)
>   at 
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163)
> On Mojarra 2.3, we get a different exception which looks more appropriate.
> org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active 
> contexts for scope type javax.faces.flow.FlowScoped
>   
> org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:623)
>   
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
>   
> org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
>   
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
>   
> org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
>   
> org.jboss.weld.util.Map$1302817811$Proxy$_$$_WeldClientProxy.toString(Unknown 
> Source)
>   java.lang.String.valueOf(String.java:2994)
>   java.lang.StringBuilder.append(StringBuilder.java:131)
>   
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4127) Unexpected exception thrown when FlowMap is injected on a RequestScoped bean

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159486#comment-16159486
 ] 

Thomas Andraschko commented on MYFACES-4127:


Nvm, got a solution which seems to work fine. [~eduardobreijo] please retest.

> Unexpected exception thrown when FlowMap is injected on a RequestScoped bean
> 
>
> Key: MYFACES-4127
> URL: https://issues.apache.org/jira/browse/MYFACES-4127
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: ConfigItems.java, ELImplicitObjectsViaCDI.war, 
> ELImplicitObjectsViaCDI.war.zip
>
>
> When @FlowMap is injected on a RequestScoped bean, and you try to use that 
> object (which should be null since we are not inside of a flow), an 
> unexpected exception is thrown. This was noted after JIRA issue: 
> https://issues.apache.org/jira/browse/MYFACES-4126
> Caused by: org.jboss.weld.exceptions.IllegalProductException: WELD-52: 
> Cannot return null from a non-dependent producer method: Producer for 
> Producer Method [Map] with qualifiers [@FlowMap @Any] 
> declared as [[UnbackedAnnotatedMethod] @Produces @FlowMap @ApplicationScoped 
> public 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap()] 
> declared on Managed Bean [class 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer] with qualifiers 
> [@Any @Default]
>   at 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap(ApplicationScopeObjectProducer.java:73)
>   StackTrace:
>   at 
> org.jboss.weld.bean.AbstractProducerBean.checkReturnValue(AbstractProducerBean.java:136)
>   at [internal classes]
>   at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
>   at 
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
>   at [internal classes]
>   at java.lang.String.valueOf(String.java:2994)
>   at java.lang.StringBuilder.append(StringBuilder.java:131)
>   at 
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163)
> On Mojarra 2.3, we get a different exception which looks more appropriate.
> org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active 
> contexts for scope type javax.faces.flow.FlowScoped
>   
> org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:623)
>   
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
>   
> org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
>   
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
>   
> org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
>   
> org.jboss.weld.util.Map$1302817811$Proxy$_$$_WeldClientProxy.toString(Unknown 
> Source)
>   java.lang.String.valueOf(String.java:2994)
>   java.lang.StringBuilder.append(StringBuilder.java:131)
>   
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4127) Unexpected exception thrown when FlowMap is injected on a RequestScoped bean

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159502#comment-16159502
 ] 

Thomas Andraschko commented on MYFACES-4127:


It should already work now but it would be great if you could review. Also did 
a small refactoring on the packages and some artifacts.
JFYI: there are some tickets which targets 2.3.0 (only 6 left) and it would be 
great if you could check MYFACES-4133.

> Unexpected exception thrown when FlowMap is injected on a RequestScoped bean
> 
>
> Key: MYFACES-4127
> URL: https://issues.apache.org/jira/browse/MYFACES-4127
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
>Assignee: Leonardo Uribe
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: ConfigItems.java, ELImplicitObjectsViaCDI.war, 
> ELImplicitObjectsViaCDI.war.zip
>
>
> When @FlowMap is injected on a RequestScoped bean, and you try to use that 
> object (which should be null since we are not inside of a flow), an 
> unexpected exception is thrown. This was noted after JIRA issue: 
> https://issues.apache.org/jira/browse/MYFACES-4126
> Caused by: org.jboss.weld.exceptions.IllegalProductException: WELD-52: 
> Cannot return null from a non-dependent producer method: Producer for 
> Producer Method [Map] with qualifiers [@FlowMap @Any] 
> declared as [[UnbackedAnnotatedMethod] @Produces @FlowMap @ApplicationScoped 
> public 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap()] 
> declared on Managed Bean [class 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer] with qualifiers 
> [@Any @Default]
>   at 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap(ApplicationScopeObjectProducer.java:73)
>   StackTrace:
>   at 
> org.jboss.weld.bean.AbstractProducerBean.checkReturnValue(AbstractProducerBean.java:136)
>   at [internal classes]
>   at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
>   at 
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
>   at [internal classes]
>   at java.lang.String.valueOf(String.java:2994)
>   at java.lang.StringBuilder.append(StringBuilder.java:131)
>   at 
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163)
> On Mojarra 2.3, we get a different exception which looks more appropriate.
> org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active 
> contexts for scope type javax.faces.flow.FlowScoped
>   
> org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:623)
>   
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
>   
> org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
>   
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
>   
> org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
>   
> org.jboss.weld.util.Map$1302817811$Proxy$_$$_WeldClientProxy.toString(Unknown 
> Source)
>   java.lang.String.valueOf(String.java:2994)
>   java.lang.StringBuilder.append(StringBuilder.java:131)
>   
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (MYFACES-4127) Unexpected exception thrown when FlowMap is injected on a RequestScoped bean

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko resolved MYFACES-4127.

Resolution: Fixed

> Unexpected exception thrown when FlowMap is injected on a RequestScoped bean
> 
>
> Key: MYFACES-4127
> URL: https://issues.apache.org/jira/browse/MYFACES-4127
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
>Assignee: Leonardo Uribe
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: ConfigItems.java, ELImplicitObjectsViaCDI.war, 
> ELImplicitObjectsViaCDI.war.zip
>
>
> When @FlowMap is injected on a RequestScoped bean, and you try to use that 
> object (which should be null since we are not inside of a flow), an 
> unexpected exception is thrown. This was noted after JIRA issue: 
> https://issues.apache.org/jira/browse/MYFACES-4126
> Caused by: org.jboss.weld.exceptions.IllegalProductException: WELD-52: 
> Cannot return null from a non-dependent producer method: Producer for 
> Producer Method [Map] with qualifiers [@FlowMap @Any] 
> declared as [[UnbackedAnnotatedMethod] @Produces @FlowMap @ApplicationScoped 
> public 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap()] 
> declared on Managed Bean [class 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer] with qualifiers 
> [@Any @Default]
>   at 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap(ApplicationScopeObjectProducer.java:73)
>   StackTrace:
>   at 
> org.jboss.weld.bean.AbstractProducerBean.checkReturnValue(AbstractProducerBean.java:136)
>   at [internal classes]
>   at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
>   at 
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
>   at [internal classes]
>   at java.lang.String.valueOf(String.java:2994)
>   at java.lang.StringBuilder.append(StringBuilder.java:131)
>   at 
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163)
> On Mojarra 2.3, we get a different exception which looks more appropriate.
> org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active 
> contexts for scope type javax.faces.flow.FlowScoped
>   
> org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:623)
>   
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
>   
> org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
>   
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
>   
> org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
>   
> org.jboss.weld.util.Map$1302817811$Proxy$_$$_WeldClientProxy.toString(Unknown 
> Source)
>   java.lang.String.valueOf(String.java:2994)
>   java.lang.StringBuilder.append(StringBuilder.java:131)
>   
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4140) NullPointerException instead of InvalidViewIdException

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159835#comment-16159835
 ] 

Thomas Andraschko commented on MYFACES-4140:


Will you fix this [~deki]?

> NullPointerException instead of InvalidViewIdException
> --
>
> Key: MYFACES-4140
> URL: https://issues.apache.org/jira/browse/MYFACES-4140
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Dennis Kieselhorst
>Priority: Minor
> Fix For: 2.3.0
>
>
> In case of an invalid viewId an NPE is thrown instead of 
> InvalidViewIdException. This is reproducible using tobago-example-demo 
> (NavigationTree /content/root-dummy.xhtml).
> {noformat}
> Caused by: java.lang.NullPointerException
> at 
> org.apache.myfaces.application.ViewHandlerImpl.getViewParameterList(ViewHandlerImpl.java:459)
> at 
> org.apache.myfaces.application.ViewHandlerImpl.getBookmarkableURL(ViewHandlerImpl.java:141)
> at 
> javax.faces.application.ViewHandlerWrapper.getBookmarkableURL(ViewHandlerWrapper.java:134)
> at 
> javax.faces.application.ViewHandlerWrapper.getBookmarkableURL(ViewHandlerWrapper.java:134)
> at 
> org.apache.myfaces.tobago.internal.util.RenderUtils.generateUrl(RenderUtils.java:229)
> at 
> org.apache.myfaces.tobago.internal.renderkit.renderer.CommandRendererBase.encodeBegin(CommandRendererBase.java:86)
> at 
> javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:597)
> at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:527)
> at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551)
> at 
> org.apache.myfaces.tobago.internal.renderkit.renderer.TreeRenderer.encodeEnd(TreeRenderer.java:130)
> at 
> javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:675)
> at javax.faces.component.UIData.encodeEnd(UIData.java:1811)
> at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:555)
> at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551)
> at javax.faces.render.Renderer.encodeChildren(Renderer.java:95)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)