September 2013 - richfaces-issues

[JBoss JIRA] (RF-13199) Framework tests does not include all needed classes to the deployment when deploying on WildFly

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13199?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13199: ------------------------------- Fix Version/s: 5.0.0.Alpha3 > Framework tests does not include all needed classes to the deployment when deploying on WildFly > ----------------------------------------------------------------------------------------------- > > Key: RF-13199 > URL: https://issues.jboss.org/browse/RF-13199 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: tests - functional > Affects Versions: 5.0.0.Alpha1 > Environment: WildFly 8.0.0.Alpha4 > Reporter: Juraj Húska > Fix For: 5.0.0.Alpha3 > > > When running framework tests with WildFly 8.0.0.Alpha4, some of the tests fail with: _DeploymentException: Cannot deploy_ exception. > The created wars miss classes like: {{FrameworkDeployment}} and other linkage errors. See for example [this|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/view...] or [this|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/view...] tests results. > The reason is IMHO different *Weld* implementation in WildFly than in JBoss AS 7.1.1.Final, where the same tests are passing. > I am also wondering why we are creating wars which contains Arquillian related stuff for client tests ? Should not we create more granular deployment, which will distinguish among client, server and warp tests ? -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (RF-13200) Tree: Uncaught TypeError: Object #<Object> has no method '$'

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13200?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13200: ------------------------------- Fix Version/s: 5.0.0.Alpha2 > Tree: Uncaught TypeError: Object #<Object> has no method '$' > ------------------------------------------------------------ > > Key: RF-13200 > URL: https://issues.jboss.org/browse/RF-13200 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tree > Affects Versions: 5.0.0.Alpha2 > Environment: RichFaces 5.0.0-SNAPSHOT > Metamer 5.0.0-SNAPSHOT > JBoss Application Server: Weld Integration 7.2.1.Final-redhat-10 > JBoss AS 7.2.1.Final-redhat-10 > Java(TM) SE Runtime Environment 1.7.0_04-b20 @ Linux > Chrome 29.0.1547.65 @ Linux x86_64 > Reporter: Pavol Pitonak > Priority: Blocker > Fix For: 5.0.0.Alpha2 > > > # deploy Metamer and open http://127.0.0.1:8080/metamer/faces/components/richTree/treeAdaptors.xhtm... > # open node R-1 > # open node R-1.1 > # click on node R-1.1-M-V-1 > expected result: > * node should be selected > actual: > * exception in browser console: Uncaught TypeError: Object #<Object> has no method '$' > reason: > * response to Ajax request contains this code > {code} > RichFaces.$("form:richTree").__updateSelectionFromInput(); > {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, 9 months

1
0
0 / 0

[JBoss JIRA] (RF-13201) Support for adding faces-config.xml with correct version dynamically in framework tests deplyment

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13201?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13201: ------------------------------- Labels: jsf22 (was: ) > Support for adding faces-config.xml with correct version dynamically in framework tests deplyment > ------------------------------------------------------------------------------------------------- > > Key: RF-13201 > URL: https://issues.jboss.org/browse/RF-13201 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: tests - functional > Affects Versions: 5.0.0.Alpha1 > Reporter: Juraj Húska > Labels: jsf22 > Fix For: 5.0.0.Alpha3 > > > Currently, {{faces-config}} with version 2.0 is added to the all wars generated by framework all tests. See [this|https://github.com/richfaces/richfaces/blob/master/build/build-resou...]. > Should not we allow to add this version dynamically to enable JSF 2.1 and 2.2. versions ? I am not aware of any problem which can be caused by this unmatched versions, but we can prevent future errors. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (RF-13201) Support for adding faces-config.xml with correct version dynamically in framework tests deplyment

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13201?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13201: ------------------------------- Fix Version/s: 5.0.0.Alpha3 > Support for adding faces-config.xml with correct version dynamically in framework tests deplyment > ------------------------------------------------------------------------------------------------- > > Key: RF-13201 > URL: https://issues.jboss.org/browse/RF-13201 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: tests - functional > Affects Versions: 5.0.0.Alpha1 > Reporter: Juraj Húska > Fix For: 5.0.0.Alpha3 > > > Currently, {{faces-config}} with version 2.0 is added to the all wars generated by framework all tests. See [this|https://github.com/richfaces/richfaces/blob/master/build/build-resou...]. > Should not we allow to add this version dynamically to enable JSF 2.1 and 2.2. versions ? I am not aware of any problem which can be caused by this unmatched versions, but we can prevent future errors. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (RF-13201) Support for adding faces-config.xml with correct version dynamically in framework tests deplyment

by Juraj Húska (JIRA)

[ https://issues.jboss.org/browse/RF-13201?page=com.atlassian.jira.plugin.s... ] Juraj Húska updated RF-13201: ----------------------------- Description: Currently, {{faces-config}} with version 2.0 is added to the all wars generated by framework all tests. See [this|https://github.com/richfaces/richfaces/blob/master/build/build-resou...]. Should not we allow to add this version dynamically to enable JSF 2.1 and 2.2. versions ? I am not aware of any problem which can be caused by this unmatched versions, but we can prevent future errors. was: Currently, {{faces-config}} with version 2.0 is added to the all wars generated by framework all tests. See [this|https://github.com/richfaces/richfaces/blob/master/build/build-resou...] Should not we allow to add this version dynamically to enable JSF 2.1 and 2.2. versions ? > Support for adding faces-config.xml with correct version dynamically in framework tests deplyment > ------------------------------------------------------------------------------------------------- > > Key: RF-13201 > URL: https://issues.jboss.org/browse/RF-13201 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: tests - functional > Affects Versions: 5.0.0.Alpha1 > Reporter: Juraj Húska > > Currently, {{faces-config}} with version 2.0 is added to the all wars generated by framework all tests. See [this|https://github.com/richfaces/richfaces/blob/master/build/build-resou...]. > Should not we allow to add this version dynamically to enable JSF 2.1 and 2.2. versions ? I am not aware of any problem which can be caused by this unmatched versions, but we can prevent future errors. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (RF-13201) Support for adding faces-config.xml with correct version dynamically in framework tests deplyment

by Juraj Húska (JIRA)

Juraj Húska created RF-13201: -------------------------------- Summary: Support for adding faces-config.xml with correct version dynamically in framework tests deplyment Key: RF-13201 URL: https://issues.jboss.org/browse/RF-13201 Project: RichFaces Issue Type: Enhancement Security Level: Public (Everyone can see) Components: tests - functional Affects Versions: 5.0.0.Alpha1 Reporter: Juraj Húska Currently, {{faces-config}} with version 2.0 is added to the all wars generated by framework all tests. Should not we allow to add this version dynamically to enable JSF 2.1 and 2.2. versions ? -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (RF-13142) Showcase: mediaOutput sample is not working with MyFaces

by Pavol Pitonak (JIRA)

[ https://issues.jboss.org/browse/RF-13142?page=com.atlassian.jira.plugin.s... ] Pavol Pitonak updated RF-13142: ------------------------------- Labels: (was: needs-qe) > Showcase: mediaOutput sample is not working with MyFaces > -------------------------------------------------------- > > Key: RF-13142 > URL: https://issues.jboss.org/browse/RF-13142 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.3, 4.3.4 > Environment: MyFaces 2.1.10 > Apache Tomcat 7.0.34 > Reporter: Jiří Štefek > Assignee: Brian Leathem > Fix For: 4.3.4 > > > The generated image from media output is not displayed. > Stack trace from logs: > {code} > java.lang.ClassNotFoundException: javax.faces.component.StateHolderSaver > at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1714) > at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:188) > at org.richfaces.util.LookAheadObjectInputStream.loadWhitelist(LookAheadObjectInputStream.java:141) > at org.richfaces.util.LookAheadObjectInputStream.<clinit>(LookAheadObjectInputStream.java:76) > at org.richfaces.util.Util.decodeObjectData(Util.java:236) > 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:191) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.richfaces.webapp.PushFilter.doFilter(PushFilter.java:129) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:172) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) > at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) > at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004) > at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) > at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:722) > {code} > {code} > java.lang.NoClassDefFoundError: Could not initialize class org.richfaces.util.LookAheadObjectInputStream > at org.richfaces.util.Util.decodeObjectData(Util.java:236) > 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:191) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.richfaces.webapp.PushFilter.doFilter(PushFilter.java:129) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:172) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) > at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) > at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004) > at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) > at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:722) > {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, 9 months

1
0
0 / 0

[JBoss JIRA] (RF-13201) Support for adding faces-config.xml with correct version dynamically in framework tests deplyment

by Juraj Húska (JIRA)

[ https://issues.jboss.org/browse/RF-13201?page=com.atlassian.jira.plugin.s... ] Juraj Húska updated RF-13201: ----------------------------- Description: Currently, {{faces-config}} with version 2.0 is added to the all wars generated by framework all tests. See [this|https://github.com/richfaces/richfaces/blob/master/build/build-resou...] Should not we allow to add this version dynamically to enable JSF 2.1 and 2.2. versions ? was: Currently, {{faces-config}} with version 2.0 is added to the all wars generated by framework all tests. Should not we allow to add this version dynamically to enable JSF 2.1 and 2.2. versions ? > Support for adding faces-config.xml with correct version dynamically in framework tests deplyment > ------------------------------------------------------------------------------------------------- > > Key: RF-13201 > URL: https://issues.jboss.org/browse/RF-13201 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: tests - functional > Affects Versions: 5.0.0.Alpha1 > Reporter: Juraj Húska > > Currently, {{faces-config}} with version 2.0 is added to the all wars generated by framework all tests. See [this|https://github.com/richfaces/richfaces/blob/master/build/build-resou...] > Should not we allow to add this version dynamically to enable JSF 2.1 and 2.2. versions ? -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (RF-13200) Tree: Uncaught TypeError: Object #<Object> has no method '$'

by Pavol Pitonak (JIRA)

Pavol Pitonak created RF-13200: ---------------------------------- Summary: Tree: Uncaught TypeError: Object #<Object> has no method '$' Key: RF-13200 URL: https://issues.jboss.org/browse/RF-13200 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-tree Affects Versions: 5.0.0.Alpha2 Environment: RichFaces 5.0.0-SNAPSHOT Metamer 5.0.0-SNAPSHOT JBoss Application Server: Weld Integration 7.2.1.Final-redhat-10 JBoss AS 7.2.1.Final-redhat-10 Java(TM) SE Runtime Environment 1.7.0_04-b20 @ Linux Chrome 29.0.1547.65 @ Linux x86_64 Reporter: Pavol Pitonak Priority: Blocker # deploy Metamer and open http://127.0.0.1:8080/metamer/faces/components/richTree/treeAdaptors.xhtm... # open node R-1 # open node R-1.1 # click on node R-1.1-M-V-1 expected result: * node should be selected actual: * exception in browser console: Uncaught TypeError: Object #<Object> has no method '$' reason: * response to Ajax request contains this code {code} RichFaces.$("form:richTree").__updateSelectionFromInput(); {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, 9 months

1
0
0 / 0

[JBoss JIRA] (RF-13199) Framework tests does not include all needed classes to the deployment when deploying on WildFly

by Juraj Húska (JIRA)

[ https://issues.jboss.org/browse/RF-13199?page=com.atlassian.jira.plugin.s... ] Juraj Húska updated RF-13199: ----------------------------- Description: When running framework tests with WildFly 8.0.0.Alpha4, some of the tests fail with: _DeploymentException: Cannot deploy_ exception. The created wars miss classes like: {{FrameworkDeployment}} and other linkage errors. See for example [this|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/view...] or [this|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/view...] tests results. The reason is IMHO different *Weld* implementation in WildFly than in JBoss AS 7.1.1.Final, where the same tests are passing. I am also wondering why we are creating wars which contains Arquillian related stuff for client tests ? Should not we create more granular deployment, which will distinguish among client, server and warp tests ? was: When running framework tests with WildFly 8.0.0.Alpha4, some of the tests fail with: _DeploymentException: Cannot deploy_ exception. The created wars miss classes like: {{FrameworkDeployment}} and other linkage errors. See for example [this|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/view...] or [this|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/view...] tests results. The reason is IMHO different Weld implementation in WildFly than in JBoss AS 7.1.1.Final, where the same tests are passing. I am also wondering why we are creating wars which contains Arquillian related stuff for client tests ? > Framework tests does not include all needed classes to the deployment when deploying on WildFly > ----------------------------------------------------------------------------------------------- > > Key: RF-13199 > URL: https://issues.jboss.org/browse/RF-13199 > Project: RichFaces > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: tests - functional > Affects Versions: 5.0.0.Alpha1 > Environment: WildFly 8.0.0.Alpha4 > Reporter: Juraj Húska > > When running framework tests with WildFly 8.0.0.Alpha4, some of the tests fail with: _DeploymentException: Cannot deploy_ exception. > The created wars miss classes like: {{FrameworkDeployment}} and other linkage errors. See for example [this|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/view...] or [this|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/view...] tests results. > The reason is IMHO different *Weld* implementation in WildFly than in JBoss AS 7.1.1.Final, where the same tests are passing. > I am also wondering why we are creating wars which contains Arquillian related stuff for client tests ? Should not we create more granular deployment, which will distinguish among client, server and warp tests ? -- 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, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

richfaces-issues September 2013