[jira] [Updated] (MYFACES-1892) validator element in faces-config should support nested attribute and property definitions

[Dora Rajappan (JIRA)]

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

Dora Rajappan updated MYFACES-1892:
---

Status: Patch Available  (was: Open)

 validator element in faces-config should support nested attribute and 
 property definitions
 --

 Key: MYFACES-1892
 URL: https://issues.apache.org/jira/browse/MYFACES-1892
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.2.3
Reporter: Simon Kitching

 As shown in this dtd:
   http://java.sun.com/dtd/web-facesconfig_1_1.dtd 
 the validator element in a faces-config.xml file should support nested 
 attribute and property elements:
 validator
validator-idxyValidtor/validator-name
validator-classcom.xy.XyValidator/validator-class
property
   property-namelength/property-name
   property-classjava.lang.Integer/property
   default-value40/default-value
/property
 /validator 
 However this appears to never have been implemented in either 1.1.x or 1.2.x 
 of core; only validator-id and validator-class are supported. Note that the 
 equivalent feature exists for converters, and does appear to have been 
 implemented.
 See the digester rules registered in the constructor for class 
   org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl
 Reported by Joerg (superjoerch at gmx.de) on the myfaces user list, 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (MYFACES-3402) Partial Response Writer always returns an ?xml version='1.0' encoding='utf-8'? ignoring the response encoding

[Dora Rajappan (JIRA)]

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

Dora Rajappan updated MYFACES-3402:
---

Status: Patch Available  (was: Open)

 Partial Response Writer always returns an ?xml version='1.0' 
 encoding='utf-8'? ignoring the response encoding
 ---

 Key: MYFACES-3402
 URL: https://issues.apache.org/jira/browse/MYFACES-3402
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 2.0.10, 2.1.4
Reporter: Werner Punz

 While I was testing different ajax encodings I discovered that the Partial 
 Response writer always returns the header listed on the headline of this 
 issue. It ignores simply the original encoding.
 A blackbox test against Mojarra showed in that exact case the proper encoding 
 not UTF-8 static.
 I guess the fix simply should be to make this part of the partial response 
 writer more dynamic and to fetch
 the encoding in from the request header.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (MYFACES-3538) Boguous implementation of the HTTP OPTIONS method

[Dora Rajappan (JIRA)]

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

Dora Rajappan updated MYFACES-3538:
---

Status: Patch Available  (was: Open)

 Boguous implementation of the HTTP OPTIONS method
 -

 Key: MYFACES-3538
 URL: https://issues.apache.org/jira/browse/MYFACES-3538
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.1.7
Reporter: Mark Struberg

 My colleague Christoph Ledl found the following issue in MyFaces:
 
 Wrong implementation of the OPTIONS method
 FacesServlet does not handle OPTIONS (and possilby other methods) correctly.
 It looks like these request are processed like a GET, which is wrong.
 the implementation of FacesServlet.service() does not deal with methods.
 one cheap fix would be to send 405 (SC_METHOD_NOT_ALLOWED) for all 
 unsupported methods like TRACE and OPTIONS.
 another approach would to extend HttpServlet (instead of implementing Servlet)
 and implement only required methods like GET and POST (this would leave the 
 other methods to the default implementation)
 citeation of HttpServlet java doc:
 There's almost no reason to override the service method.
 Likewise, there's almost no reason to override the doOptions and doTrace 
 methods.
 ---
 This materializes in the following Exception:
 Feb 28 17:48:13 j04 [http-8080-exec-14]   ERROR log.LogFilter j04 0 
 43396625FA6E47DF1C03B12B60BF request done OPTIONS 
 /events/ical.xhtml?locale=detoken=488d-1-b7da-f29fcf074 time=749.16ms 
 cpu=610ms ex=IllegalStateException msg=null 
 UA=Microsoft-WebDAV-MiniRedir/6.1.7601
 Feb 28 17:48:13 j04 [http-8080-exec-14]   INFO  log.LogFilter params: 
 token=48b0368d-b7da-f2974 locale=de
 Feb 28 17:48:13 j04 [http-8080-exec-14]   ERROR [/events].[Faces Servlet] 
 Servlet.service() for servlet Faces Servlet threw exception
 Feb 28 17:48:13 j04 java.lang.IllegalStateException
 Feb 28 17:48:13 j04  at 
 org.apache.catalina.connector.ResponseFacade.sendRedirect(ResponseFacade.java:435)
 Feb 28 17:48:13 j04  at 
 org.apache.myfaces.context.servlet.ServletExternalContextImpl.redirect(ServletExternalContextImpl.java:465)
 Feb 28 17:48:13 j04  at 
 org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.DefaultWindowHandler.sendRedirect(DefaultWindowHandler.java:104)
 Feb 28 17:48:13 j04  at 
 sun.reflect.GeneratedMethodAccessor1600.invoke(Unknown Source)
 Feb 28 17:48:13 j04  at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 Feb 28 17:48:13 j04  at java.lang.reflect.Method.invoke(Method.java:597)
 Feb 28 17:48:13 j04  at 
 org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:329)
 Feb 28 17:48:13 j04  at 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:122)
 Most times this method gets used by mobile browsers in smartphones. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (MYFACES-3683) Implement AjaxBehavior resetValues and delay

[Dora Rajappan (JIRA)]

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

Dora Rajappan updated MYFACES-3683:
---

Status: Patch Available  (was: Open)

 Implement AjaxBehavior resetValues and delay
 

 Key: MYFACES-3683
 URL: https://issues.apache.org/jira/browse/MYFACES-3683
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe

 Implement AjaxBehavior resetValues and delay as described in the spec. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-1892) validator element in faces-config should support nested attribute and property definitions

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13639118#comment-13639118
 ] 

Dora Rajappan commented on MYFACES-1892:


A few more file changes FacesConfig,.. need to be patched.And updating 
testcase. Working with this.

 validator element in faces-config should support nested attribute and 
 property definitions
 --

 Key: MYFACES-1892
 URL: https://issues.apache.org/jira/browse/MYFACES-1892
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.2.3
Reporter: Simon Kitching
 Attachments: MYFACES-1892.patch


 As shown in this dtd:
   http://java.sun.com/dtd/web-facesconfig_1_1.dtd 
 the validator element in a faces-config.xml file should support nested 
 attribute and property elements:
 validator
validator-idxyValidtor/validator-name
validator-classcom.xy.XyValidator/validator-class
property
   property-namelength/property-name
   property-classjava.lang.Integer/property
   default-value40/default-value
/property
 /validator 
 However this appears to never have been implemented in either 1.1.x or 1.2.x 
 of core; only validator-id and validator-class are supported. Note that the 
 equivalent feature exists for converters, and does appear to have been 
 implemented.
 See the digester rules registered in the constructor for class 
   org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl
 Reported by Joerg (superjoerch at gmx.de) on the myfaces user list, 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-1892) validator element in faces-config should support nested attribute and property definitions

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13640441#comment-13640441
 ] 

Dora Rajappan commented on MYFACES-1892:


Can I commit this code? I have no developer access to svn

 validator element in faces-config should support nested attribute and 
 property definitions
 --

 Key: MYFACES-1892
 URL: https://issues.apache.org/jira/browse/MYFACES-1892
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.2.3
Reporter: Simon Kitching
 Attachments: MYFACES-1892.patch, MYFACES-1892.patch


 As shown in this dtd:
   http://java.sun.com/dtd/web-facesconfig_1_1.dtd 
 the validator element in a faces-config.xml file should support nested 
 attribute and property elements:
 validator
validator-idxyValidtor/validator-name
validator-classcom.xy.XyValidator/validator-class
property
   property-namelength/property-name
   property-classjava.lang.Integer/property
   default-value40/default-value
/property
 /validator 
 However this appears to never have been implemented in either 1.1.x or 1.2.x 
 of core; only validator-id and validator-class are supported. Note that the 
 equivalent feature exists for converters, and does appear to have been 
 implemented.
 See the digester rules registered in the constructor for class 
   org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl
 Reported by Joerg (superjoerch at gmx.de) on the myfaces user list, 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-1892) validator element in faces-config should support nested attribute and property definitions

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13641628#comment-13641628
 ] 

Dora Rajappan commented on MYFACES-1892:


Not tested with Mojarra. Can I know the version of mojarra and where can I 
download it? Oracles reference implementation formerly Suns? Can I download the 
source to check that?

 validator element in faces-config should support nested attribute and 
 property definitions
 --

 Key: MYFACES-1892
 URL: https://issues.apache.org/jira/browse/MYFACES-1892
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.2.3
Reporter: Simon Kitching
 Attachments: MYFACES-1892-New.patch


 As shown in this dtd:
   http://java.sun.com/dtd/web-facesconfig_1_1.dtd 
 the validator element in a faces-config.xml file should support nested 
 attribute and property elements:
 validator
validator-idxyValidtor/validator-name
validator-classcom.xy.XyValidator/validator-class
property
   property-namelength/property-name
   property-classjava.lang.Integer/property
   default-value40/default-value
/property
 /validator 
 However this appears to never have been implemented in either 1.1.x or 1.2.x 
 of core; only validator-id and validator-class are supported. Note that the 
 equivalent feature exists for converters, and does appear to have been 
 implemented.
 See the digester rules registered in the constructor for class 
   org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl
 Reported by Joerg (superjoerch at gmx.de) on the myfaces user list, 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-1892) validator element in faces-config should support nested attribute and property definitions

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13644492#comment-13644492
 ] 

Dora Rajappan commented on MYFACES-1892:


I tested this fine with guessnumber sample. Will check mojarra 2 has this 
behaviour

 validator element in faces-config should support nested attribute and 
 property definitions
 --

 Key: MYFACES-1892
 URL: https://issues.apache.org/jira/browse/MYFACES-1892
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.2.3
Reporter: Simon Kitching
 Attachments: MYFACES-1892.patch


 As shown in this dtd:
   http://java.sun.com/dtd/web-facesconfig_1_1.dtd 
 the validator element in a faces-config.xml file should support nested 
 attribute and property elements:
 validator
validator-idxyValidtor/validator-name
validator-classcom.xy.XyValidator/validator-class
property
   property-namelength/property-name
   property-classjava.lang.Integer/property
   default-value40/default-value
/property
 /validator 
 However this appears to never have been implemented in either 1.1.x or 1.2.x 
 of core; only validator-id and validator-class are supported. Note that the 
 equivalent feature exists for converters, and does appear to have been 
 implemented.
 See the digester rules registered in the constructor for class 
   org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl
 Reported by Joerg (superjoerch at gmx.de) on the myfaces user list, 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-1892) validator element in faces-config should support nested attribute and property definitions

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13645660#comment-13645660
 ] 

Dora Rajappan commented on MYFACES-1892:


setProperties for validator behaviour is not there for mojarra-2.1.1 . So this 
need not be implemented?

 validator element in faces-config should support nested attribute and 
 property definitions
 --

 Key: MYFACES-1892
 URL: https://issues.apache.org/jira/browse/MYFACES-1892
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.2.3
Reporter: Simon Kitching
 Attachments: MYFACES-1892.patch


 As shown in this dtd:
   http://java.sun.com/dtd/web-facesconfig_1_1.dtd 
 the validator element in a faces-config.xml file should support nested 
 attribute and property elements:
 validator
validator-idxyValidtor/validator-name
validator-classcom.xy.XyValidator/validator-class
property
   property-namelength/property-name
   property-classjava.lang.Integer/property
   default-value40/default-value
/property
 /validator 
 However this appears to never have been implemented in either 1.1.x or 1.2.x 
 of core; only validator-id and validator-class are supported. Note that the 
 equivalent feature exists for converters, and does appear to have been 
 implemented.
 See the digester rules registered in the constructor for class 
   org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl
 Reported by Joerg (superjoerch at gmx.de) on the myfaces user list, 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3716) Implement h:inputFile

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13646516#comment-13646516
 ] 

Dora Rajappan commented on MYFACES-3716:


I start working on this h:inputFile

 Implement h:inputFile
 -

 Key: MYFACES-3716
 URL: https://issues.apache.org/jira/browse/MYFACES-3716
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe

 Implement h:inputFile as described in the spec

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-1892) validator element in faces-config should support nested attribute and property definitions

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13647434#comment-13647434
 ] 

Dora Rajappan commented on MYFACES-1892:


My observation not related to this bug while testing is myface and mojarra not 
behave same way in tag handling, I had to change position of f:view tag closer 
to form tag and farther when using myface and mojarra respectively.

 validator element in faces-config should support nested attribute and 
 property definitions
 --

 Key: MYFACES-1892
 URL: https://issues.apache.org/jira/browse/MYFACES-1892
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.2.3
Reporter: Simon Kitching
 Attachments: MYFACES-1892.patch


 As shown in this dtd:
   http://java.sun.com/dtd/web-facesconfig_1_1.dtd 
 the validator element in a faces-config.xml file should support nested 
 attribute and property elements:
 validator
validator-idxyValidtor/validator-name
validator-classcom.xy.XyValidator/validator-class
property
   property-namelength/property-name
   property-classjava.lang.Integer/property
   default-value40/default-value
/property
 /validator 
 However this appears to never have been implemented in either 1.1.x or 1.2.x 
 of core; only validator-id and validator-class are supported. Note that the 
 equivalent feature exists for converters, and does appear to have been 
 implemented.
 See the digester rules registered in the constructor for class 
   org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl
 Reported by Joerg (superjoerch at gmx.de) on the myfaces user list, 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-1892) validator element in faces-config should support nested attribute and property definitions

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13647511#comment-13647511
 ] 

Dora Rajappan commented on MYFACES-1892:


My observation is UIInput clears properties while restore _validatorList = 
(_DeltaListValidator)
restoreAttachedState(facesContext,values[1]); (that is after 
loading the page when submit is called)
One way to fix this is to reapplyConfiguration after this restore. Or trace the 
converter behaviour exactly and follow for validator.


 validator element in faces-config should support nested attribute and 
 property definitions
 --

 Key: MYFACES-1892
 URL: https://issues.apache.org/jira/browse/MYFACES-1892
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.2.3
Reporter: Simon Kitching
 Attachments: MYFACES-1892.patch


 As shown in this dtd:
   http://java.sun.com/dtd/web-facesconfig_1_1.dtd 
 the validator element in a faces-config.xml file should support nested 
 attribute and property elements:
 validator
validator-idxyValidtor/validator-name
validator-classcom.xy.XyValidator/validator-class
property
   property-namelength/property-name
   property-classjava.lang.Integer/property
   default-value40/default-value
/property
 /validator 
 However this appears to never have been implemented in either 1.1.x or 1.2.x 
 of core; only validator-id and validator-class are supported. Note that the 
 equivalent feature exists for converters, and does appear to have been 
 implemented.
 See the digester rules registered in the constructor for class 
   org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl
 Reported by Joerg (superjoerch at gmx.de) on the myfaces user list, 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3716) Implement h:inputFile

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13651794#comment-13651794
 ] 

Dora Rajappan commented on MYFACES-3716:


Working with HtmlRenderKitImpl

 Implement h:inputFile
 -

 Key: MYFACES-3716
 URL: https://issues.apache.org/jira/browse/MYFACES-3716
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe

 Implement h:inputFile as described in the spec

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3716) Implement h:inputFile

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13652854#comment-13652854
 ] 

Dora Rajappan commented on MYFACES-3716:


standard-faces-config has renderer entry only for InputFile  and not for 
javax.faces.File
renderer
component-familyjavax.faces.Input/component-family
renderer-typejavax.faces.InputFile/renderer-type

renderer-classorg.apache.myfaces.renderkit.html.HtmlInputFileRenderer/renderer-class
  /renderer
  
  2.2 spec says
  Represents an HTML input element of type file.

By default, the rendererType property must be set to javax.faces.File. This 
value can be changed by calling the setRendererType() method.

HtmlInputFileTag sets rendertype to File and this finds no renderer

Should the standard-faces-config file renderer entry to be updated with File or 
change the default rendertype to InputFile in _HtmlInputFile?

WARNING: No Renderer found for component {Component-Path : [Class: javax.faces.c
omponent.UIViewRoot,ViewId: /greeting.jspx][Class: javax.faces.component.html.Ht
mlForm,Id: helloForm][Class: javax.faces.component.html.HtmlInputFile,Id: file]}
 (component-family=javax.faces.Input, renderer-type=javax.faces.File) 

 Implement h:inputFile
 -

 Key: MYFACES-3716
 URL: https://issues.apache.org/jira/browse/MYFACES-3716
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe

 Implement h:inputFile as described in the spec

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-1892) validator element in faces-config should support nested attribute and property definitions

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13652857#comment-13652857
 ] 

Dora Rajappan commented on MYFACES-1892:


created issue here https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1192

 validator element in faces-config should support nested attribute and 
 property definitions
 --

 Key: MYFACES-1892
 URL: https://issues.apache.org/jira/browse/MYFACES-1892
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.2.3
Reporter: Simon Kitching
 Attachments: MYFACES-1892.patch


 As shown in this dtd:
   http://java.sun.com/dtd/web-facesconfig_1_1.dtd 
 the validator element in a faces-config.xml file should support nested 
 attribute and property elements:
 validator
validator-idxyValidtor/validator-name
validator-classcom.xy.XyValidator/validator-class
property
   property-namelength/property-name
   property-classjava.lang.Integer/property
   default-value40/default-value
/property
 /validator 
 However this appears to never have been implemented in either 1.1.x or 1.2.x 
 of core; only validator-id and validator-class are supported. Note that the 
 equivalent feature exists for converters, and does appear to have been 
 implemented.
 See the digester rules registered in the constructor for class 
   org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl
 Reported by Joerg (superjoerch at gmx.de) on the myfaces user list, 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3716) Implement h:inputFile

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13660754#comment-13660754
 ] 

Dora Rajappan commented on MYFACES-3716:


http://www.cs.tut.fi/~jkorpela/forms/file.html#support
Rendering works. Only encodeEnd is pending. Werner punz has implemented decode 
in RendererBase Chrome not submitting file. 

 Implement h:inputFile
 -

 Key: MYFACES-3716
 URL: https://issues.apache.org/jira/browse/MYFACES-3716
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe

 Implement h:inputFile as described in the spec

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3716) Implement h:inputFile

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13665146#comment-13665146
 ] 

Dora Rajappan commented on MYFACES-3716:


Context ... allowCasualMultipartParsing=true tomcat7 users need to set this 
for file upload.
Chrome is submitting file.

According to spec decode behaviour is

Call getParts() on the httpServletRequest. Iterate over the parts. If the 
name property of the current part is equal to the clientId, pass the 
current part to the setSubmittedValue() method of the component. If an 
exception is thrown during the iteration, log the exception and continue.

So the bean should have a type ApplicationPart and not File type for the 
property.

Encode behaviour is pending.

If ProjectStage is not ProjectStage.Production, verify that the enclosing form 
has an enctype attribute whose value is multipart/form-data. If not, add a 
FacesMessage for this component's clientId to the FacesContext stating that 
file upload requires a form with enctype equal to multipart/form-data. If 
ProjectStage is ProjectStage.Production, do not do this verification.

In order not to break the spec

standard-faces-config add renderer entry  for javax.faces.File 
renderer 
component-familyjavax.faces.Input/component-family 
renderer-typejavax.faces.File/renderer-type 

renderer-classorg.apache.myfaces.renderkit.html.HtmlInputFileRenderer/renderer-class
 
  /renderer 
   




 Implement h:inputFile
 -

 Key: MYFACES-3716
 URL: https://issues.apache.org/jira/browse/MYFACES-3716
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe

 Implement h:inputFile as described in the spec

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3716) Implement h:inputFile

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666354#comment-13666354
 ] 

Dora Rajappan commented on MYFACES-3716:


I change the bean to have type part instead of File I get this
va.lang.RuntimeException: Could not restore StateHolder of type 
org.apache.catalina.core.ApplicationPart (missing no-args constructor?)

javax.faces.component.UIComponentBase.restoreAttachedState(UIComponentBase.java:1904)

javax.faces.component._DeltaStateHelper.restoreState(_DeltaStateHelper.java:661)

javax.faces.component.UIComponentBase.restoreState(UIComponentBase.java:2057)

 Implement h:inputFile
 -

 Key: MYFACES-3716
 URL: https://issues.apache.org/jira/browse/MYFACES-3716
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe

 Implement h:inputFile as described in the spec

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3716) Implement h:inputFile

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666357#comment-13666357
 ] 

Dora Rajappan commented on MYFACES-3716:


Added this public void encodeEnd(FacesContext facesContext, UIComponent 
component)
throws IOException
{

super.encodeEnd(facesContext, component);

 if(!facesContext.isProjectStage(ProjectStage.Production))
 {
 String content = ((HttpServletRequest) 
facesContext.getExternalContext().getRequest()).getContentType();
 if(content==null || !content.contains(multipart/form-data)){
 //Add facemessage
 FacesMessage message = new FacesMessage(file upload 
requires a form with enctype equal to multipart/form-data);
 facesContext.addMessage(component.getClientId(), 
message);
 }
 }
}

 Implement h:inputFile
 -

 Key: MYFACES-3716
 URL: https://issues.apache.org/jira/browse/MYFACES-3716
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe

 Implement h:inputFile as described in the spec

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3716) Implement h:inputFile

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666367#comment-13666367
 ] 

Dora Rajappan commented on MYFACES-3716:


I can exclude Part type from restore and avoid this error. So the spec wont be 
broken.

 Implement h:inputFile
 -

 Key: MYFACES-3716
 URL: https://issues.apache.org/jira/browse/MYFACES-3716
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe

 Implement h:inputFile as described in the spec

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (MYFACES-3716) Implement h:inputFile

[Dora Rajappan (JIRA)]

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

Dora Rajappan updated MYFACES-3716:
---

Status: Patch Available  (was: Open)

 Implement h:inputFile
 -

 Key: MYFACES-3716
 URL: https://issues.apache.org/jira/browse/MYFACES-3716
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe

 Implement h:inputFile as described in the spec

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3716) Implement h:inputFile

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13668333#comment-13668333
 ] 

Dora Rajappan commented on MYFACES-3716:


Is it ok to change the api pom file dependency for compiling 
javax.servlet.http.Part ?

 Implement h:inputFile
 -

 Key: MYFACES-3716
 URL: https://issues.apache.org/jira/browse/MYFACES-3716
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
 Attachments: inputfile.patch


 Implement h:inputFile as described in the spec

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3716) Implement h:inputFile

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683328#comment-13683328
 ] 

Dora Rajappan commented on MYFACES-3716:


Thanks for bringing into notice the misunderstanding between the form enctype 
and request content type. Encode just adds a Facesmessage which is Ok since its 
not an exception. Form may not need to have enctype multipart all the time 
though it has inputFile component.

Restore solution with the wrapper is perfect and it works. This patch has the 
changes.

I have not considered ajax behavior just yet. 

 Implement h:inputFile
 -

 Key: MYFACES-3716
 URL: https://issues.apache.org/jira/browse/MYFACES-3716
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
 Attachments: inputfile14Jun2013.patch


 Implement h:inputFile as described in the spec

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (MYFACES-3737) Remove _Html*.class from myface api.jar

[Dora Rajappan (JIRA)]

Dora Rajappan created MYFACES-3737:
--

 Summary: Remove _Html*.class from myface api.jar
 Key: MYFACES-3737
 URL: https://issues.apache.org/jira/browse/MYFACES-3737
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.1.12
 Environment: NA
Reporter: Dora Rajappan
Priority: Trivial


_Html classes are used by the builder plugin and not required to be there in 
api.jar to have it lighter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3716) Implement h:inputFile

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683419#comment-13683419
 ] 

Dora Rajappan commented on MYFACES-3716:


How can I checkin these files?

 Implement h:inputFile
 -

 Key: MYFACES-3716
 URL: https://issues.apache.org/jira/browse/MYFACES-3716
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
 Attachments: inputfile14Jun2013.patch


 Implement h:inputFile as described in the spec

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3683) Implement AjaxBehavior resetValues and delay

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700038#comment-13700038
 ] 

Dora Rajappan commented on MYFACES-3683:


In this scenario updatemodelvalue is called after process partial. Problem is 
in UIInput resetValue method sets LocalValueSet to false and the update model 
ignores the change. So I change UIInput resetValue method to set LocalValueSet 
to true.

 Implement AjaxBehavior resetValues and delay
 

 Key: MYFACES-3683
 URL: https://issues.apache.org/jira/browse/MYFACES-3683
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
 Attachments: MYFACES-3683-delay1.patch, MYFACES-3683-delay2.patch, 
 MYFACES-3683-delay3.patch, resetValuesNew.patch, resetValues.patch


 Implement AjaxBehavior resetValues and delay as described in the spec. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3683) Implement AjaxBehavior resetValues and delay

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13706936#comment-13706936
 ] 

Dora Rajappan commented on MYFACES-3683:


When render=component is not mentioned along with resetValues = true the 
component is not refreshed after resetValues. eg. f:ajax event=click 
execute=userNo resetValues=true 

 Implement AjaxBehavior resetValues and delay
 

 Key: MYFACES-3683
 URL: https://issues.apache.org/jira/browse/MYFACES-3683
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
 Attachments: MYFACES-3683-delay1.patch, MYFACES-3683-delay2.patch, 
 MYFACES-3683-delay3.patch, resetValuesNew.patch, resetValues.patch, 
 UIInput.patch


 Implement AjaxBehavior resetValues and delay as described in the spec. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3717) Implement role attribute in related components and renderers

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730829#comment-13730829
 ] 

Dora Rajappan commented on MYFACES-3717:


role information https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1134

 Implement role attribute in related components and renderers
 --

 Key: MYFACES-3717
 URL: https://issues.apache.org/jira/browse/MYFACES-3717
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (MYFACES-3717) Implement role attribute in related components and renderers

[Dora Rajappan (JIRA)]

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

Dora Rajappan updated MYFACES-3717:
---

Status: Patch Available  (was: Open)

 Implement role attribute in related components and renderers
 --

 Key: MYFACES-3717
 URL: https://issues.apache.org/jira/browse/MYFACES-3717
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3717) Implement role attribute in related components and renderers

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13754868#comment-13754868
 ] 

Dora Rajappan commented on MYFACES-3717:


Changed diff to patch. 

 Implement role attribute in related components and renderers
 --

 Key: MYFACES-3717
 URL: https://issues.apache.org/jira/browse/MYFACES-3717
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
 Attachments: rolepassedthrough.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3717) Implement role attribute in related components and renderers

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13756164#comment-13756164
 ] 

Dora Rajappan commented on MYFACES-3717:


Are you able to apply the patch? This is good enough for most components. 

 Implement role attribute in related components and renderers
 --

 Key: MYFACES-3717
 URL: https://issues.apache.org/jira/browse/MYFACES-3717
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
 Attachments: rolepassedthrough.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3683) Implement AjaxBehavior resetValues and delay

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13764541#comment-13764541
 ] 

Dora Rajappan commented on MYFACES-3683:


Please apply this patch.

 Implement AjaxBehavior resetValues and delay
 

 Key: MYFACES-3683
 URL: https://issues.apache.org/jira/browse/MYFACES-3683
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
 Attachments: MYFACES-3683-delay1.patch, MYFACES-3683-delay2.patch, 
 MYFACES-3683-delay3.patch, resetValuesNew.patch, resetValues.patch, 
 UIInput.patch


 Implement AjaxBehavior resetValues and delay as described in the spec. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3683) Implement AjaxBehavior resetValues and delay

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13768294#comment-13768294
 ] 

Dora Rajappan commented on MYFACES-3683:


Please apply the UIInput.patch that is left out and then only the value is 
reset. When more than one ajax reset request is send javax.faces.partial.render 
param returns only one. For below request javax.faces.partial.render param 
returns only userNo.

h:commandButton type=check id=check  value=check 
   f:ajax event=click execute=userNo resetValues=true render=userNo/
f:ajax event=click execute=userName resetValues=true 
render=userName/
/h:commandButton

Requst header has this formData.

helloForm:userNo:2
helloForm:userName:custom presentation
helloForm_SUBMIT:1
javax.faces.ViewState:RrFAKI8lcND1R4ZMRKwzARHaTOpbn8JtnYLjjPIxee3xkJtlQ+cRADxFWrV+tRFX2E0XEh3Xo2w/GNMC49C4nMAIS0rORlUFGRsj5wWIGWDeBeQaqKd34YRvafwCX8eCoQf7yoSDkad0JbdJpZ6vb4oNaA7U9PjyH4YOQyjKMkbIUATRwBxOYXbuki6wr49famX3YZ5RffB8ajkdd/28qO/+BUNsiL8RQ8u6BA==
javax.faces.behavior.event:click
javax.faces.partial.event:click
javax.faces.source:helloForm:check
javax.faces.partial.ajax:true
javax.faces.partial.resetValues:true
javax.faces.partial.execute:helloForm:userNo
javax.faces.partial.render:helloForm:userNo
helloForm:helloForm

 Implement AjaxBehavior resetValues and delay
 

 Key: MYFACES-3683
 URL: https://issues.apache.org/jira/browse/MYFACES-3683
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
 Attachments: MYFACES-3683-delay1.patch, MYFACES-3683-delay2.patch, 
 MYFACES-3683-delay3.patch, resetValuesNew.patch, resetValues.patch, 
 UIInput.patch


 Implement AjaxBehavior resetValues and delay as described in the spec. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3683) Implement AjaxBehavior resetValues and delay

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770922#comment-13770922
 ] 

Dora Rajappan commented on MYFACES-3683:


This is the behaviour now. Ajax resetValues not visibly resetting value in the 
screen. And avoid setting null value in bean by setLocalValueSet(false). 

When two render requests are given in same request.
h:commandButton type=check id=check  value=check 
   f:ajax event=click  resetValues=true render=userNo userName/ 
/h:commandButton

Form data has the rendervalue concatenated. 
helloForm:userNo:4
helloForm:userName:custom presentation
helloForm_SUBMIT:1
javax.faces.ViewState:t8AgGnkn5YYgJdrcfYkpcDI+enqWb5kivC1elY6UQxZZdvVym1RKOGXfOzUMQpgczZPjCTCjbJpXI2Y+OSth5WJ2FAkP5Kn96/pTExg2Z741vhjO6KMymi7LYaqQP5vOUp1Hm91SBHQbtUXEqMrMc/4Kq6+3miTtfCsNsagbfAgmKvuEvLNsNs7qlopzPI4tMln5LPNolqbMqMliXItghFPVq3AkOAfLJRtL2A==
javax.faces.behavior.event:click
javax.faces.partial.event:click
javax.faces.source:helloForm:check
javax.faces.partial.ajax:true
javax.faces.partial.resetValues:true
javax.faces.partial.execute:helloForm:check
javax.faces.partial.render:helloForm:userNo helloForm:userName
helloForm:helloForm

Are you resolving this then?

 Implement AjaxBehavior resetValues and delay
 

 Key: MYFACES-3683
 URL: https://issues.apache.org/jira/browse/MYFACES-3683
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
 Attachments: MYFACES-3683-delay1.patch, MYFACES-3683-delay2.patch, 
 MYFACES-3683-delay3.patch, resetValuesNew.patch, resetValues.patch, 
 UIInput.patch


 Implement AjaxBehavior resetValues and delay as described in the spec. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3683) Implement AjaxBehavior resetValues and delay

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770934#comment-13770934
 ] 

Dora Rajappan commented on MYFACES-3683:


Ajax reset not resetting the value to null in screen but reverting to previous 
state value which is expected  and hence can be resolved.

 Implement AjaxBehavior resetValues and delay
 

 Key: MYFACES-3683
 URL: https://issues.apache.org/jira/browse/MYFACES-3683
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
 Attachments: MYFACES-3683-delay1.patch, MYFACES-3683-delay2.patch, 
 MYFACES-3683-delay3.patch, resetValuesNew.patch, resetValues.patch, 
 UIInput.patch


 Implement AjaxBehavior resetValues and delay as described in the spec. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3542) The render attribute of AjaxBehavior should support late value expression evaluation

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13776344#comment-13776344
 ] 

Dora Rajappan commented on MYFACES-3542:


The spec has given preference to c:if over ajax and can be corrected otherwise 
it will defeat the purpose of ajax.

 The render attribute of AjaxBehavior should support late value expression 
 evaluation
 

 Key: MYFACES-3542
 URL: https://issues.apache.org/jira/browse/MYFACES-3542
 Project: MyFaces Core
  Issue Type: New Feature
Reporter: Bernd Bohmann
 Attachments: late-render-expression-0.png, 
 late-render-expression-1.png, late-render-expression-2.png, 
 late-render-expression-3.png, late-render-expression-4.png, 
 late-render-expression.tgz


 The render attribute of AjaxBehavior should evaluated during post-back after 
 'Invoke Application' and before 'Render Response'. It's easly to add this 
 feature with a own PartialViewContext. But there is no call to processPartial 
 with 'Invoke Application'. The Phase 'Render Response' is too late if you are 
 using c:if to skip components from the component tree. See attached example 
 app and pictures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3542) The render attribute of AjaxBehavior should support late value expression evaluation

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13776377#comment-13776377
 ] 

Dora Rajappan commented on MYFACES-3542:


This problem may be solved now with the new visit algorithm. Leonardo responded 
before this change. I will check the problem is still there with current jsf 
2.2.

 The render attribute of AjaxBehavior should support late value expression 
 evaluation
 

 Key: MYFACES-3542
 URL: https://issues.apache.org/jira/browse/MYFACES-3542
 Project: MyFaces Core
  Issue Type: New Feature
Reporter: Bernd Bohmann
 Attachments: late-render-expression-0.png, 
 late-render-expression-1.png, late-render-expression-2.png, 
 late-render-expression-3.png, late-render-expression-4.png, 
 late-render-expression.tgz


 The render attribute of AjaxBehavior should evaluated during post-back after 
 'Invoke Application' and before 'Render Response'. It's easly to add this 
 feature with a own PartialViewContext. But there is no call to processPartial 
 with 'Invoke Application'. The Phase 'Render Response' is too late if you are 
 using c:if to skip components from the component tree. See attached example 
 app and pictures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3542) The render attribute of AjaxBehavior should support late value expression evaluation

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13777657#comment-13777657
 ] 

Dora Rajappan commented on MYFACES-3542:


This particular behaviour of evaluating the render ids on the fly and then 
rendering those ids  is not something the spec thought of implementing.   

 The render attribute of AjaxBehavior should support late value expression 
 evaluation
 

 Key: MYFACES-3542
 URL: https://issues.apache.org/jira/browse/MYFACES-3542
 Project: MyFaces Core
  Issue Type: New Feature
Reporter: Bernd Bohmann
 Attachments: late-render-expression-0.png, 
 late-render-expression-1.png, late-render-expression-2.png, 
 late-render-expression-3.png, late-render-expression-4.png, 
 late-render-expression.tgz


 The render attribute of AjaxBehavior should evaluated during post-back after 
 'Invoke Application' and before 'Render Response'. It's easly to add this 
 feature with a own PartialViewContext. But there is no call to processPartial 
 with 'Invoke Application'. The Phase 'Render Response' is too late if you are 
 using c:if to skip components from the component tree. See attached example 
 app and pictures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3542) The render attribute of AjaxBehavior should support late value expression evaluation

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13777676#comment-13777676
 ] 

Dora Rajappan commented on MYFACES-3542:


There is no problem with c:if component behaviour with visit algorithm also. 
Info2 component is in execute and when the checkbox was deselected subsequent 
ajax request test2 got skipped which is expected. If info2 is removed from 
execute ajax render wont skip test2 . Preference is clearly for ajax. I 
misunderstood the problem was with skipping components and not purely for late 
value expression evaluation for render attribute.

 The render attribute of AjaxBehavior should support late value expression 
 evaluation
 

 Key: MYFACES-3542
 URL: https://issues.apache.org/jira/browse/MYFACES-3542
 Project: MyFaces Core
  Issue Type: New Feature
Reporter: Bernd Bohmann
 Attachments: late-render-expression-0.png, 
 late-render-expression-1.png, late-render-expression-2.png, 
 late-render-expression-3.png, late-render-expression-4.png, 
 late-render-expression.tgz


 The render attribute of AjaxBehavior should evaluated during post-back after 
 'Invoke Application' and before 'Render Response'. It's easly to add this 
 feature with a own PartialViewContext. But there is no call to processPartial 
 with 'Invoke Application'. The Phase 'Render Response' is too late if you are 
 using c:if to skip components from the component tree. See attached example 
 app and pictures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13781725#comment-13781725
 ] 

Dora Rajappan commented on MYFACES-3786:


Steps to configure cdi in tomcat 7
http://www.theserverside.com/tutorial/Working-with-CDI-and-JSF-20-on-Tomcat-7-Configuring-Weld

 Web Container injection support should be provided for additional lifecycle 
 artifacts (not just managed beans)
 --

 Key: MYFACES-3786
 URL: https://issues.apache.org/jira/browse/MYFACES-3786
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe

 This issue is all about how to inject beans into jsf artifacts.
 See JSF 2.2 section 5.4.1
 The problem here is in some point we need to give the control to the 
 underlying environment to inject beans into the artifacts, but we don't know 
 much about how to properly do it, so we need to try with examples.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13781787#comment-13781787
 ] 

Dora Rajappan commented on MYFACES-3786:



1. Specify the artifacts apart from managed beans in faces config like below 
and write application and verify these are injectable.
 
+faces-config xmlns=http://java.sun.com/xml/ns/javaee; 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
+  xsi:schemaLocation=http://java.sun.com/xml/ns/javaee 
http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd;
+  version=1.2
+  application
+action-listeneraction-listener1/action-listener
+action-listeneraction-listener2/action-listener
+default-render-kit-iddefault-render-kit-id/default-render-kit-id
+locale-config
+  default-localeaa/default-locale
+  supported-localeaa/supported-locale
+  supported-localebb/supported-locale
+/locale-config
+message-bundlemessage-bundle/message-bundle
+navigation-handlernavigation-handler/navigation-handler
+property-resolverproperty-resolver/property-resolver
+state-managerstate-manager/state-manager
+variable-resolvervariable-resolver/variable-resolver
+view-handlerview-handler/view-handler
+
+!-- 1.2 specific --
+el-resolverel-resolver/el-resolver
+resource-bundle
+  base-namebase-name/base-name
+  varvar/var
+/resource-bundle
+  /application
+  validator
+ validator-idxyValidtor/validator-id
+ 
validator-classorg.apache.myfaces.config.impl.digester.XyValidator/validator-class
+  /validator
+/faces-config


 Web Container injection support should be provided for additional lifecycle 
 artifacts (not just managed beans)
 --

 Key: MYFACES-3786
 URL: https://issues.apache.org/jira/browse/MYFACES-3786
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe

 This issue is all about how to inject beans into jsf artifacts.
 See JSF 2.2 section 5.4.1
 The problem here is in some point we need to give the control to the 
 underlying environment to inject beans into the artifacts, but we don't know 
 much about how to properly do it, so we need to try with examples.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

[Dora Rajappan (JIRA)]

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

Dora Rajappan updated MYFACES-3786:
---

Status: Patch Available  (was: Open)

 Web Container injection support should be provided for additional lifecycle 
 artifacts (not just managed beans)
 --

 Key: MYFACES-3786
 URL: https://issues.apache.org/jira/browse/MYFACES-3786
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe

 This issue is all about how to inject beans into jsf artifacts.
 See JSF 2.2 section 5.4.1
 The problem here is in some point we need to give the control to the 
 underlying environment to inject beans into the artifacts, but we don't know 
 much about how to properly do it, so we need to try with examples.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13785316#comment-13785316
 ] 

Dora Rajappan commented on MYFACES-3786:


And the cdi is not good for PartialViewContext with mojarra 2.2.3. 

 Web Container injection support should be provided for additional lifecycle 
 artifacts (not just managed beans)
 --

 Key: MYFACES-3786
 URL: https://issues.apache.org/jira/browse/MYFACES-3786
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Attachments: cdiPartialViewContext.war, cdiPartialViewContext.zip, 
 cdiValidatorSource.zip, cdiValidator.war


 This issue is all about how to inject beans into jsf artifacts.
 See JSF 2.2 section 5.4.1
 The problem here is in some point we need to give the control to the 
 underlying environment to inject beans into the artifacts, but we don't know 
 much about how to properly do it, so we need to try with examples.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13788058#comment-13788058
 ] 

Dora Rajappan commented on MYFACES-3786:



Additional steps to configure cdi in Tomcat 7

 Tomcat has a read-only JNDI, so Weld can't automatically bind the BeanManager 
extension SPI. To bind the BeanManager into JNDI, you should populate 
META-INF/context.xml in the web root with the following contents: 

Context

   Resource name=BeanManager

  auth=Container

  type=javax.enterprise.inject.spi.BeanManager

  factory=org.jboss.weld.resources.ManagerObjectFactory/

/Context


 and make it available to your deployment by adding this to the bottom 
ofweb.xml: 

resource-env-ref

   resource-env-ref-nameBeanManager/resource-env-ref-name

   resource-env-ref-type

  javax.enterprise.inject.spi.BeanManager

   /resource-env-ref-type

/resource-env-ref

 Tomcat only allows you to bind entries to java:comp/env, so the BeanManager 
will be available at java:comp/env/BeanManager 

 Weld also supports Servlet injection in Tomcat containers. 


 Web Container injection support should be provided for additional lifecycle 
 artifacts (not just managed beans)
 --

 Key: MYFACES-3786
 URL: https://issues.apache.org/jira/browse/MYFACES-3786
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdiValidatorSource.zip, 
 cdiValidator.war


 This issue is all about how to inject beans into jsf artifacts.
 See JSF 2.2 section 5.4.1
 The problem here is in some point we need to give the control to the 
 underlying environment to inject beans into the artifacts, but we don't know 
 much about how to properly do it, so we need to try with examples.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13788073#comment-13788073
 ] 

Dora Rajappan commented on MYFACES-3786:


MYFACES-3797 patch is good for Validator. Though Convertor and Validator is 
excluded from spec 2.2 this solution should work for rest of the artifacts 
which can go in spec 2.2.In the class ExternalArtifactResolver from patch 3797 
add methods for artifacts similar to resolveManagedValidator(ExternalContext, 
Class? extends Validator) use them in respective Impls , (ie for 
PartialViewContextFactory artifact call the resolve method from 
FacesContextImpl). 

 Web Container injection support should be provided for additional lifecycle 
 artifacts (not just managed beans)
 --

 Key: MYFACES-3786
 URL: https://issues.apache.org/jira/browse/MYFACES-3786
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdiValidatorSource.zip, 
 cdiValidator.war


 This issue is all about how to inject beans into jsf artifacts.
 See JSF 2.2 section 5.4.1
 The problem here is in some point we need to give the control to the 
 underlying environment to inject beans into the artifacts, but we don't know 
 much about how to properly do it, so we need to try with examples.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3797) cdi support for converters and validators

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13788108#comment-13788108
 ] 

Dora Rajappan commented on MYFACES-3797:


From core perspective  [~lu4242]  doubts are valid comprehensive. 

 cdi support for converters and validators
 -

 Key: MYFACES-3797
 URL: https://issues.apache.org/jira/browse/MYFACES-3797
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-344
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Attachments: MYFACES-3797.patch


 with
 context-param
 
 param-nameorg.apache.myfaces.CONVERTER_INJECTION_ENABLED/param-name
 param-valuetrue/param-value
 /context-param
 and
 context-param
 
 param-nameorg.apache.myfaces.VALIDATOR_INJECTION_ENABLED/param-name
 param-valuetrue/param-value
 /context-param
 it should be possible to enable cdi support for converters/validators.
 we need the config, because it was postponed for the spec.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (MYFACES-3797) cdi support for converters and validators

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13788108#comment-13788108
 ] 

Dora Rajappan edited comment on MYFACES-3797 at 10/7/13 12:39 PM:
--

From core perspective  [~lu4242]  doubts are valid and comprehensive. 


was (Author: dorarajappan):
From core perspective  [~lu4242]  doubts are valid comprehensive. 

 cdi support for converters and validators
 -

 Key: MYFACES-3797
 URL: https://issues.apache.org/jira/browse/MYFACES-3797
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-344
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Attachments: MYFACES-3797.patch


 with
 context-param
 
 param-nameorg.apache.myfaces.CONVERTER_INJECTION_ENABLED/param-name
 param-valuetrue/param-value
 /context-param
 and
 context-param
 
 param-nameorg.apache.myfaces.VALIDATOR_INJECTION_ENABLED/param-name
 param-valuetrue/param-value
 /context-param
 it should be possible to enable cdi support for converters/validators.
 we need the config, because it was postponed for the spec.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13788253#comment-13788253
 ] 

Dora Rajappan commented on MYFACES-3786:


MYFACES-3797 cdi package is very good for ELResolver artifact.

 Web Container injection support should be provided for additional lifecycle 
 artifacts (not just managed beans)
 --

 Key: MYFACES-3786
 URL: https://issues.apache.org/jira/browse/MYFACES-3786
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdiValidatorSource.zip, 
 cdiValidator.war


 This issue is all about how to inject beans into jsf artifacts.
 See JSF 2.2 section 5.4.1
 The problem here is in some point we need to give the control to the 
 underlying environment to inject beans into the artifacts, but we don't know 
 much about how to properly do it, so we need to try with examples.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3797) cdi support for converters and validators

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13788363#comment-13788363
 ] 

Dora Rajappan commented on MYFACES-3797:


Yeah from core perspective specific code in DeltaStateHelper should be avoided 
and should go for wrapper similar to that of inputFile restore. Rest is 
excellent.

 cdi support for converters and validators
 -

 Key: MYFACES-3797
 URL: https://issues.apache.org/jira/browse/MYFACES-3797
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-344
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Attachments: MYFACES-3797.patch


 with
 context-param
 
 param-nameorg.apache.myfaces.CONVERTER_INJECTION_ENABLED/param-name
 param-valuetrue/param-value
 /context-param
 and
 context-param
 
 param-nameorg.apache.myfaces.VALIDATOR_INJECTION_ENABLED/param-name
 param-valuetrue/param-value
 /context-param
 it should be possible to enable cdi support for converters/validators.
 we need the config, because it was postponed for the spec.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3797) cdi support for converters and validators

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13789141#comment-13789141
 ] 

Dora Rajappan commented on MYFACES-3797:


@Gerard code not affect the state handling unlike the part of inputFile which 
required wrapper, but makes validator/convertor  specific code in delta state 
helper.(rest of artifacts at least ie ELResolver, PartialViewContext not go via 
Delta state helper). To avoid specific code in delta state helper, its a good 
idea to use a wrapper in the least or an adapter at the best for supporting 
custom implementations , which was not a requirement for part in the case of 
input file. 

Its a good idea to enable disable injection for Validator/Convertor. But for 
rest of artifacts the spec says if they are just mentioned in the config file 
they are injectable.

 cdi support for converters and validators
 -

 Key: MYFACES-3797
 URL: https://issues.apache.org/jira/browse/MYFACES-3797
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-344
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Attachments: MYFACES-3797_2.patch, MYFACES-3797.patch


 with
 context-param
 
 param-nameorg.apache.myfaces.CONVERTER_INJECTION_ENABLED/param-name
 param-valuetrue/param-value
 /context-param
 and
 context-param
 
 param-nameorg.apache.myfaces.VALIDATOR_INJECTION_ENABLED/param-name
 param-valuetrue/param-value
 /context-param
 it should be possible to enable cdi support for converters/validators.
 we need the config, because it was postponed for the spec.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13789267#comment-13789267
 ] 

Dora Rajappan commented on MYFACES-3786:


CDI is very difficult for customPartialViewContextFactory since the 
FactoryFinder  creates the instance from contructor given below.

Constructor? delegationConstructor = implClass.getConstructor(new Class[] { 
interfaceClass });
// impl class supports decorator pattern,
try
{
// create new decorator wrapping current
current = delegationConstructor.newInstance(new 
Object[] { current });

What happens  in method  getContextualReference(BeanManager beanManager, 
ClassT type)  of ExternalArtifactResolver class  beanManager.getBeans for 
type class guess.RenderExpressionPartialViewContextFactoryImpl return empty set.

I tried with no argument constructor for 
RenderExpressionPartialViewContectFactoryImpl  and cdi works. But its of no 
consequence.

 Web Container injection support should be provided for additional lifecycle 
 artifacts (not just managed beans)
 --

 Key: MYFACES-3786
 URL: https://issues.apache.org/jira/browse/MYFACES-3786
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Attachments: cdiELResolver.patch, cdiELresolverWeb.zip, 
 cdiELResolver.zip, cdipackage.patch, cdiPartialViewContext.war, 
 cdiPartialViewContext.zip, cdi.patch, cdiValidatorSource.zip, cdiValidator.war


 This issue is all about how to inject beans into jsf artifacts.
 See JSF 2.2 section 5.4.1
 The problem here is in some point we need to give the control to the 
 underlying environment to inject beans into the artifacts, but we don't know 
 much about how to properly do it, so we need to try with examples.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13789334#comment-13789334
 ] 

Dora Rajappan commented on MYFACES-3786:


Nice to know how this could work. Thank you for explaining. Deferring it for 
now and going for the next artefact.

 Web Container injection support should be provided for additional lifecycle 
 artifacts (not just managed beans)
 --

 Key: MYFACES-3786
 URL: https://issues.apache.org/jira/browse/MYFACES-3786
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Attachments: cdiELResolver.patch, cdiELresolverWeb.zip, 
 cdiELResolver.zip, cdipackage.patch, cdiPartialViewContext.war, 
 cdiPartialViewContext.zip, cdi.patch, cdiValidatorSource.zip, cdiValidator.war


 This issue is all about how to inject beans into jsf artifacts.
 See JSF 2.2 section 5.4.1
 The problem here is in some point we need to give the control to the 
 underlying environment to inject beans into the artifacts, but we don't know 
 much about how to properly do it, so we need to try with examples.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792687#comment-13792687
 ] 

Dora Rajappan commented on MYFACES-3786:


Unable to apply this patch and verify how this works. I analysed the patch.
CDIAnnotationInjectionProvider class has this 
public void inject(Object instance) throws InjectionProviderException
{
AnnotatedType annoType = beanManager.createAnnotatedType(instance.getClass());
InjectionTarget target = beanManager.createInjectionTarget(annoType);
target.inject(instance, beanManager.createCreationalContext(null));

ExternalArtifactResolver for Validator Converter has this and this gave 
problems with the constructor created instances.
 Bean? bean = beanManager.resolve(beans);
 CreationalContext? creationalContext = 
beanManager.createCreationalContext(bean);

@SuppressWarnings({ unchecked, UnnecessaryLocalVariable })


T result = (T) beanManager.getReference(bean, type, creationalContext);

Its good CDIAnnotationInjectionProvider inject can solve the problem of 
constructor created instances not getting resolved from BeanManager using 
ExternalArtifactResolver.
And this should take care of CDI from jsf.

2.2 spec says container will take care of injection similar to managed beans. 
Hence you have made specific coding for Tomcat to find if tomcat has injected 
the artifacts if not create the instances in jsf. Have to make it generic for 
supporting rest of the containers.


 Web Container injection support should be provided for additional lifecycle 
 artifacts (not just managed beans)
 --

 Key: MYFACES-3786
 URL: https://issues.apache.org/jira/browse/MYFACES-3786
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip, 
 cdiValidator.war, MYFACES-3786-1.patch


  This issue is all about how to inject beans into jsf artifacts.
 See JSF 2.2 section 5.4.1
 The problem here is in some point we need to give the control to the 
 underlying environment to inject beans into the artifacts, but we don't know 
 much about how to properly do it, so we need to try with examples.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792718#comment-13792718
 ] 

Dora Rajappan commented on MYFACES-3786:


According to what @Gerhard via injectionTarget. 
Also the weld reference says
The first thing that a framework developer is going to look for in the 
portable extension SPI is a way to inject CDI
beans into objects which are not under the control of CDI. The InjectionTarget 
interface makes this very easy.

We recommend that frameworks let CDI take over the job of actually 
instantiating the frameworkcontrolled
objects. That way, the framework-controlled objects can take advantage of 
constructor
injection. However, if the framework requires use of a constructor with a 
special signature, the
framework will need to instantiate the object itself, and so only method and 
field injection will be
supported. 

 Web Container injection support should be provided for additional lifecycle 
 artifacts (not just managed beans)
 --

 Key: MYFACES-3786
 URL: https://issues.apache.org/jira/browse/MYFACES-3786
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip, 
 cdiValidator.war, MYFACES-3786-1.patch


  This issue is all about how to inject beans into jsf artifacts.
 See JSF 2.2 section 5.4.1
 The problem here is in some point we need to give the control to the 
 underlying environment to inject beans into the artifacts, but we don't know 
 much about how to properly do it, so we need to try with examples.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792738#comment-13792738
 ] 

Dora Rajappan commented on MYFACES-3786:


jsf2.2 Spec says JSF Implementations that are running as a part of Java EE 5 
(or later) must allow managed bean implementations to use
the annotations specified in section 14.5 of the Servlet 2.5 Specification to 
allow the container to inject references to
container managed resources into a managed bean instance before it is made 
accessible to the JSF application. Only
beans declared to be in request, session, or application scope are eligible for 
resource injection.
In addition to managed beans being injectable in this manner, the following JSF 
artifacts are also injectable.

Container probably can never inject a constructor created instance (ie al teast 
all custom factories) in the manner ManagedBeans are injected. In that sense 
cdi api library cannot be optional for jsf if it wants enable cdi for jsf 
artifacts.



 Web Container injection support should be provided for additional lifecycle 
 artifacts (not just managed beans)
 --

 Key: MYFACES-3786
 URL: https://issues.apache.org/jira/browse/MYFACES-3786
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip, 
 cdiValidator.war, MYFACES-3786-1.patch


  This issue is all about how to inject beans into jsf artifacts.
 See JSF 2.2 section 5.4.1
 The problem here is in some point we need to give the control to the 
 underlying environment to inject beans into the artifacts, but we don't know 
 much about how to properly do it, so we need to try with examples.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792791#comment-13792791
 ] 

Dora Rajappan commented on MYFACES-3786:


Spec never say anything about restriction of annotation scope for jsf 
artifacts. Its inferred that its in application scope which makes sense for 
most of them(except for convertor/validator ..). Also the scope is not required 
to be mentioned in faces-config for the artifacts. 

 Web Container injection support should be provided for additional lifecycle 
 artifacts (not just managed beans)
 --

 Key: MYFACES-3786
 URL: https://issues.apache.org/jira/browse/MYFACES-3786
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdiValidatorSource.zip, 
 cdiValidator.war, MYFACES-3786-1.patch, MYFACES-3786-2.patch


  This issue is all about how to inject beans into jsf artifacts.
 See JSF 2.2 section 5.4.1
 The problem here is in some point we need to give the control to the 
 underlying environment to inject beans into the artifacts, but we don't know 
 much about how to properly do it, so we need to try with examples.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794076#comment-13794076
 ] 

Dora Rajappan commented on MYFACES-3786:


MYFACES-3786-2.patch  is very good. No need to change the priority of 
discovering the injection provider factory. Let it be container first. For all 
of factory artifacts to be injected by container, you can use @Named the parent 
factory impl and the custom implementations can use a dependency injection for 
parentFactory and container can inject those custom factories also. I have 
changed the PhaseListener and ELResolver to use new _callInjectAndPostConstruct 
method in FacesConfigurator in the cdirevised.patch. Validator/Convertor you 
have omitted for this patch.

 Web Container injection support should be provided for additional lifecycle 
 artifacts (not just managed beans)
 --

 Key: MYFACES-3786
 URL: https://issues.apache.org/jira/browse/MYFACES-3786
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch


  This issue is all about how to inject beans into jsf artifacts.
 See JSF 2.2 section 5.4.1
 The problem here is in some point we need to give the control to the 
 underlying environment to inject beans into the artifacts, but we don't know 
 much about how to properly do it, so we need to try with examples.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795121#comment-13795121
 ] 

Dora Rajappan commented on MYFACES-3786:


Sounds to me that you are replicating the scope handling of container in jsf. 
In future everything goes to container and the cdiscope handling become 
obsolete or a failover. And for now this #4 and #5 are equally good. 

But how will you listen to the scope changes in jsf and perform clean up 
#preDestroy? When session expires perform a clean up and also perform the 
cleanup when the application is shutdown, renderesponse phase for view scoped 
instances and so forth. How about request and flowscope clean-ups? How about 
custom scopes?  How will you determine the scope of jsf artifact that is in 
annotation and not even in faces-config to store it against a scope in #4 and 
#5? 

Scoping doubts are applicable for Validator/Convertor.ie a Validator in 
@RequestScoped  Is scope Valid for StateManager or NavigationHandler?

I analysed the patch. 
ListBeanEntry injectedBeanStorage  can be MapClass?, ListBeanEntry 
injectedBeanStorage  for ease of  predestroy by Class? and object.



 Web Container injection support should be provided for additional lifecycle 
 artifacts (not just managed beans)
 --

 Key: MYFACES-3786
 URL: https://issues.apache.org/jira/browse/MYFACES-3786
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch


  This issue is all about how to inject beans into jsf artifacts.
 See JSF 2.2 section 5.4.1
 The problem here is in some point we need to give the control to the 
 underlying environment to inject beans into the artifacts, but we don't know 
 much about how to properly do it, so we need to try with examples.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795131#comment-13795131
 ] 

Dora Rajappan commented on MYFACES-3786:


Is CDI managing javax.enterprise.context scopes? Then no work need to be done 
in jsf for scope.

 Web Container injection support should be provided for additional lifecycle 
 artifacts (not just managed beans)
 --

 Key: MYFACES-3786
 URL: https://issues.apache.org/jira/browse/MYFACES-3786
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch


  This issue is all about how to inject beans into jsf artifacts.
 See JSF 2.2 section 5.4.1
 The problem here is in some point we need to give the control to the 
 underlying environment to inject beans into the artifacts, but we don't know 
 much about how to properly do it, so we need to try with examples.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795180#comment-13795180
 ] 

Dora Rajappan commented on MYFACES-3786:


ListBeanEntry injectedBeanStorage can be MapType, ListBeanEntry 
injectedBeanStorage for ease of predestroy by Type and object since the 
artifacts that are configurable are derived.

 Web Container injection support should be provided for additional lifecycle 
 artifacts (not just managed beans)
 --

 Key: MYFACES-3786
 URL: https://issues.apache.org/jira/browse/MYFACES-3786
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch


  This issue is all about how to inject beans into jsf artifacts.
 See JSF 2.2 section 5.4.1
 The problem here is in some point we need to give the control to the 
 underlying environment to inject beans into the artifacts, but we don't know 
 much about how to properly do it, so we need to try with examples.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795196#comment-13795196
 ] 

Dora Rajappan commented on MYFACES-3786:


True. Instead of putting the injected beans in external context that is in this 
patch put in corresponding scope objects. But the scope of artifacts are not 
known to jsf and better not to support from jsf.

 Web Container injection support should be provided for additional lifecycle 
 artifacts (not just managed beans)
 --

 Key: MYFACES-3786
 URL: https://issues.apache.org/jira/browse/MYFACES-3786
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch


  This issue is all about how to inject beans into jsf artifacts.
 See JSF 2.2 section 5.4.1
 The problem here is in some point we need to give the control to the 
 underlying environment to inject beans into the artifacts, but we don't know 
 much about how to properly do it, so we need to try with examples.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795246#comment-13795246
 ] 

Dora Rajappan commented on MYFACES-3786:


Thank @Gerald for explaining the rule when cdi context management is bypassed. 
Leonardo suggested scope to go in signature in #1 for supporting scope for 
artifacts. But that's not required these jsf aritifcats(Excluding 
Validator/Convertor). There is no way of jsf knowing the scope of these 
artifacts now. #5 is very good  with bean entry having meta data.

 Web Container injection support should be provided for additional lifecycle 
 artifacts (not just managed beans)
 --

 Key: MYFACES-3786
 URL: https://issues.apache.org/jira/browse/MYFACES-3786
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch


  This issue is all about how to inject beans into jsf artifacts.
 See JSF 2.2 section 5.4.1
 The problem here is in some point we need to give the control to the 
 underlying environment to inject beans into the artifacts, but we don't know 
 much about how to properly do it, so we need to try with examples.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3786) Web Container injection support should be provided for additional lifecycle artifacts (not just managed beans)

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795381#comment-13795381
 ] 

Dora Rajappan commented on MYFACES-3786:


Is there a problem sending an object that has no injection annotations to 
beanManager and inject via InjectionTarget ? Will the object remain intact?

 Web Container injection support should be provided for additional lifecycle 
 artifacts (not just managed beans)
 --

 Key: MYFACES-3786
 URL: https://issues.apache.org/jira/browse/MYFACES-3786
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Fix For: 2.2.0

 Attachments: cdiELresolverWeb.zip, cdiELResolver.zip, 
 cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch, 
 cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch, 
 cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch, 
 MYFACES-3786-2.patch, MYFACES-3786_bean-entry_draft_01.patch, 
 MYFACES-3786_internal_bean-entry_draft.patch


  This issue is all about how to inject beans into jsf artifacts.
 See JSF 2.2 section 5.4.1
 The problem here is in some point we need to give the control to the 
 underlying environment to inject beans into the artifacts, but we don't know 
 much about how to properly do it, so we need to try with examples.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3717) Implement role attribute in related components and renderers

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798223#comment-13798223
 ] 

Dora Rajappan commented on MYFACES-3717:


Thanks Leonardo for explaining the logic for h:message and MyFaces junit test 
case for html attributes is good and easy to use.

 Implement role attribute in related components and renderers
 --

 Key: MYFACES-3717
 URL: https://issues.apache.org/jira/browse/MYFACES-3717
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Fix For: 2.2.0

 Attachments: components.patch, MYFACES-3717-rolepassthrough-2.patch, 
 rolepassedthrough.patch, rolepassedthroughtest.patch






--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3716) Implement h:inputFile

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798231#comment-13798231
 ] 

Dora Rajappan commented on MYFACES-3716:


The solution to set the bean with wrapper implementing Part works. You have no 
rule that it should be exactly the Part from the server.

 Implement h:inputFile
 -

 Key: MYFACES-3716
 URL: https://issues.apache.org/jira/browse/MYFACES-3716
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Fix For: 2.2.0

 Attachments: inputFile.patch, MYFACES-3716-fileUpload-2.patch, 
 RendererTest.patch


 Implement h:inputFile as described in the spec



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-1892) validator element in faces-config should support nested attribute and property definitions

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798258#comment-13798258
 ] 

Dora Rajappan commented on MYFACES-1892:


Not got a response for this issue so far. 

 validator element in faces-config should support nested attribute and 
 property definitions
 --

 Key: MYFACES-1892
 URL: https://issues.apache.org/jira/browse/MYFACES-1892
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 1.2.3
Reporter: Simon Kitching
 Attachments: MYFACES-1892.patch


 As shown in this dtd:
   http://java.sun.com/dtd/web-facesconfig_1_1.dtd 
 the validator element in a faces-config.xml file should support nested 
 attribute and property elements:
 validator
validator-idxyValidtor/validator-name
validator-classcom.xy.XyValidator/validator-class
property
   property-namelength/property-name
   property-classjava.lang.Integer/property
   default-value40/default-value
/property
 /validator 
 However this appears to never have been implemented in either 1.1.x or 1.2.x 
 of core; only validator-id and validator-class are supported. Note that the 
 equivalent feature exists for converters, and does appear to have been 
 implemented.
 See the digester rules registered in the constructor for class 
   org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl
 Reported by Joerg (superjoerch at gmx.de) on the myfaces user list, 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (MYFACES-3542) The render attribute of AjaxBehavior should support late value expression evaluation

[Dora Rajappan (JIRA)]

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

Dora Rajappan updated MYFACES-3542:
---

Status: Patch Available  (was: Open)

 The render attribute of AjaxBehavior should support late value expression 
 evaluation
 

 Key: MYFACES-3542
 URL: https://issues.apache.org/jira/browse/MYFACES-3542
 Project: MyFaces Core
  Issue Type: New Feature
Reporter: Bernd Bohmann
 Attachments: late-render-expression-0.png, 
 late-render-expression-1.png, late-render-expression-2.png, 
 late-render-expression-3.png, late-render-expression-4.png, 
 late-render-expression.tgz


 The render attribute of AjaxBehavior should evaluated during post-back after 
 'Invoke Application' and before 'Render Response'. It's easly to add this 
 feature with a own PartialViewContext. But there is no call to processPartial 
 with 'Invoke Application'. The Phase 'Render Response' is too late if you are 
 using c:if to skip components from the component tree. See attached example 
 app and pictures.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3804) Use the same key in server side state saving for ajax requests

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13810496#comment-13810496
 ] 

Dora Rajappan commented on MYFACES-3804:


# 1. This key generation per request for ajax is also fine. Instead of  
changing the logic for ajax just create a key, its the same over head. 
Depending on the max count of NumberOfSequentialViewsInSession these previous 
keys/values are removed from the map. Hence the map size is limited to this 
count. If new key is generated for ajax number of views in the collection goes 
up to max count. Of course using same key can save a few objects in this map. 
Current algorithm is good and you can avoid ViewExpiredException by making ajax 
specific logic.

#2. Ajax redirect  will not add a view in this map. Cause partial rendering of 
the current page is avoided.

@RequestScoped
public class RedirectBean {

public String redirect() {

FacesContext ctx = FacesContext.getCurrentInstance();

ExternalContext extContext = ctx.getExternalContext();
String url = 
extContext.encodeActionURL(ctx.getApplication().getViewHandler().getActionURL(ctx,
 /ajax/redirecttarget.xhtml));
try {

extContext.redirect(url);
} catch (IOException ioe) {
throw new FacesException(ioe);

}
return null;
 
}

h:head
titleAjax Redirect/title
/h:head
h:body
h:form id=form
h:commandButton id=redirect value=Redirect 
action=#{redirectBean.redirect}
 f:ajax execute=@this render=@none/
/h:commandButton
/h:form
/h:body



 Use the same key in server side state saving for ajax requests
 --

 Key: MYFACES-3804
 URL: https://issues.apache.org/jira/browse/MYFACES-3804
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-344
Reporter: Leonardo Uribe

 The current code for server side state saving creates one key per request to 
 store the view state. This is ok, but it is not necessary for ajax requests. 
 The reason why is not necessary is because you can never go back to a page 
 when using ajax. If you are on page A and the current request is an ajax 
 request and it returns to the same page and the view is the same that the one 
 that has been restored, the key or the token sent does not need to change, 
 what changes is the internal state of the view. From the client side the page 
 is the same. We can take advantage of this fact and just update the state 
 stored in SerializedViewCollection for the view. 
 The challenge here is detect when this strategy is applicable. For example, 
 what happen if there is an ajax redirect? It looks is a good idea for 
 implement in 2.2, because it avoids to store unnecessary information into 
 session and optimize the use of each view slot. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3804) Use the same key in server side state saving for ajax requests

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13810542#comment-13810542
 ] 

Dora Rajappan commented on MYFACES-3804:


One good aspect of using the same key for ajax is that it will retain valid 
views in map than redundant ajax views. 

 Use the same key in server side state saving for ajax requests
 --

 Key: MYFACES-3804
 URL: https://issues.apache.org/jira/browse/MYFACES-3804
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-344
Reporter: Leonardo Uribe

 The current code for server side state saving creates one key per request to 
 store the view state. This is ok, but it is not necessary for ajax requests. 
 The reason why is not necessary is because you can never go back to a page 
 when using ajax. If you are on page A and the current request is an ajax 
 request and it returns to the same page and the view is the same that the one 
 that has been restored, the key or the token sent does not need to change, 
 what changes is the internal state of the view. From the client side the page 
 is the same. We can take advantage of this fact and just update the state 
 stored in SerializedViewCollection for the view. 
 The challenge here is detect when this strategy is applicable. For example, 
 what happen if there is an ajax redirect? It looks is a good idea for 
 implement in 2.2, because it avoids to store unnecessary information into 
 session and optimize the use of each view slot. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (MYFACES-3804) Use the same key in server side state saving for ajax requests

[Dora Rajappan (JIRA)]

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

Dora Rajappan updated MYFACES-3804:
---

Status: Patch Available  (was: Open)

 Use the same key in server side state saving for ajax requests
 --

 Key: MYFACES-3804
 URL: https://issues.apache.org/jira/browse/MYFACES-3804
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-344
Reporter: Leonardo Uribe

 The current code for server side state saving creates one key per request to 
 store the view state. This is ok, but it is not necessary for ajax requests. 
 The reason why is not necessary is because you can never go back to a page 
 when using ajax. If you are on page A and the current request is an ajax 
 request and it returns to the same page and the view is the same that the one 
 that has been restored, the key or the token sent does not need to change, 
 what changes is the internal state of the view. From the client side the page 
 is the same. We can take advantage of this fact and just update the state 
 stored in SerializedViewCollection for the view. 
 The challenge here is detect when this strategy is applicable. For example, 
 what happen if there is an ajax redirect? It looks is a good idea for 
 implement in 2.2, because it avoids to store unnecessary information into 
 session and optimize the use of each view slot. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3804) Use the same key in server side state saving for ajax requests

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13811223#comment-13811223
 ] 

Dora Rajappan commented on MYFACES-3804:


Also for for web configuration below the fix is good. 
context-param
  param-namejavax.faces.STATE_SAVING_METHOD/param-name
param-valueclient/param-value
 /context-param

 Use the same key in server side state saving for ajax requests
 --

 Key: MYFACES-3804
 URL: https://issues.apache.org/jira/browse/MYFACES-3804
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-344
Reporter: Leonardo Uribe
 Attachments: ajaxviewkey.patch


 The current code for server side state saving creates one key per request to 
 store the view state. This is ok, but it is not necessary for ajax requests. 
 The reason why is not necessary is because you can never go back to a page 
 when using ajax. If you are on page A and the current request is an ajax 
 request and it returns to the same page and the view is the same that the one 
 that has been restored, the key or the token sent does not need to change, 
 what changes is the internal state of the view. From the client side the page 
 is the same. We can take advantage of this fact and just update the state 
 stored in SerializedViewCollection for the view. 
 The challenge here is detect when this strategy is applicable. For example, 
 what happen if there is an ajax redirect? It looks is a good idea for 
 implement in 2.2, because it avoids to store unnecessary information into 
 session and optimize the use of each view slot. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[Dora Rajappan (JIRA)]

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

Dora Rajappan commented on MYFACES-3816:


What have you decided about the current behaviour of ajax redirect loosing 
state information when changes are executed with redirect? Have you decided to 
flag in redirect and write it in response after save state in rendering phase?

 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.1#6144)

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

[Dora Rajappan (JIRA)]

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

Dora Rajappan commented on MYFACES-3816:


And this behaviour true for redirect via navigation handler. In render phase it 
goes to response complete and state saving is avoided.

h:commandButton action=#{bean.action} value=Invoke and redirect
 f:ajax execute=@this/
 /h:commandButton 

 navigation-rules
 navigation-rule
 from-view-id/form.xhtml/from-view-id
 navigation-case
 from-action#{bean.action}/from-action
 from-outcomesuccess/from-outcome
 to-view-id/target.xhtml/to-view-id
redirect/
 /navigation-case
 /navigation-rule
 /navigation-rules 

 @RequestScoped @ManagedBean
 public class Bean {
 public String action() { return success; }
 } 

I think its a good idea to follow client side state saving behaviour for ajax 
redirect.

 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.1#6144)

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

[Dora Rajappan (JIRA)]

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

Dora Rajappan commented on MYFACES-3816:


The topic about window-handling is different but it exposes a scenario related 
to 3804. Probably this redirect behaviour and server side state handling can be 
included in #3804 or a new jira issue.

 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.1#6144)

[jira] [Commented] (MYFACES-3804) Use the same key in server side state saving for ajax requests

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812783#comment-13812783
 ] 

Dora Rajappan commented on MYFACES-3804:


Including relevant comments from 3816
What have you decided about the current behaviour of ajax redirect loosing 
state information when changes are executed with redirect? Have you decided to 
flag in redirect and write it in response after save state in rendering phase?

And this behaviour true for redirect via navigation handler. In render phase it 
goes to response complete and state saving is avoided.

h:commandButton action=#
{bean.action} value=Invoke and redirect
 f:ajax execute=@this/
 /h:commandButton 

 navigation-rules
 navigation-rule
 from-view-id/form.xhtml/from-view-id
 navigation-case
 from-action#{bean.action} 
/from-action
 from-outcomesuccess/from-outcome
 to-view-id/target.xhtml/to-view-id
 redirect/
 /navigation-case
 /navigation-rule
 /navigation-rules 

@RequestScoped @ManagedBean
 public class Bean {
 public String action() 
{ return success; } 
} 

I think its a good idea to follow client side state saving behaviour for ajax 
redirect. 


 Use the same key in server side state saving for ajax requests
 --

 Key: MYFACES-3804
 URL: https://issues.apache.org/jira/browse/MYFACES-3804
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-344
Reporter: Leonardo Uribe
 Attachments: ajaxviewkey.patch, ajaxviewkeytest.patch, 
 ajaxviewkeytest2.patch


 The current code for server side state saving creates one key per request to 
 store the view state. This is ok, but it is not necessary for ajax requests. 
 The reason why is not necessary is because you can never go back to a page 
 when using ajax. If you are on page A and the current request is an ajax 
 request and it returns to the same page and the view is the same that the one 
 that has been restored, the key or the token sent does not need to change, 
 what changes is the internal state of the view. From the client side the page 
 is the same. We can take advantage of this fact and just update the state 
 stored in SerializedViewCollection for the view. 
 The challenge here is detect when this strategy is applicable. For example, 
 what happen if there is an ajax redirect? It looks is a good idea for 
 implement in 2.2, because it avoids to store unnecessary information into 
 session and optimize the use of each view slot. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (MYFACES-3817) ajax redirect loosing state information when changes are executed with redirect

[Dora Rajappan (JIRA)]

Dora Rajappan created MYFACES-3817:
--

 Summary:  ajax redirect loosing state information when changes are 
executed with redirect
 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan


 Ajax redirect loosing state information when changes are executed with 
redirect.  This can be addressed 
#1 By putting a  flag in redirect and write it in response after save state in 
rendering phase.
#2 This behaviour true for redirect via navigation handler. In render phase it 
goes to response complete and state saving is avoided. When its a redirect not 
make the response complete true and flag it so that in rendering phase state is 
saved.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3817) ajax redirect loosing state information when changes are executed with redirect

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812799#comment-13812799
 ] 

Dora Rajappan commented on MYFACES-3817:


#1 for redirect via ExternalContext
#2 for redirect via NaviagtionHandler.

  ajax redirect loosing state information when changes are executed with 
 redirect
 

 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect loosing state information when changes are executed with 
 redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3804) Use the same key in server side state saving for ajax requests

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812802#comment-13812802
 ] 

Dora Rajappan commented on MYFACES-3804:


I have opened a jira issue 3817 for state saving problem with ajax redirect. 
Once that is fixed the view key fix automatically applies to redirect scenario. 
Shall I commit  this code. This address when there is no key initially in 
client window mode and  an ajax request is made.

 Use the same key in server side state saving for ajax requests
 --

 Key: MYFACES-3804
 URL: https://issues.apache.org/jira/browse/MYFACES-3804
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-344
Reporter: Leonardo Uribe
 Attachments: ajaxviewkey.patch, ajaxviewkeytest.patch, 
 ajaxviewkeytest2.patch


 The current code for server side state saving creates one key per request to 
 store the view state. This is ok, but it is not necessary for ajax requests. 
 The reason why is not necessary is because you can never go back to a page 
 when using ajax. If you are on page A and the current request is an ajax 
 request and it returns to the same page and the view is the same that the one 
 that has been restored, the key or the token sent does not need to change, 
 what changes is the internal state of the view. From the client side the page 
 is the same. We can take advantage of this fact and just update the state 
 stored in SerializedViewCollection for the view. 
 The challenge here is detect when this strategy is applicable. For example, 
 what happen if there is an ajax redirect? It looks is a good idea for 
 implement in 2.2, because it avoids to store unnecessary information into 
 session and optimize the use of each view slot. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3817) ajax redirect loosing state information when changes are executed with redirect

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812817#comment-13812817
 ] 

Dora Rajappan commented on MYFACES-3817:


With Client side state saving the changes executed with ajax redirect are saved 
in state. Hence the same behaviour is expected in server side state saving also.

  ajax redirect loosing state information when changes are executed with 
 redirect
 

 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect loosing state information when changes are executed with 
 redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Comment Edited] (MYFACES-3817) ajax redirect loosing state information when changes are executed with redirect

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812817#comment-13812817
 ] 

Dora Rajappan edited comment on MYFACES-3817 at 11/4/13 4:42 PM:
-

Both client and server side state saving ajax redirect loose changes executed 
with redirect. partial-responseredirect 
url=/portlet-bridge-facelets-guess/guessroleoriginal.jsf/redirect/partial-response
 No state information is sent to the page. In the case of redirect the view is 
built in a different way and you still get the state changes. Hence this bug 
can be closed and need not be handled.


was (Author: dorarajappan):
With Client side state saving the changes executed with ajax redirect are saved 
in state. Hence the same behaviour is expected in server side state saving also.

  ajax redirect loosing state information when changes are executed with 
 redirect
 

 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect loosing state information when changes are executed with 
 redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (MYFACES-3817) ajax redirect loosing state information when changes are executed with redirect

[Dora Rajappan (JIRA)]

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

Dora Rajappan resolved MYFACES-3817.


Resolution: Invalid

When tested it is found that the fix is not required.

  ajax redirect loosing state information when changes are executed with 
 redirect
 

 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect loosing state information when changes are executed with 
 redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3817) ajax redirect loosing state information when changes are executed with redirect

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812994#comment-13812994
 ] 

Dora Rajappan commented on MYFACES-3817:


When ajax redirect is performed from page1 and its redirected to page2. The 
serialisedView is not updated. But when ajax redirect is performed from page2 
to page1 the view is not from serialisedView but in a different way and hence 
it gets the state changes. The bug is not a usability bug but a serialisedView 
inconsistency.

  ajax redirect loosing state information when changes are executed with 
 redirect
 

 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect loosing state information when changes are executed with 
 redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3804) Use the same key in server side state saving for ajax requests

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813896#comment-13813896
 ] 

Dora Rajappan commented on MYFACES-3804:


Thanks for your reply. Let this discussion go in here for ease. 
You are talking about the tab characters in testcase. I will submit new patch 
for that. I had not saved the format.
I am not using checkstyle for now. I will configure it.
I use maven for build/test, svn yes but outside of eclipse.

add() can change to update. I will make that change.

In normal navigation you have a  key and next key for the new view built which 
passed to add of SerialisedViewCollection.
But in the case of ajax and normal navigation same thing happens new view built 
is passed to add of SerialisedViewCollection. What happens now is  in invoke 
application executor the action is processed and navigation handled and next 
view is created and this view is in same execute cycle and this overwrites the 
ajax view and gets rendered with ajax view id in the page. 

Not altering this behaviour above ajaxwithsameviewkey fix is extended to normal 
navigation by means of add instead of update of SerialisedViewCollection. 

 Regarding the condition in restoreSerializedView looks suspicious, this bypass 
is only for ajax request and hence its affects only ajax requests. But I have 
changed code to put the state id in SERVER_STATE_ID and not in SEQUENCE_PARAM.

Is this fine tuning required for ajax since redirect and navigation are avoided 
:)

 Use the same key in server side state saving for ajax requests
 --

 Key: MYFACES-3804
 URL: https://issues.apache.org/jira/browse/MYFACES-3804
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-344
Reporter: Leonardo Uribe
 Attachments: ajaxviewkeytest.patch, ajaxviewkeytest2.patch, 
 ajaxviewsamekey.patch, ajaxviewsamekey2.patch, ajaxviewsamekey3.patch


 The current code for server side state saving creates one key per request to 
 store the view state. This is ok, but it is not necessary for ajax requests. 
 The reason why is not necessary is because you can never go back to a page 
 when using ajax. If you are on page A and the current request is an ajax 
 request and it returns to the same page and the view is the same that the one 
 that has been restored, the key or the token sent does not need to change, 
 what changes is the internal state of the view. From the client side the page 
 is the same. We can take advantage of this fact and just update the state 
 stored in SerializedViewCollection for the view. 
 The challenge here is detect when this strategy is applicable. For example, 
 what happen if there is an ajax redirect? It looks is a good idea for 
 implement in 2.2, because it avoids to store unnecessary information into 
 session and optimize the use of each view slot. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Reopened] (MYFACES-3817) ajax redirect loosing state information when changes are executed with redirect

[Dora Rajappan (JIRA)]

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

Dora Rajappan reopened MYFACES-3817:



Reopening bug with a better test case.

Ajax redirect is loosing state information when changes are executed with 
redirect  normal navigation.

Navigate or Redirect from page1 to page2 through ajax request. And navigate 
(not redirect) from page2 to page1. In this case page1 is built from 
SerialisedViewCollection and it is found that the state changes are lost.

  ajax redirect loosing state information when changes are executed with 
 redirect
 

 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect loosing state information when changes are executed with 
 redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3737) Remove _Html*.class from myface api.jar

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13816051#comment-13816051
 ] 

Dora Rajappan commented on MYFACES-3737:


It is required to add  below in api pom after myfaces-builder-plugin to remove 
unused _Html*.java files from api binary.

plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration

  excludes
 
exclude**/javax/faces/component/html/_Html*.java/exclude
  /excludes
/configuration
  /plugin

 Remove _Html*.class from myface api.jar
 ---

 Key: MYFACES-3737
 URL: https://issues.apache.org/jira/browse/MYFACES-3737
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.1.12
 Environment: NA
Reporter: Dora Rajappan
Priority: Trivial
   Original Estimate: 168h
  Remaining Estimate: 168h

 _Html classes are used by the builder plugin and not required to be there in 
 api.jar to have it lighter.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3737) Remove _Html*.class from myface api.jar

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13821152#comment-13821152
 ] 

Dora Rajappan commented on MYFACES-3737:


Having file names in the exclude list for compilation in the pom is better.

 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-compiler-plugin/artifactId
 configuration

excludes


exclude**/javax/faces/component/html/_HtmlBody.java/exclude


exclude**/javax/faces/component/html/_HtmlColumn.java/exclude 


exclude**/javax/faces/component/html/_HtmlCommandButton.java/exclude


exclude**/javax/faces/component/html/_HtmlCommandLink.java/exclude


exclude**/javax/faces/component/html/_HtmlDataTable.java/exclude


exclude**/javax/faces/component/html/_HtmlDoctype.java/exclude


exclude**/javax/faces/component/html/_HtmlForm.java/exclude


exclude**/javax/faces/component/html/_HtmlGraphicImage.java/exclude


exclude**/javax/faces/component/html/_HtmlHead.java/exclude


exclude**/javax/faces/component/html/_HtmlInputFile.java/exclude


exclude**/javax/faces/component/html/_HtmlInputSecret.java/exclude


exclude**/javax/faces/component/html/_HtmlInputText.java/exclude


exclude**/javax/faces/component/html/_HtmlInputTextarea.java/exclude


exclude**/javax/faces/component/html/_HtmlMessage.java/exclude


exclude**/javax/faces/component/html/_HtmlMessages.java/exclude


exclude**/javax/faces/component/html/_HtmlOutcomeTargetButton.java/exclude


exclude**/javax/faces/component/html/_HtmlOutcomeTargetLink.java/exclude


exclude**/javax/faces/component/html/_HtmlOutputFormat.java/exclude


exclude**/javax/faces/component/html/_HtmlOutputLabel.java/exclude


exclude**/javax/faces/component/html/_HtmlOutputLink.java/exclude


exclude**/javax/faces/component/html/_HtmlOutputText.java/exclude


exclude**/javax/faces/component/html/_HtmlPanelGrid.java/exclude


exclude**/javax/faces/component/html/_HtmlPanelGroup.java/exclude


exclude**/javax/faces/component/html/_HtmlSelectBooleanCheckbox.java/exclude


exclude**/javax/faces/component/html/_HtmlSelectManyCheckbox.java/exclude


exclude**/javax/faces/component/html/_HtmlSelectManyListbox.java/exclude


exclude**/javax/faces/component/html/_HtmlSelectManyMenu.java/exclude


exclude**/javax/faces/component/html/_HtmlSelectOneListbox.java/exclude


exclude**/javax/faces/component/html/_HtmlSelectOneMenu.java/exclude

 

[jira] [Commented] (MYFACES-3817) ajax redirect loosing state information when changes are executed with redirect

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13821228#comment-13821228
 ] 

Dora Rajappan commented on MYFACES-3817:


In order to support NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION it is required to 
save state in Navigation Handler in execute cycle before viewroot is 
overwritten. Not required to flag it and follow till render phase to save state.

  ajax redirect loosing state information when changes are executed with 
 redirect
 

 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect loosing state information when changes are executed with 
 redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3817) ajax redirect/navigation loosing state information when changes are executed with redirect

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13822455#comment-13822455
 ] 

Dora Rajappan commented on MYFACES-3817:


A redirect from page1 is clearing the viewmap and hence the next access to 
page1 cause the view to be built form tree and it get the state change. Not 
sure the spec mentioning to clear the viewmap for redirect. Not sure 
NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION is excluded for redirect. Redirect 
generates a non faces response is mentioned in spec and it can exclude render 
cycle. Spec not mention about viewstate handling for redirect.

  ajax redirect/navigation loosing state information when changes are executed 
 with redirect
 ---

 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect/navigation loosing state information when changes are executed 
 with redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3817) ajax redirect/navigation loosing state information when changes are executed with redirect/navigation

[Dora Rajappan (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13827871#comment-13827871
 ] 

Dora Rajappan commented on MYFACES-3817:


In order not to loose state change for the redirect/navigation if you save 
state in execute cycle before overwrite the viewroot the server side state 
saving remains in good state but with  the client side state saving you simply 
cannot send two separate viewstate information. And that is the reason the 
state is not saved in execute. This conflict has to be addressed. Easiest 
solution is send a viewstate information after state saving and before 
overwriting viewroot and then save the new view and send the response.  For all 
responseComplete navigation cases in execute cycle the overwritten view can be 
saved in execute cycle to avoid ViewExpiredException. And this will not 
conflict the clientside and serverside state saving.

  ajax redirect/navigation loosing state information when changes are executed 
 with redirect/navigation
 --

 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect/navigation loosing state information when changes are executed 
 with redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (MYFACES-3817) ajax redirect/navigation loosing state information when changes are executed with redirect/navigation

[Dora Rajappan (JIRA)]

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

Dora Rajappan resolved MYFACES-3817.


Resolution: Fixed

ViewExpiredException is fixed. state change under these conditions is lost due 
to overwrite and not supported this time for client and server side state 
saving to remain in sync.

  ajax redirect/navigation loosing state information when changes are executed 
 with redirect/navigation
 --

 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect/navigation loosing state information when changes are executed 
 with redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (MYFACES-3737) Remove _Html*.class from myface api.jar

[Dora Rajappan (JIRA)]

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

Dora Rajappan resolved MYFACES-3737.


Resolution: Fixed

Api pom is changed and api.jar not containing the _Html* classes that are only 
required for myfaces builder plugin.

 Remove _Html*.class from myface api.jar
 ---

 Key: MYFACES-3737
 URL: https://issues.apache.org/jira/browse/MYFACES-3737
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.1.12
 Environment: NA
Reporter: Dora Rajappan
Priority: Trivial
   Original Estimate: 168h
  Remaining Estimate: 168h

 _Html classes are used by the builder plugin and not required to be there in 
 api.jar to have it lighter.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Reopened] (MYFACES-3817) ajax redirect/navigation loosing state information when changes are executed with redirect/navigation

[Dora Rajappan (JIRA)]

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

Dora Rajappan reopened MYFACES-3817:



According to http://myfaces.apache.org/core21/myfaces-impl/webconfig.html 
NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION  include redirect.

org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION 2.0.6  Indicates the 
amount of views (default is not active) that should be stored in session 
between sequential POST or POST-REDIRECT-GET if org .

Hence the in NavigationHandler the viewmap need not be cleared for redirect. 
After redirect from page1 to page2 subsequent navigation to page1 can fetch the 
view from viewmap when serialisation is applied. Now it fetches the view from 
tree.





  ajax redirect/navigation loosing state information when changes are executed 
 with redirect/navigation
 --

 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect/navigation loosing state information when changes are executed 
 with redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Updated] (MYFACES-3817) ajax redirect/navigation loosing state information when changes are executed with redirect/navigation

[Dora Rajappan (JIRA)]

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

Dora Rajappan updated MYFACES-3817:
---

Status: Patch Available  (was: Reopened)

  ajax redirect/navigation loosing state information when changes are executed 
 with redirect/navigation
 --

 Key: MYFACES-3817
 URL: https://issues.apache.org/jira/browse/MYFACES-3817
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.0-beta
 Environment: Windows 8
Reporter: Dora Rajappan
   Original Estimate: 0.8h
  Remaining Estimate: 0.8h

  Ajax redirect/navigation loosing state information when changes are executed 
 with redirect.  This can be addressed 
 #1 By putting a  flag in redirect and write it in response after save state 
 in rendering phase.
 #2 This behaviour true for redirect via navigation handler. In render phase 
 it goes to response complete and state saving is avoided. When its a redirect 
 not make the response complete true and flag it so that in rendering phase 
 state is saved.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] Dora Rajappan shared MYFACES-3816: missing window-handling for initial requests with you

[Dora Rajappan (JIRA)]

Dora Rajappan shared an issue with you


Hi, 

I tried the redirect but  jsf is not able to support it now. 
externaltContext.redirect(url) makes it response complete and ajax request will 
not get processed. Question is to have a new method that to makes it not 
response complete. If its not made response complete also jsf cannot send 
consecutive responses in one request lifecycle.

Regards,
Dora Rajappan

 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.2#6252)

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

[Dora Rajappan (JIRA)]

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

Dora Rajappan commented on MYFACES-4127:


If the  
FacesContext.getCurrentInstance().getApplication().getFlowHandler().getCurrentFlowScope()
 returns null for various reasons (includes invalid declarations such as 
postconstruct method in which case session will be null, or when its not inside 
a flow window will be null ); cdi throws the said exception. How to notify CDI 
whats the reason for the nulls will solve the problem. Need to throw 
appropriate exceptions from getCurrentFlowScope method so cdi can capture it 
show meaningful exception to the user.

> 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
> Attachments: ConfigItems.java
>
>
> 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

[Dora Rajappan (JIRA)]

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

Dora Rajappan commented on MYFACES-4127:


Myfaces CDI integration to route the call via 
DefaultContextualInstanceStrategy.getIfExists rather than via 
DefaultContextualInstanceStrategy.get to show the ContextNotActiveException. 
Throwing ContextNotActiveException from FlowHandlerImpl (public Flow 
getCurrentFlow(FacesContext context)) when window is null fails lifecycle 
execute testcase. Hence not an option.

> 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
> Attachments: ConfigItems.java
>
>
> 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-4129) When @FacesConfig annotation is used in a CDI bean, implicit EL objects don't work

[Dora Rajappan (JIRA)]

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

Dora Rajappan commented on MYFACES-4129:


Applied patch and built 2.3.0  , deployed the war and tested this with pluto 
3.0.0. Application scope is fine.

> When @FacesConfig annotation is used in a CDI bean, implicit EL objects don't 
> work
> --
>
> Key: MYFACES-4129
> URL: https://issues.apache.org/jira/browse/MYFACES-4129
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
> Attachments: ImplicitELObjects.war, MYFACES-4129.patch
>
>
> When the @javax.faces.annotation.FacesConfig annotation is used in a CDI 
> bean, the implicit EL Objects from JSF 2.3 spec section 5.9.2 don't work. 
> This is because when that FacesConfig annotation is in a bean we remove the 
> implicit EL resolver from the chain so we don't have any mechanism for CDI to 
> do the resolution of the implicit objects.
> Tested this on Mojarra and it works fine, with or without @FacesConfig 
> annotation.
> A sample app is provided. It can be deployed on tomcat:
> 1) Drive a request to: http://localhost:8080/ImplicitELObjects/index.jsf
> 2) You should see that Application: ApplicationScope: and Component: are 
> empty since they cannot be resolved



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

[jira] [Commented] (MYFACES-4131) begin and end do not look to be implemented / working

[Dora Rajappan (JIRA)]

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

Dora Rajappan commented on MYFACES-4131:


This feature is not implemented in myfaces. Im working out a patch.

>  begin and end do not look to be implemented / working
> --
>
> Key: MYFACES-4131
> URL: https://issues.apache.org/jira/browse/MYFACES-4131
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
>
> I started to test the  constraint feature of JSF 2.3 and it does 
> not look to function on MyFaces. 
> The changes required are for the following JSF 2.3 spec issue : 
> https://github.com/javaee/javaserverfaces-spec/issues/1102
> According to the spec the  tag will now have begin and end 
> attributes. For instance:
> 
> #{x}
> 
> In the above example if testList had 10 items in it each entry containing a 
> number 0-9 then we would expect the following output:
> 0123456789
> If we changed it to:
> 
> #{x}
> 
> We would expect the following output:
> 56789



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

[jira] [Commented] (MYFACES-4131) begin and end do not look to be implemented / working

[Dora Rajappan (JIRA)]

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

Dora Rajappan commented on MYFACES-4131:


Can I commit this in 2.3.x?

>  begin and end do not look to be implemented / working
> --
>
> Key: MYFACES-4131
> URL: https://issues.apache.org/jira/browse/MYFACES-4131
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
> Attachments: MYFACES-4131.patch
>
>
> I started to test the  constraint feature of JSF 2.3 and it does 
> not look to function on MyFaces. 
> The changes required are for the following JSF 2.3 spec issue : 
> https://github.com/javaee/javaserverfaces-spec/issues/1102
> According to the spec the  tag will now have begin and end 
> attributes. For instance:
> 
> #{x}
> 
> In the above example if testList had 10 items in it each entry containing a 
> number 0-9 then we would expect the following output:
> 0123456789
> If we changed it to:
> 
> #{x}
> 
> We would expect the following output:
> 56789



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

[jira] [Commented] (MYFACES-4131) begin and end do not look to be implemented / working

[Dora Rajappan (JIRA)]

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

Dora Rajappan commented on MYFACES-4131:


Thanks Eduardo for committing the patch.

>  begin and end do not look to be implemented / working
> --
>
> Key: MYFACES-4131
> URL: https://issues.apache.org/jira/browse/MYFACES-4131
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
> Fix For: 2.3.0
>
> Attachments: MYFACES-4131-WITH-TEST.patch
>
>
> I started to test the  constraint feature of JSF 2.3 and it does 
> not look to function on MyFaces. 
> The changes required are for the following JSF 2.3 spec issue : 
> https://github.com/javaee/javaserverfaces-spec/issues/1102
> According to the spec the  tag will now have begin and end 
> attributes. For instance:
> 
> #{x}
> 
> In the above example if testList had 10 items in it each entry containing a 
> number 0-9 then we would expect the following output:
> 0123456789
> If we changed it to:
> 
> #{x}
> 
> We would expect the following output:
> 56789



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