[JBoss JIRA] (RF-13098) Regression: mediaOutput broken for CDI MediaData beans
by Romain Guillaume (JIRA)
[ https://issues.jboss.org/browse/RF-13098?page=com.atlassian.jira.plugin.s... ]
Romain Guillaume commented on RF-13098:
---------------------------------------
Hi everyone,
I recently updated to RF 4.3.4 in the hope to fix this issue.
But unfortunately, with or without "implements SerializableResource" I still have:
java.io.InvalidClassException: Unauthorized deserialization attempt; org.jboss.weld.util.el.ForwardingMethodExpression
I guess adding the Weld SerializableClientProxy to the resource serialisation whitelist has no effect on Weld ForwardingMethodExpression.
What do you recommend?
For the moment I use a workaround by replacing a4j:mediaOutput by h:graphicImage and a servlet.
Thank you
> Regression: mediaOutput broken for CDI MediaData beans
> ------------------------------------------------------
>
> Key: RF-13098
> URL: https://issues.jboss.org/browse/RF-13098
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.3
> Reporter: Marek Schmidt
> Assignee: Brian Leathem
> Labels: regression
> Fix For: 4.3.4, 5.0.0.Alpha2
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> https://issues.jboss.org/browse/RF-13089 introduced a regression for a4j:mediaOutput component
> Having a
> {code}
> <a4j:mediaOutput element="img" cacheable="true" session="true" createContent="#{mediaBean.paint}" value="#{mediaData}" mimeType="image/jpeg"/>
> {code}
> with mediaData being a CDI bean, e.g.
> {code}
> @javax.inject.Named("mediaData")
> @javax.enterprise.context.RequestScoped
> public class MediaData implements Serializable
> {code}
> the following exception occurs:
> {code}10:39:27,997 SEVERE [org.richfaces.log.Resource] (http-/127.0.0.1:8080-1) Input error for deserialize data : java.io.InvalidClassException: Unauthorized deserialization attempt; org.jboss.weld.bean.proxy.util.SerializableClientProxy
> at org.richfaces.util.LookAheadObjectInputStream.resolveClass(LookAheadObjectInputStream.java:93) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1610) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1515) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1769) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1989) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1913) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1796) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1704) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1342) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370) [rt.jar:1.7.0_25]
> at org.richfaces.util.Util.decodeObjectData(Util.java:237) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at org.richfaces.resource.DefaultCodecResourceRequestData.getData(DefaultCodecResourceRequestData.java:97) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at org.richfaces.resource.ResourceFactoryImpl.createResource(ResourceFactoryImpl.java:337) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:156) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:591) [jboss-jsf-api_2.1_spec-2.1.19.1.Final-redhat-1.jar:2.1.19.1.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> {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
12 years, 6 months
[JBoss JIRA] (RF-13246) Richfaces 4.3.4 ajax fails on ie8 packed.js cannot find console.
by Jeremy Landis (JIRA)
Jeremy Landis created RF-13246:
----------------------------------
Summary: Richfaces 4.3.4 ajax fails on ie8 packed.js cannot find console.
Key: RF-13246
URL: https://issues.jboss.org/browse/RF-13246
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.3.4
Reporter: Jeremy Landis
After upgrading to richfaces 4.3.4 using jsf 2.1.26, ajax has stopped working in IE8. I have been able to verify non issue in firefox and IE11. The issue affects specialized ajax calls within a page as well as overall ajax page areas. It further affects extended data grids where it will not allow next page logic to work.
--
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, 6 months
[JBoss JIRA] (RF-13182) Autocomplete: attributes style and styleClass missing
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13182?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč resolved RF-13182.
-----------------------------
Resolution: Done
> Autocomplete: attributes style and styleClass missing
> -----------------------------------------------------
>
> Key: RF-13182
> URL: https://issues.jboss.org/browse/RF-13182
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input, regression
> Affects Versions: 5.0.0.Alpha2
> Environment: RichFaces 5.0.0-SNAPSHOT
> Metamer 5.0.0-SNAPSHOT
> Mojarra 2.1.19
> JBoss AS 7.2.0.Final-redhat-8
> Java(TM) SE Runtime Environment 1.7.0_04-b20 @ Linux
> Chrome 29.0.1547.65 @ Linux x86_64
> Reporter: Pavol Pitonak
> Assignee: Lukáš Fryč
> Fix For: 5.0.0.Alpha2
>
> Original Estimate: 30 minutes
> Remaining Estimate: 30 minutes
>
> Component autocomplete is missing two attributes - style and styleClass. There attributes were present in 5.0.0.Alpha1.
--
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, 6 months
[JBoss JIRA] (RF-13245) Favor Javadoc comments as base for attribute description over @Description annotations
by Lukáš Fryč (JIRA)
Lukáš Fryč created RF-13245:
-------------------------------
Summary: Favor Javadoc comments as base for attribute description over @Description annotations
Key: RF-13245
URL: https://issues.jboss.org/browse/RF-13245
Project: RichFaces
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: component
Affects Versions: 5.0.0.Alpha2
Reporter: Lukáš Fryč
With merging all sources to one, we have no longer the issue with scanning Javadoc for attribute description in *Props interfaces.
That's why we can remove all @Descriptions and favor rather Javadoc which is more readable. It will also avoid duplication.
--
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, 6 months
[JBoss JIRA] (RF-12802) Move page fragments from repository qa to richfaces5
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-12802?page=com.atlassian.jira.plugin.s... ]
Juraj Húska commented on RF-12802:
----------------------------------
Couple of additional refactorings, we have discussed offline:
* Create interface for method {{advance()}} -
{code}
AdvancedInteractions<T> {
T advanced();
}
{code}
We can document the method more easily - the fragment will implement that interface
* provide a way to set JS strategy in {{arquillian.xml}} - e.g.
{code:xml}
<extension name="richfacesPageFragments"><property name="controlStrategy">interactive</property>
{code}
See ARQGRA-325 comments as well.
* waiting API - put {{withTimeout}} right to the wrapper, so the public API methods do not have call for the actual timeout value
* rename the parameter for setting of the timeout from _timeout_ to something which shows in what time unit it is - e.g. miliseconds
* move fields which hold timeout value to the {{AdvancedInteraction}} classes
* use miliseconds in waiting API instead of seconds as we found them to be more used accros tests
* review exception throwing - throw them where it is necessary, make the method no operation where it is not necessary
> Move page fragments from repository qa to richfaces5
> ----------------------------------------------------
>
> Key: RF-12802
> URL: https://issues.jboss.org/browse/RF-12802
> Project: RichFaces
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: build/distribution
> Affects Versions: 5.0.0.Alpha1
> Reporter: Pavol Pitonak
> Assignee: Brian Leathem
> Fix For: 5.0.0.Alpha2
>
>
> As discussed on community meeting on Feb 12, we should move page fragments for RichFaces components to richfaces5 repository so that they are distributed with framework.
> We should find out how to prepare them so that they are easy to use for community members. RichFaces QE/dev need to test internals of components, community members will probably test only high-level functionality of components. One possible solution would be to create package "internal" in which there would be page fragments extending those from "public" package. QE team would then use "internal" implementations.
--
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, 6 months
[JBoss JIRA] (RF-12802) Move page fragments from repository qa to richfaces5
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-12802?page=com.atlassian.jira.plugin.s... ]
Juraj Húska commented on RF-12802:
----------------------------------
List of additional features we either discussed on developer forum or not discussed at all:
* ability to choose between JS API and interactive manipulation with a widget (setting/obtaining value)
* advanced interactions
* {{WaitingWrapper}} [interface|https://github.com/richfaces/richfaces-qa/blob/master/page-frag...] - there are some predefined waitings for some fragments. This is a convenient way how an user can call it: e.g. {{autocomplete.advanced().waitForSuggestionsToBeNotVisible().withTimeout(4);}}
* those waiting are also used in the the methods from public API. Thus there has to be way how an user can change the timeout for those methods. E.g. {{autocomplete.type("ala").confirm();}} - the method needs to wait until the suggestions are not visible, and the user should have an option to set the timeout for it - thus {{autocomplete.advanced().setupConfirmWaitForSuggestionsToBeNotVisibleTimeout(3);}}
* HotKey [fragment|https://github.com/richfaces/richfaces-qa/blob/master/page-fragm...] - automatically retrieve the hotkey combination via JS
The automatic detection of widget is not implemented. We will need to investigate on that more.
> Move page fragments from repository qa to richfaces5
> ----------------------------------------------------
>
> Key: RF-12802
> URL: https://issues.jboss.org/browse/RF-12802
> Project: RichFaces
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: build/distribution
> Affects Versions: 5.0.0.Alpha1
> Reporter: Pavol Pitonak
> Assignee: Brian Leathem
> Fix For: 5.0.0.Alpha2
>
>
> As discussed on community meeting on Feb 12, we should move page fragments for RichFaces components to richfaces5 repository so that they are distributed with framework.
> We should find out how to prepare them so that they are easy to use for community members. RichFaces QE/dev need to test internals of components, community members will probably test only high-level functionality of components. One possible solution would be to create package "internal" in which there would be page fragments extending those from "public" package. QE team would then use "internal" implementations.
--
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, 6 months
[JBoss JIRA] (RF-12802) Move page fragments from repository qa to richfaces5
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12802?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč edited comment on RF-12802 at 10/4/13 4:00 AM:
----------------------------------------------------------
Juraj, generally the API looks great from my point of view.
-I would like to see information hiding in form of providing interfaces and their implementation.-
-(a)ImplementedBy(RichFacesCalendar.class) public interface Calendar {}-
(that's achieved by {{advanced()}} method)
Could you please list additional features which we haven't discussed before?: e.g.:
* ability to choose between JS API and interactive manipulation with a widget (setting/obtaining value)
* advanced interactions
Have you implemented automatic detection of the widget in the page? E.g. rich:calendar can be find by ".rf-cal" in case there is just one instance in the page (or in the context of user-defined fragment).
was (Author: lfryc):
Juraj, generally the API looks great from my point of view.
I would like to see information hiding in form of providing interfaces and their implementation.
@ImplementedBy(RichFacesCalendar.class) public interface Calendar {}
Could you please list additional features which we haven't discussed before?: e.g.:
* ability to choose between JS API and interactive manipulation with a widget (setting/obtaining value)
* advanced interactions
Have you implemented automatic detection of the widget in the page? E.g. rich:calendar can be find by ".rf-cal" in case there is just one instance in the page (or in the context of user-defined fragment).
> Move page fragments from repository qa to richfaces5
> ----------------------------------------------------
>
> Key: RF-12802
> URL: https://issues.jboss.org/browse/RF-12802
> Project: RichFaces
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: build/distribution
> Affects Versions: 5.0.0.Alpha1
> Reporter: Pavol Pitonak
> Assignee: Brian Leathem
> Fix For: 5.0.0.Alpha2
>
>
> As discussed on community meeting on Feb 12, we should move page fragments for RichFaces components to richfaces5 repository so that they are distributed with framework.
> We should find out how to prepare them so that they are easy to use for community members. RichFaces QE/dev need to test internals of components, community members will probably test only high-level functionality of components. One possible solution would be to create package "internal" in which there would be page fragments extending those from "public" package. QE team would then use "internal" implementations.
--
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, 6 months