[JBoss JIRA] Created: (AS7-1348) Weld breaks RichFaces 4
by Juergen Zimmermann (JIRA)
Weld breaks RichFaces 4
-----------------------
Key: AS7-1348
URL: https://issues.jboss.org/browse/AS7-1348
Project: Application Server 7
Issue Type: Bug
Components: CDI / Weld
Affects Versions: 7.0.0.Final
Environment: Jenkins build 1402
Reporter: Juergen Zimmermann
Assignee: Stuart Douglas
I'm migrating an EAR from JBoss 6 to 7. The Web module is based on RichFaces 4 and Weld. However, I'm getting the stacktrace below. I'll attach a testcase.
Stacktrace:
javax.el.ELException: Cannot convert testcase.PasswordGroup of type class java.lang.String to class [Ljava.lang.Class;
at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:470)
at org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:46)
at org.jboss.weld.util.el.ForwardingExpressionFactory.coerceToType(ForwardingExpressionFactory.java:37)
at com.sun.faces.facelets.tag.BeanPropertyTagRule$LiteralPropertyMetadata.applyMetadata(BeanPropertyTagRule.java:88)
at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81)
at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129)
at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102)
at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.setAttributes(BehaviorsAddingComponentHandlerWrapper.java:115)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doNewComponentActions(ComponentTagHandlerDelegateImpl.java:402)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:159)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:82)
at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:744)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893)
at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
at java.lang.Thread.run(Thread.java:662)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (AS7-1717) mod_cluster needs consistent naming
by Radoslav Husar (JIRA)
mod_cluster needs consistent naming
-----------------------------------
Key: AS7-1717
URL: https://issues.jboss.org/browse/AS7-1717
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Priority: Critical
We have been running into issues with misspelt modcluster, mod_cluster and mod-cluster (and Mod-cluster) for quite some time now, making difficult time for users. Surely there are sometimes rules where we can't stick to proper naming but we should then be able to minimize to two names.
*project name = mod_cluster
*console name = "Mod_cluster Status"
*xsd schema filename = mod-cluster (./docs/schema/jboss-as-mod-cluster_1_0.xsd)
*xmlns = modcluster (eg xmlns="urn:jboss:domain:modcluster:1.0")
*xs elements = mod-cluster (eg mod-cluster-config)
*schema comments = mod_cluster (eg <!-- mod_cluster parameters ...)
*jar name = mod_cluster (ie mod_cluster-1.1.3.Final)
I am not going to name the EAP5 components where names are significantly changed too.
We need this madness to stop soon enough ;-(
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (AS7-1337) Expose Management API for tests
by Karel Piwko (JIRA)
Expose Management API for tests
-------------------------------
Key: AS7-1337
URL: https://issues.jboss.org/browse/AS7-1337
Project: Application Server 7
Issue Type: Feature Request
Components: Test Suite
Affects Versions: 7.0.0.Final
Reporter: Karel Piwko
Assignee: Andrew Rubinger
Priority: Critical
It should be possible to get access to management console/API from the test suite. There is a ModelControllerClient available in CommonDeployableContainer but this is not exposed to user. Creating it externally requires keeping configuration twice.
The client can be likely made an @ArquillianResource via custom provider. It would be useful if it can be run before @Deployment method or at least available in that method because some examples would require for example creating a DataSource before a war can be deployed.
This is crucial so test can prepare required environment.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (AS7-1014) Can't run smoke test from IDE
by Carlo de Wolf (JIRA)
Can't run smoke test from IDE
-----------------------------
Key: AS7-1014
URL: https://issues.jboss.org/browse/AS7-1014
Project: Application Server 7
Issue Type: Bug
Components: Test Suite
Reporter: Carlo de Wolf
Priority: Blocker
When I try to run StandaloneModuleEjbJndiBindingTestCase in Intellij 10.5:
{noformat}
java.lang.RuntimeException: Could not load class
at org.jboss.arquillian.test.spi.SecurityActions.loadClass(SecurityActions.java:67)
at org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder.build(TestRunnerAdaptorBuilder.java:36)
at org.jboss.arquillian.junit.Arquillian.<init>(Arquillian.java:90)
at org.jboss.arquillian.junit.Arquillian.<init>(Arquillian.java:71)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31)
at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:38)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:199)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.lang.ClassNotFoundException: org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at org.jboss.arquillian.test.spi.SecurityActions.loadClass(SecurityActions.java:63)
... 21 more
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months