[JBoss JIRA] (RF-13539) r:fileUpload doesn't have the attribute fileUploadListener anymore
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13539?page=com.atlassian.jira.plugin.s... ]
Brian Leathem edited comment on RF-13539 at 2/11/14 2:09 PM:
-------------------------------------------------------------
I understand this feature was temporarily disabled with RF-13444 in 5.0.0.Alpha3 to enable JSF 2.2 compatibility. We are aiming to restore the functionality with a re-work of the fileUpload component in 5.0.0.Alpha4 with RF-13514.
[~lfryc] please correct me if am wrong. Should we consider this a duplicate issue?
was (Author: bleathem):
I understand this feature was temporarily disabled with RF-13444 in 5.0.0.Alpha3 to enable JSF 2.2 compatibility. We are aiming to restorer the functionality with a re-work of the fileUpload component in 5.0.0.Alpha4 with RF-13514.
[~lfryc] please correct me if am wrong. Should we consider this a duplicate issue?
> r:fileUpload doesn't have the attribute fileUploadListener anymore
> ------------------------------------------------------------------
>
> Key: RF-13539
> URL: https://issues.jboss.org/browse/RF-13539
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 5.0.0.Alpha3
> Reporter: Juergen Zimmermann
>
> In RF 4.x and 5.0.0.Alpha1 the tag r:fileUpload had an attribute fileUploadListener to provide a listener which received the uploaded byte array. This attribute is gone. How shall one receive the uploaded bytes?
--
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
10 years, 4 months
[JBoss JIRA] (RF-13539) r:fileUpload doesn't have the attribute fileUploadListener anymore
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13539?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13539:
------------------------------------
I understand this feature was temporarily disabled with RF-13444 in 5.0.0.Alpha3 to enable JSF 2.2 compatibility. We are aiming to restorer the functionality with a re-work of the fileUpload component in 5.0.0.Alpha4 with RF-13514.
[~lfryc] please correct me if am wrong. Should we consider this a duplicate issue?
> r:fileUpload doesn't have the attribute fileUploadListener anymore
> ------------------------------------------------------------------
>
> Key: RF-13539
> URL: https://issues.jboss.org/browse/RF-13539
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 5.0.0.Alpha3
> Reporter: Juergen Zimmermann
>
> In RF 4.x and 5.0.0.Alpha1 the tag r:fileUpload had an attribute fileUploadListener to provide a listener which received the uploaded byte array. This attribute is gone. How shall one receive the uploaded bytes?
--
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
10 years, 4 months
[JBoss JIRA] (RF-13247) Upgrade the RichFaces guava dependency to the latest version
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13247?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13247:
-------------------------------
Summary: Upgrade the RichFaces guava dependency to the latest version (was: Upgrade the RichFaces guava dependency to version 15.0)
> Upgrade the RichFaces guava dependency to the latest version
> ------------------------------------------------------------
>
> Key: RF-13247
> URL: https://issues.jboss.org/browse/RF-13247
> Project: RichFaces
> Issue Type: Component Upgrade
> Security Level: Public(Everyone can see)
> Components: third-party
> Reporter: Jeremy Landis
> Assignee: Brian Leathem
> Priority: Minor
> Fix For: 5.0.0.Alpha4
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> Upgrading to guava 15 from 14.0.1 causes this richfaces error. I have not looked into this further but wanted to put it out there as an issue.
> Caused by: java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class org.richfaces.resource.ResourceLibraryFactoryImpl
--
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
10 years, 4 months
[JBoss JIRA] (RF-13538) Closeables.closeQuietly() removed in Guava 16.0, but still used in RF
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13538?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13538:
-------------------------------
Fix Version/s: 5.0.0.Alpha4
> Closeables.closeQuietly() removed in Guava 16.0, but still used in RF
> ---------------------------------------------------------------------
>
> Key: RF-13538
> URL: https://issues.jboss.org/browse/RF-13538
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 5.0.0.Alpha3
> Reporter: Juergen Zimmermann
> Fix For: 5.0.0.Alpha4
>
>
> For instance in org.richfaces.resource.Java2DUserResourceWrapperImpl at line 73 is an invocation of Closeables.closeQuietly(...). However, this method is removed in Guava 16.0 which is now used in RF 5.0.0.Alpha3.
> javadoc of Guava 14.0 already mentioned:
> "Deprecated. Where possible, use the try-with-resources statement if using JDK7 or Closer on JDK6 to close one or more Closeable objects. This method is deprecated because it is easy to misuse and may swallow IO exceptions that really should be thrown and handled. See Guava issue 1118 for a more detailed explanation of the reasons for deprecation and see Closing Resources for more information on the problems with closing Closeable objects and some of the preferred solutions for handling it correctly. This method is scheduled to be removed in Guava 16.0."
> Well, now the method is removed, but still invoked in RF 5.0.0.Alpha3.
--
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
10 years, 4 months
[JBoss JIRA] (RF-13534) a4j:mediaOutput on GF4: "Unauthorized deserialisation attempt"
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13534?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13534:
-------------------------------
Fix Version/s: 5-Tracking
> a4j:mediaOutput on GF4: "Unauthorized deserialisation attempt"
> --------------------------------------------------------------
>
> Key: RF-13534
> URL: https://issues.jboss.org/browse/RF-13534
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.5
> Environment: Glassfish 4.0, Mac OS X 10.9.1, Java(TM) SE Runtime Environment (build 1.7.0_21-b12), Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
> Reporter: Daniele Benegiamo
> Fix For: 5-Tracking
>
> Attachments: MediaOutput.zip
>
>
> On GF4.0 any attempt to use {{<a4j:mediaOutput>}} raises the same exception ("{{java.io.InvalidClassException: Unauthorized deserialisation attempt}}"). Everything works nicely with the old RichFaces 4.1.0.
> Below you can find a stack trace, a sample page and a sample managed bean as minimum reproducible test case.
> To keep the test case short, the sample doesn't uses the {{value}} attribute, but exceptions are raised also when using it (e.g. passing a simple {{java.lang.String}}).
> From a first quick analysis seems that:
> * basic types (as {{java.lang.String}}) are not properly detected as "de-serializable";
> * types implementing {{Serializable}} or {{SerializableResource}} interfaces are impossible to instantiate by {{LookAheadObjectInputStream}} (row 118 - {{Class.forName()}} call in {{isClassValid()}} method - raises a {{ClassNotFoundException}} exception).
> {code:title=Exception}
> SEVERE: Input error for deserialize data
> java.io.InvalidClassException: Unauthorized deserialization attempt; org.jboss.weld.util.el.ForwardingMethodExpression
> at org.richfaces.util.LookAheadObjectInputStream.resolveClass(LookAheadObjectInputStream.java:105)
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1610)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1515)
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1620)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1515)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1769)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
> at com.sun.faces.facelets.el.TagMethodExpression.readExternal(TagMethodExpression.java:158)
> at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1835)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1794)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348)
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1989)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1913)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1796)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348)
> at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1704)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1342)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
> at org.richfaces.util.Util.decodeObjectData(Util.java:237)
> at org.richfaces.resource.DefaultCodecResourceRequestData.getData(DefaultCodecResourceRequestData.java:97)
> at org.richfaces.resource.ResourceFactoryImpl.createResource(ResourceFactoryImpl.java:337)
> at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:156)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:643)
> at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
> at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
> at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
> at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
> at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
> at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
> at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
> at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
> at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
> at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
> at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
> at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
> at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
> at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
> at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
> at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
> at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
> at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
> at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
> at java.lang.Thread.run(Thread.java:722)
> WARNING: StandardWrapperValve[Faces Servlet]: Servlet.service() for servlet Faces Servlet threw exception
> java.lang.NullPointerException
> at org.richfaces.resource.MediaOutputResource.encode(MediaOutputResource.java:62)
> at org.richfaces.resource.UserResourceWrapperImpl.encode(UserResourceWrapperImpl.java:188)
> at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:229)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:643)
> at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
> at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
> at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
> at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
> at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
> at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
> at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
> at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
> at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
> at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
> at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
> at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
> at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
> at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
> at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
> at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
> at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
> at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
> at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
> at java.lang.Thread.run(Thread.java:722)
> {code}
> {code:xml|title=index.xhtml}
> <?xml version='1.0' encoding='UTF-8' ?>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://xmlns.jcp.org/jsf/html"
> xmlns:a4j="http://richfaces.org/a4j">
> <h:head>
> <title>Page title</title>
> </h:head>
> <h:body>
> <a4j:mediaOutput element="img" createContent="#{myBean.myCreateContent}"/>
> </h:body>
> </html>
> {code}
> {code:java|title=MyBean.java}
> package org.example;
> import java.awt.Color;
> import java.awt.Font;
> import java.awt.Graphics2D;
> import java.awt.image.BufferedImage;
> import java.io.IOException;
> import javax.enterprise.context.RequestScoped;
> import javax.imageio.ImageIO;
> import javax.inject.Named;
> @Named
> @RequestScoped
> public class MyBean
> {
> public void myCreateContent (java.io.OutputStream output, java.lang.Object input)
> throws IOException
> {
> BufferedImage img = new BufferedImage (400, 200, BufferedImage.TYPE_INT_RGB);
> Graphics2D graphics2D = img.createGraphics ();
> graphics2D.setBackground (Color.BLACK);
> graphics2D.setColor (Color.WHITE);
> graphics2D.clearRect (0, 0, img.getWidth (), img.getHeight ());
> graphics2D.setFont (new Font ("Arial", Font.PLAIN, 12));
> graphics2D.drawString ("String", 20, 35);
> ImageIO.write (img, "png", output);
> }
> }
> {code}
--
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
10 years, 4 months
[JBoss JIRA] (RF-13538) Closeables.closeQuietly() removed in Guava 16.0, but still used in RF
by Cody Lerum (JIRA)
[ https://issues.jboss.org/browse/RF-13538?page=com.atlassian.jira.plugin.s... ]
Cody Lerum commented on RF-13538:
---------------------------------
This was always an @Beta feature (http://docs.guava-libraries.googlecode.com/git-history/v13.0.1/javadoc/in...) and probably shouldn't have been depended on.
> Closeables.closeQuietly() removed in Guava 16.0, but still used in RF
> ---------------------------------------------------------------------
>
> Key: RF-13538
> URL: https://issues.jboss.org/browse/RF-13538
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 5.0.0.Alpha3
> Reporter: Juergen Zimmermann
>
> For instance in org.richfaces.resource.Java2DUserResourceWrapperImpl at line 73 is an invocation of Closeables.closeQuietly(...). However, this method is removed in Guava 16.0 which is now used in RF 5.0.0.Alpha3.
> javadoc of Guava 14.0 already mentioned:
> "Deprecated. Where possible, use the try-with-resources statement if using JDK7 or Closer on JDK6 to close one or more Closeable objects. This method is deprecated because it is easy to misuse and may swallow IO exceptions that really should be thrown and handled. See Guava issue 1118 for a more detailed explanation of the reasons for deprecation and see Closing Resources for more information on the problems with closing Closeable objects and some of the preferred solutions for handling it correctly. This method is scheduled to be removed in Guava 16.0."
> Well, now the method is removed, but still invoked in RF 5.0.0.Alpha3.
--
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
10 years, 4 months