[JBoss JIRA] (WFLY-7579) rts integration tests failed when building with jdk 9
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-7579?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on WFLY-7579:
---------------------------------
you could try to add "--add-opens=java.base/java.lang=ALL-UNNAMED" or maybe others options with $JAVA_OPTS to start the server.
> rts integration tests failed when building with jdk 9
> -----------------------------------------------------
>
> Key: WFLY-7579
> URL: https://issues.jboss.org/browse/WFLY-7579
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite, Transactions
> Reporter: Amos Feng
> Assignee: Amos Feng
>
> It can not start the wildfly with the exception
> {code}
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected java.lang.Package java.lang.ClassLoader.getPackage(java.lang.String) accessible: module java.base does not "exports private java.lang" to unnamed module @77e4c80f
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8815) WeldApplication should extend ApplicationWrapper
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-8815?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-8815:
---------------------------------
Issue Type: Bug (was: Feature Request)
> WeldApplication should extend ApplicationWrapper
> ------------------------------------------------
>
> Key: WFLY-8815
> URL: https://issues.jboss.org/browse/WFLY-8815
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.1.0.Final
> Environment: WildFly 10.1.0.Final with JSF 2.3
> Reporter: Bauke Scholtz
> Assignee: Stuart Douglas
>
> When upgrading WildFly 10.x to JSF 2.3, then running a web application using any JSF library having a custom javax.faces.application.Application will result in an UnsupportedOperationException during startup.
> {code}
> Caused by: java.lang.UnsupportedOperationException
> at javax.faces.application.Application.getSearchExpressionHandler(Application.java:2001)
> at javax.faces.application.ApplicationWrapper.getSearchExpressionHandler(ApplicationWrapper.java:815)
> at com.sun.faces.config.processor.ApplicationConfigProcessor.setSearchExpressionHandler(ApplicationConfigProcessor.java:738)
> at com.sun.faces.config.processor.ApplicationConfigProcessor.process(ApplicationConfigProcessor.java:382)
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:155)
> at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:138)
> at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:155)
> at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:246)
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:443)
> ... 20 more
> {code}
> This is reported a.o. here http://stackoverflow.com/questions/44076148/why-is-jsf-2-3-not-working-wi...
> This problem has the same grounds as reported in a.o. https://github.com/omnifaces/omnifaces/issues/75 and https://issues.jboss.org/browse/WELD-1805
> Root problem is: {{org.jboss.as.jsf.injection.weld.WeldApplication}} does not extend from JSF's own {{javax.faces.application.ApplicationWrapper}} having all necessary default methods implemented. Instead, it extends from a custom {{org.jboss.as.jsf.injection.weld.ForwardingApplication}} with only JSF 2.2 specific default methods hardcoded instead of relying on API-provided ones.
> Solution: let {{WeldApplication}} extend from {{ApplicationWrapper}} instead.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8816) WeldApplication should extend ApplicationWrapper
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-8816:
------------------------------------
Summary: WeldApplication should extend ApplicationWrapper
Key: WFLY-8816
URL: https://issues.jboss.org/browse/WFLY-8816
Project: WildFly
Issue Type: Feature Request
Components: CDI / Weld
Affects Versions: 10.1.0.Final
Environment: WildFly 10.1.0.Final with JSF 2.3
Reporter: Bauke Scholtz
Assignee: Stuart Douglas
When upgrading WildFly 10.x to JSF 2.3, then running a web application using any JSF library having a custom javax.faces.application.Application will result in an UnsupportedOperationException during startup.
{code}
Caused by: java.lang.UnsupportedOperationException
at javax.faces.application.Application.getSearchExpressionHandler(Application.java:2001)
at javax.faces.application.ApplicationWrapper.getSearchExpressionHandler(ApplicationWrapper.java:815)
at com.sun.faces.config.processor.ApplicationConfigProcessor.setSearchExpressionHandler(ApplicationConfigProcessor.java:738)
at com.sun.faces.config.processor.ApplicationConfigProcessor.process(ApplicationConfigProcessor.java:382)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:155)
at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:138)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:155)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:246)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:443)
... 20 more
{code}
This is reported a.o. here http://stackoverflow.com/questions/44076148/why-is-jsf-2-3-not-working-wi...
This problem has the same grounds as reported in a.o. https://github.com/omnifaces/omnifaces/issues/75 and https://issues.jboss.org/browse/WELD-1805
Root problem is: {{org.jboss.as.jsf.injection.weld.WeldApplication}} does not extend from JSF's own {{javax.faces.application.ApplicationWrapper}} having all necessary default methods implemented. Instead, it extends from a custom {{org.jboss.as.jsf.injection.weld.ForwardingApplication}} with only JSF 2.2 specific default methods hardcoded instead of relying on API-provided ones.
Solution: let {{WeldApplication}} extend from {{ApplicationWrapper}} instead.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8432) Support socket-binding attribute "client-mapping" in messaging subsystem
by Heribert Steuer (JIRA)
[ https://issues.jboss.org/browse/WFLY-8432?page=com.atlassian.jira.plugin.... ]
Heribert Steuer commented on WFLY-8432:
---------------------------------------
Hello Bartosz,
thanks alot for this patch. I have applied your changed to the 10.x branch and did some tests to run the jmx quickstart project through the proxy. Running the test without the reverse proxy works well, after adding
the appropriate client-mapping attribute to the socket-binding and looping traffic through the proxy leads to exceptions at the client level (see below).
Is there probably anything missing in order to run JMS through a reverse proxy?
After a successful looking up the queue using JNDI, the client throws the following exception:
bq. Exception in thread "main" javax.jms.JMSRuntimeException: Failed to create session factory
bq. at org.apache.activemq.artemis.jms.client.JmsExceptionUtils.convertToRuntimeException(JmsExceptionUtils.java:88)
bq. at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createContext(ActiveMQConnectionFactory.java:262)
bq. at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createContext(ActiveMQConnectionFactory.java:248)
bq. at org.jboss.as.quickstarts.ejb.remote.client.RemoteEJBClient.makeJmsCall(RemoteEJBClient.java:320)
bq. at org.jboss.as.quickstarts.ejb.remote.client.RemoteEJBClient.main(RemoteEJBClient.java:56)
bq. Caused by: javax.jms.JMSException: Failed to create session factory
bq. at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:727)
bq. at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createContext(ActiveMQConnectionFactory.java:255)
bq. ... 3 more
bq. Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119007: Cannot connect to server(s). Tried with all available servers.]
bq. at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:778)
bq. at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:724)
bq. ... 4 more
> Support socket-binding attribute "client-mapping" in messaging subsystem
> ------------------------------------------------------------------------
>
> Key: WFLY-8432
> URL: https://issues.jboss.org/browse/WFLY-8432
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final
> Reporter: Jörg Bäsner
> Assignee: Bartosz Spyrko-Śmietanko
> Fix For: 11.0.0.Beta1
>
>
> The messaging subsystem doesn't take into account the "client-mapping" attribute of the <socket-binding> when creating a <http-connector>.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-2850) AbstractRuntimeOnlyHandler should not add its step on a profile=* resource
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2850:
----------------------------------------
Summary: AbstractRuntimeOnlyHandler should not add its step on a profile=* resource
Key: WFCORE-2850
URL: https://issues.jboss.org/browse/WFCORE-2850
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The child resources of /profile=* do not have a runtime behind them, so AbstractRuntimeOnlyStepHandler should not add its Stage.RUNTIME step if the target resources is in that tree.
This will make it possible to use this class if as part of WFCORE-389 we lift the (currently unenforced) restriction on adding runtime-only ops to profile resources in order to have the DC roll them out to relevant servers. It's particular important in the context of the related WFCORE-2815, which would result in the current AbstractRuntimeOnlyStepHandler impl failing if used on a profile resource, since the step it adds would be rejected.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8309) build.sh and integration-tests.sh scripts doesn't work on Solaris SPARC
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-8309?page=com.atlassian.jira.plugin.... ]
Romain Pelisse reopened WFLY-8309:
----------------------------------
Provided fix did not help - issue is a bug in the bash interpreter.
> build.sh and integration-tests.sh scripts doesn't work on Solaris SPARC
> -----------------------------------------------------------------------
>
> Key: WFLY-8309
> URL: https://issues.jboss.org/browse/WFLY-8309
> Project: WildFly
> Issue Type: Bug
> Components: Build System, Test Suite
> Reporter: Peter Palaga
> Assignee: Romain Pelisse
> Priority: Critical
> Fix For: 11.0.0.Beta1
>
>
> Solaris 10 SPARC and Solaris 11 SPARC are supported platforms.
> This issue is regression against EAP 7.1.0.DR11.
> *Wrong behaviour in EAP 7.1.0.DR12*
> build.sh and integration-tests.sh scripts doesn't work on Solaris SPARC.
> *Desired behaviour*
> build.sh and integration-tests.sh scripts should work on Solaris SPARC.
> *Solaris 10*
> * Solaris 10 SPARC release information:
> {noformat}
> [hudson@dev139-03 ~]$ cat /etc/release
> Oracle Solaris 10 1/13 s10s_u11wos_24a SPARC
> Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved.
> Assembled 17 January 2013
> [hudson@dev139-03 ~]$
> {noformat}
> * logs from build.sh
> {noformat}
> 07:39:36 + ./build.sh -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/abacf11d/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dts.noSmoke
> 07:39:36 ./build.sh: syntax error at line 20: `DIRNAME="$( cd "$' unexpected
> {noformat}
> * logs from integration-tests.sh:
> {noformat}
> 07:43:10 + ./integration-tests.sh -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dnode0=10.16.178.25 -Dnode1=10.16.178.26 -Dmcast=227.43.91.56 -DallTests -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/jboss-eap-7.1
> 07:43:10 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/mvnw install -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dnode0=10.16.178.25 -Dnode1=10.16.178.26 -Dmcast=227.43.91.56 -DallTests -fae -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/jboss-eap-7.1 -s /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/tools/maven/conf/settings.xml
> 07:43:10 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/abacf11d/mvnw: syntax error at line 190: `(' unexpected
> {noformat}
> *Solaris 11*
> * Solaris 11 SPARC release information:
> {noformat}
> [hudson@dev34-03 ~]$ cat /etc/release
> Oracle Solaris 11.3 SPARC
> Copyright (c) 1983, 2016, Oracle and/or its affiliates. All rights reserved.
> Assembled 03 August 2016
> [hudson@dev34-03 ~]$
> {noformat}
> * logs from build.sh
> {noformat}
> 07:39:35 + ./build.sh -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/e745cc07/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dts.noSmoke
> 07:39:35 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/e745cc07/mvnw install '-Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/e745cc07/eap-local-maven-repository' '-fae' '-Dmaven.test.failure.ignore=true' '-Dts.noSmoke'
> 07:39:35 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/e745cc07/mvnw[190]: local: not found [No such file or directory]
> 07:39:35 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-unit-solaris/e745cc07/mvnw[191]: local: not found [No such file or directory]
> 07:39:36 Error: Could not find or load main class org.apache.maven.wrapper.MavenWrapperMain
> {noformat}
> * logs from integration-tests.sh:
> {noformat}
> 7:43:15 + ./integration-tests.sh -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dnode0=10.16.179.32 -Dnode1=10.16.179.33 -Dmcast=227.43.91.214 -DallTests -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/jboss-eap-7.1
> 07:43:15 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/mvnw install -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/eap-local-maven-repository -fae -Dmaven.test.failure.ignore=true -Dnode0=10.16.179.32 -Dnode1=10.16.179.33 -Dmcast=227.43.91.214 -DallTests -fae -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/jboss-eap-7.1 -s /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/tools/maven/conf/settings.xml
> 07:43:15 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/mvnw[190]: local: not found [No such file or directory]
> 07:43:15 /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-solaris/e745cc07/mvnw[191]: local: not found [No such file or directory]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (WFLY-7579) rts integration tests failed when building with jdk 9
by Jessica Lundberg (JIRA)
[ https://issues.jboss.org/browse/WFLY-7579?page=com.atlassian.jira.plugin.... ]
Jessica Lundberg edited comment on WFLY-7579 at 5/20/17 4:19 PM:
-----------------------------------------------------------------
Hi,
I just installed the latest Wildfly 10.1 final release and the latest windows build for JDK 9 and I am getting this exception when I run domain.bat. What is the fix? There isn't an option that I see to download the JDK 9 without jigsaw.
was (Author: jessicallundberg):
Hi,
I just installed the latest Wildfly 10.1 final release and the latest windows build for JDK 9 and I am getting this exception. What is the fix? There isn't an option that I see to download the JDK 9 without jigsaw.
> rts integration tests failed when building with jdk 9
> -----------------------------------------------------
>
> Key: WFLY-7579
> URL: https://issues.jboss.org/browse/WFLY-7579
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite, Transactions
> Reporter: Amos Feng
> Assignee: Amos Feng
>
> It can not start the wildfly with the exception
> {code}
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected java.lang.Package java.lang.ClassLoader.getPackage(java.lang.String) accessible: module java.base does not "exports private java.lang" to unnamed module @77e4c80f
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months