[JBoss JIRA] (RF-13323) FileUploadEvent listener reset the list value with Viewscope
by Jiří Štefek (JIRA)
[ https://issues.jboss.org/browse/RF-13323?page=com.atlassian.jira.plugin.s... ]
Jiří Štefek edited comment on RF-13323 at 11/12/13 3:55 AM:
------------------------------------------------------------
I tried this by changing the scope of the _FileUploadBean_ with the latest RF4 showcase on AS 7.1 and EAP 6.1 and uploading the same picture for multiple times.
I have noticed, that when the scope was @ViewScoped:
* uploaded image preview didn't show,
* and encountered an error on the server side:
{code}
ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/showcase].[Faces Servlet]] (http--127.0.0.1-8080-23) Servlet.service() for servlet Faces Servlet threw exception: java.lang.NullPointerException
at com.sun.faces.mgbean.BeanManager$ScopeManager$ViewScopeHandler.getFromScope(BeanManager.java:563) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.mgbean.BeanManager$ScopeManager.getFromScope(BeanManager.java:477) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.mgbean.BeanManager.getBeanFromScope(BeanManager.java:240) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.el.ManagedBeanELResolver.resolveBean(ManagedBeanELResolver.java:242) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.el.ManagedBeanELResolver.getValue(ManagedBeanELResolver.java:116) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) [jsf-impl-2.1.7-jbossorg-2.jar:]
at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72) [jbossweb-7.0.13.Final.jar:]
at org.apache.el.parser.AstValue.getTarget(AstValue.java:94) [jbossweb-7.0.13.Final.jar:]
at org.apache.el.parser.AstValue.invoke(AstValue.java:244) [jbossweb-7.0.13.Final.jar:]
at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:278) [jbossweb-7.0.13.Final.jar:]
at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:39) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.7-jbossorg-2.jar:]
at org.richfaces.resource.MediaOutputResource.encode(MediaOutputResource.java:62) [richfaces-components-ui-4.3.5-20131022.221155-19.jar:4.3.5-SNAPSHOT]
at org.richfaces.resource.UserResourceWrapperImpl.encode(UserResourceWrapperImpl.java:188) [richfaces-core-impl-4.3.5-20131022.070629-12.jar:4.3.5-SNAPSHOT]
at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:229) [richfaces-core-impl-4.3.5-20131022.070629-12.jar:4.3.5-SNAPSHOT]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:591) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
at org.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:172) [rewrite-servlet-1.0.4.Final.jar:1.0.4.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.13.Final.jar:]
at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
{code}
But the list was updated as you can see on the images I've appended here. On the images you can also see that:
* 2 request were made (bottom left),
* scope of the bean (bottom right),
* the updated list (top right) (with or without the image preview).
[~bleathem]: there is a problem, but it seems (from the stacktrace) that the bug is in MediaOutput(or not?) and is connected with Showcase sample not the FileUpload component itself. In this case I can not reproduce the bug.
was (Author: jstefek):
I tried this by changing the scope of the _FileUploadBean_ with the latest RF4 showcase on AS 7.1 and EAP 6.1 and uploading the same picture for multiple times.
I have noticed, that when the scope was @ViewScoped:
* uploaded image preview didn't show,
* and encountered an error on the server side:
{code}
ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/showcase].[Faces Servlet]] (http--127.0.0.1-8080-23) Servlet.service() for servlet Faces Servlet threw exception: java.lang.NullPointerException
at com.sun.faces.mgbean.BeanManager$ScopeManager$ViewScopeHandler.getFromScope(BeanManager.java:563) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.mgbean.BeanManager$ScopeManager.getFromScope(BeanManager.java:477) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.mgbean.BeanManager.getBeanFromScope(BeanManager.java:240) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.el.ManagedBeanELResolver.resolveBean(ManagedBeanELResolver.java:242) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.el.ManagedBeanELResolver.getValue(ManagedBeanELResolver.java:116) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) [jsf-impl-2.1.7-jbossorg-2.jar:]
at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72) [jbossweb-7.0.13.Final.jar:]
at org.apache.el.parser.AstValue.getTarget(AstValue.java:94) [jbossweb-7.0.13.Final.jar:]
at org.apache.el.parser.AstValue.invoke(AstValue.java:244) [jbossweb-7.0.13.Final.jar:]
at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:278) [jbossweb-7.0.13.Final.jar:]
at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:39) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.7-jbossorg-2.jar:]
at org.richfaces.resource.MediaOutputResource.encode(MediaOutputResource.java:62) [richfaces-components-ui-4.3.5-20131022.221155-19.jar:4.3.5-SNAPSHOT]
at org.richfaces.resource.UserResourceWrapperImpl.encode(UserResourceWrapperImpl.java:188) [richfaces-core-impl-4.3.5-20131022.070629-12.jar:4.3.5-SNAPSHOT]
at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:229) [richfaces-core-impl-4.3.5-20131022.070629-12.jar:4.3.5-SNAPSHOT]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:591) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
at org.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:172) [rewrite-servlet-1.0.4.Final.jar:1.0.4.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.13.Final.jar:]
at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
{code}
But the list was updated as you can see on the images I've appended here. On the images you can also see that:
* 2 request were made (bottom left),
* scope of the bean (bottom right),
* the updated list (top right) (with or without the image preview).
[~bleathem]: there is a problem, but it seems (from the stacktrace) that the bug is in MediaOutput(?) and is connected with Showcase sample not the FileUpload component itself. In this case I can not reproduce the bug.
> FileUploadEvent listener reset the list value with Viewscope
> ------------------------------------------------------------
>
> Key: RF-13323
> URL: https://issues.jboss.org/browse/RF-13323
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.3.4
> Environment: Jboss 7.1
> Richfaces 4.3.4
> JSF 2.1.9
>
> Reporter: Mohammad Weshah
> Assignee: Jiří Štefek
> Labels: rich:fileUpload
> Attachments: RF-13323-SessionScoped.png, RF-13323-ViewScoped.png
>
>
> Hello All,
> i make an example of upload file from richfaces showcase it is working successfully , but i notice if i changed the backing bean to viewscope the files list inside the FileUploadEvent listener will be rest every time that i upload new file , the code as follow :
>
> {code}
> protected List<UploadedImage> files = new ArrayList<UploadedImage>();
>
> public void FileUploadlistener(FileUploadEvent event) throws Exception {
> UploadedFile item = event.getUploadedFile();
> UploadedImage file = new UploadedImage();
> file.setLength(item.getData().length);
> file.setName(item.getName());
> file.setData(item.getData());
>
> files.add(file);
> }
> {code}
>
> but when i changed the scope to session the files still contain the old files, is it mandatory to the backing be session or there is something wrong ?
>
> Regards
> Wish79
--
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
12 years, 4 months
[JBoss JIRA] (RF-13323) FileUploadEvent listener reset the list value with Viewscope
by Jiří Štefek (JIRA)
[ https://issues.jboss.org/browse/RF-13323?page=com.atlassian.jira.plugin.s... ]
Jiří Štefek commented on RF-13323:
----------------------------------
I tried this by changing the scope of the _FileUploadBean_ with the latest RF4 showcase on AS 7.1 and EAP 6.1 and uploading the same picture for multiple times.
I have noticed, that when the scope was @ViewScoped:
* uploaded image preview didn't show,
* and encountered an error on the server side:
{code}
ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/showcase].[Faces Servlet]] (http--127.0.0.1-8080-23) Servlet.service() for servlet Faces Servlet threw exception: java.lang.NullPointerException
at com.sun.faces.mgbean.BeanManager$ScopeManager$ViewScopeHandler.getFromScope(BeanManager.java:563) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.mgbean.BeanManager$ScopeManager.getFromScope(BeanManager.java:477) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.mgbean.BeanManager.getBeanFromScope(BeanManager.java:240) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.el.ManagedBeanELResolver.resolveBean(ManagedBeanELResolver.java:242) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.el.ManagedBeanELResolver.getValue(ManagedBeanELResolver.java:116) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) [jsf-impl-2.1.7-jbossorg-2.jar:]
at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72) [jbossweb-7.0.13.Final.jar:]
at org.apache.el.parser.AstValue.getTarget(AstValue.java:94) [jbossweb-7.0.13.Final.jar:]
at org.apache.el.parser.AstValue.invoke(AstValue.java:244) [jbossweb-7.0.13.Final.jar:]
at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:278) [jbossweb-7.0.13.Final.jar:]
at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:39) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.7-jbossorg-2.jar:]
at org.richfaces.resource.MediaOutputResource.encode(MediaOutputResource.java:62) [richfaces-components-ui-4.3.5-20131022.221155-19.jar:4.3.5-SNAPSHOT]
at org.richfaces.resource.UserResourceWrapperImpl.encode(UserResourceWrapperImpl.java:188) [richfaces-core-impl-4.3.5-20131022.070629-12.jar:4.3.5-SNAPSHOT]
at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:229) [richfaces-core-impl-4.3.5-20131022.070629-12.jar:4.3.5-SNAPSHOT]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:591) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
at org.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:172) [rewrite-servlet-1.0.4.Final.jar:1.0.4.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.13.Final.jar:]
at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
{code}
But the list was updated as you can see on the images I've appended here. On the images you can also see that:
* 2 request were made (bottom left),
* scope of the bean (bottom right),
* the updated list (top right) (with or without the image preview).
[~bleathem]: there is a problem, but it seems (from the stacktrace) that the bug is in MediaOutput(?) and is connected with Showcase sample not the FileUpload component itself. In this case I can not reproduce the bug.
> FileUploadEvent listener reset the list value with Viewscope
> ------------------------------------------------------------
>
> Key: RF-13323
> URL: https://issues.jboss.org/browse/RF-13323
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.3.4
> Environment: Jboss 7.1
> Richfaces 4.3.4
> JSF 2.1.9
>
> Reporter: Mohammad Weshah
> Assignee: Jiří Štefek
> Labels: rich:fileUpload
> Attachments: RF-13323-SessionScoped.png, RF-13323-ViewScoped.png
>
>
> Hello All,
> i make an example of upload file from richfaces showcase it is working successfully , but i notice if i changed the backing bean to viewscope the files list inside the FileUploadEvent listener will be rest every time that i upload new file , the code as follow :
>
> {code}
> protected List<UploadedImage> files = new ArrayList<UploadedImage>();
>
> public void FileUploadlistener(FileUploadEvent event) throws Exception {
> UploadedFile item = event.getUploadedFile();
> UploadedImage file = new UploadedImage();
> file.setLength(item.getData().length);
> file.setName(item.getName());
> file.setData(item.getData());
>
> files.add(file);
> }
> {code}
>
> but when i changed the scope to session the files still contain the old files, is it mandatory to the backing be session or there is something wrong ?
>
> Regards
> Wish79
--
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
12 years, 4 months
[JBoss JIRA] (RF-13323) FileUploadEvent listener reset the list value with Viewscope
by Jiří Štefek (JIRA)
[ https://issues.jboss.org/browse/RF-13323?page=com.atlassian.jira.plugin.s... ]
Jiří Štefek updated RF-13323:
-----------------------------
Attachment: RF-13323-SessionScoped.png
RF-13323-ViewScoped.png
> FileUploadEvent listener reset the list value with Viewscope
> ------------------------------------------------------------
>
> Key: RF-13323
> URL: https://issues.jboss.org/browse/RF-13323
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.3.4
> Environment: Jboss 7.1
> Richfaces 4.3.4
> JSF 2.1.9
>
> Reporter: Mohammad Weshah
> Assignee: Jiří Štefek
> Labels: rich:fileUpload
> Attachments: RF-13323-SessionScoped.png, RF-13323-ViewScoped.png
>
>
> Hello All,
> i make an example of upload file from richfaces showcase it is working successfully , but i notice if i changed the backing bean to viewscope the files list inside the FileUploadEvent listener will be rest every time that i upload new file , the code as follow :
>
> {code}
> protected List<UploadedImage> files = new ArrayList<UploadedImage>();
>
> public void FileUploadlistener(FileUploadEvent event) throws Exception {
> UploadedFile item = event.getUploadedFile();
> UploadedImage file = new UploadedImage();
> file.setLength(item.getData().length);
> file.setName(item.getName());
> file.setData(item.getData());
>
> files.add(file);
> }
> {code}
>
> but when i changed the scope to session the files still contain the old files, is it mandatory to the backing be session or there is something wrong ?
>
> Regards
> Wish79
--
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
12 years, 4 months
[JBoss JIRA] (RF-13335) Page fragments: get rid of commons-lang dependency
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13335?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč edited comment on RF-13335 at 11/12/13 3:12 AM:
-----------------------------------------------------------
I came to conclusion that we should not need JSON parsing at all - leveraging RichFaces 5 {{bridgeBase}}, we can retrieve options using following jQuery UI widget factory invocation:
{code}
$(element).pluginName("optionName");
{code}
Unfortunately, RichFaces 4 BaseComponent doesn't allow to retrieve options at runtime.
I suggest to introduce method {{getOptions}} to [{{BaseComponent}}|https://github.com/richfaces/richfaces/blob/0855b61d55533ad9c1b31555f222608911806cb0/framework/src/main/resources/META-INF/resources/org.richfaces/common/richfaces-base-component.js#L193]:
{code}
function getOptions() {
return this.options;
}
{code}
This would need to be introduced in both, RF 4.3, RF 4.5 and RF 5.0.
was (Author: lfryc):
I came to conclusion that we should not need JSON parsing at all - in RichFaces bridgeBase, we can retrieve options using following jQuery UI widget factory invocation:
{code}
$(element).pluginName("optionName");
{code}
Unfortunately, RichFaces 4 BaseComponent doesn't allow to retrieve options at runtime.
I suggest to introduce method {{getOptions}} to [{{BaseComponent}}|https://github.com/richfaces/richfaces/blob/0855b61d55533ad9c1b31555f222608911806cb0/framework/src/main/resources/META-INF/resources/org.richfaces/common/richfaces-base-component.js#L193]:
{code}
function getOptions() {
return this.options;
}
{code}
This would need to be introduced in both, RF 4.3, RF 4.5 and RF 5.0.
> Page fragments: get rid of commons-lang dependency
> --------------------------------------------------
>
> Key: RF-13335
> URL: https://issues.jboss.org/browse/RF-13335
> Project: RichFaces
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: page-fragments
> Affects Versions: 5.0.0.Alpha2
> Reporter: Lukáš Fryč
> Assignee: Lukáš Fryč
> Fix For: 5.0.0.Alpha2
>
>
> I didn't found reason to leave {{Validate.isTrue}} - this should be replaced by more verbose but dependency free code.
> I did some googling for alternatives to {{StringEscapeUtils.unescapeJava}} and found out few [suggestions for dependency free Java-unescaping|http://stackoverflow.com/questions/3537706/howto-unescape...].
--
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
12 years, 4 months
[JBoss JIRA] (RF-13335) Page fragments: get rid of commons-lang dependency
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13335?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-13335:
---------------------------------
I came to conclusion that we should not need JSON parsing at all - in RichFaces bridgeBase, we can retrieve options using following jQuery UI widget factory invocation:
{code}
$(element).pluginName("optionName");
{code}
Unfortunately, RichFaces 4 BaseComponent doesn't allow to retrieve options at runtime.
I suggest to introduce method {{getOptions}} to [{{BaseComponent}}|https://github.com/richfaces/richfaces/blob/0855b61d55533ad9c1b31555f222608911806cb0/framework/src/main/resources/META-INF/resources/org.richfaces/common/richfaces-base-component.js#L193]:
{code}
function getOptions() {
return this.options;
}
{code}
This would need to be introduced in both, RF 4.3, RF 4.5 and RF 5.0.
> Page fragments: get rid of commons-lang dependency
> --------------------------------------------------
>
> Key: RF-13335
> URL: https://issues.jboss.org/browse/RF-13335
> Project: RichFaces
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: page-fragments
> Affects Versions: 5.0.0.Alpha2
> Reporter: Lukáš Fryč
> Assignee: Lukáš Fryč
> Fix For: 5.0.0.Alpha2
>
>
> I didn't found reason to leave {{Validate.isTrue}} - this should be replaced by more verbose but dependency free code.
> I did some googling for alternatives to {{StringEscapeUtils.unescapeJava}} and found out few [suggestions for dependency free Java-unescaping|http://stackoverflow.com/questions/3537706/howto-unescape...].
--
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
12 years, 4 months