[JBoss JIRA] (WFLY-10655) SEVERE error on deploy of ear: "Unable to obtain CDI 1.1 utilities for Mojarra"
by tommaso borgato (JIRA)
[ https://issues.jboss.org/browse/WFLY-10655?page=com.atlassian.jira.plugin... ]
tommaso borgato updated WFLY-10655:
-----------------------------------
Attachment: clusterbench-ee7.ear
> SEVERE error on deploy of ear: "Unable to obtain CDI 1.1 utilities for Mojarra"
> -------------------------------------------------------------------------------
>
> Key: WFLY-10655
> URL: https://issues.jboss.org/browse/WFLY-10655
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JSF
> Affects Versions: 13.0.0.Final
> Reporter: tommaso borgato
> Assignee: Dmitrii Tikhomirov
> Attachments: clusterbench-ee7.ear
>
>
> Affected scenario is [eap-7x-failover-ejb-ejbservlet-undeploy-repl-sync|https://jenkins.hosts.m...].
> Every time the server is stated or re-started, we observed the following SEVERE logs just after clusterbench is deployed (clusterbench is an ear that uses JSF); we observed them systematically on each of the 4 nodes composing the cluster:
> {noformat}
> 2018-06-27 02:47:07,439 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 72) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-granular.war cache from web container
> 2018-06-27 02:47:07,440 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 75) WFLYCLINF0002: Started client-mappings cache from ejb container
> 2018-06-27 02:47:07,440 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 73) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-default.war cache from web container
> 2018-06-27 02:47:07,440 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 74) WFLYCLINF0002: Started default-server cache from web container
> 2018-06-27 02:47:07,439 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 76) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war cache from web container
> 2018-06-27 02:47:07,578 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 75) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
> 2018-06-27 02:47:07,673 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-7) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class org.jberet.creation.BatchBeanProducer is deprecated from CDI 1.1!
> 2018-06-27 02:47:07,713 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-7) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor is deprecated from CDI 1.1!
> 2018-06-27 02:47:07,739 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-7) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class com.sun.faces.flow.FlowDiscoveryCDIHelper is deprecated from CDI 1.1!
> 2018-06-27 02:47:08,149 SEVERE [javax.enterprise.resource.webcontainer.jsf.flow] (MSC service thread 1-7) Unable to obtain CDI 1.1 utilities for Mojarra
> 2018-06-27 02:47:08,163 SEVERE [javax.enterprise.resource.webcontainer.jsf.application.view] (MSC service thread 1-7) Unable to obtain CDI 1.1 utilities for Mojarra
> 2018-06-27 02:47:08,586 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 76) Initializing Mojarra 2.2.13.SP5 for context '/clusterbench-granular'
> 2018-06-27 02:47:08,586 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 72) Initializing Mojarra 2.2.13.SP5 for context '/clusterbench'
> 2018-06-27 02:47:08,587 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 78) Initializing Mojarra 2.2.13.SP5 for context '/clusterbench-passivating'
> 2018-06-27 02:47:09,860 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 76) WFLYUT0021: Registered web context: '/clusterbench-granular' for server 'default-server'
> 2018-06-27 02:47:09,863 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 72) WFLYUT0021: Registered web context: '/clusterbench' for server 'default-server'
> 2018-06-27 02:47:09,863 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 78) WFLYUT0021: Registered web context: '/clusterbench-passivating' for server 'default-server'
> 2018-06-27 02:47:09,889 INFO [org.jboss.as.server] (ServerService Thread Pool -- 42) WFLYSRV0010: Deployed "clusterbench-ee7.ear" (runtime-name : "clusterbench-ee7.ear")
> 2018-06-27 02:47:09,989 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
> {noformat}
>
> Complete log [here|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap...]
> Already observed a very long time ago: https://issues.jboss.org/browse/WFLY-1946
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10474) AMQ119012: Timed out waiting to receive initial broadcast from cluster
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10474?page=com.atlassian.jira.plugin... ]
Erich Duda commented on WFLY-10474:
-----------------------------------
[~pferraro] In the run \[1\] the reproducer passed 39 times and then failed because of different issue. I retriggered it and the second run \[2\] passed 50 times in row.
[~ataylor] [~martyn-taylor] Can you please rebase your Wildfly branch and try to reproduce the issue? In the meantime I will try to reproduce it with Wildfly 12 which is, based on my previous comment, affected by this issue.
\[1\] https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag...
\[2\] https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag...
> AMQ119012: Timed out waiting to receive initial broadcast from cluster
> ----------------------------------------------------------------------
>
> Key: WFLY-10474
> URL: https://issues.jboss.org/browse/WFLY-10474
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 13.0.0.Beta1
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: blocker-WF14
>
> In messaging HA scenarios we see that tests sometimes fail because of exception \[1\]. The exception is thrown from {{ServerLocatorImpl::createSessionFactory}} which waits until initial broadcast from cluster is received, but it is not received in 10 seconds timeout. In following scenario the issue causes split brain - both live and backup are active at the same time.
> *Scenario*
> * There are two Wildfly/Artemis servers configured as Live-Backup pair
> * Live server is killed
> * Backup server becomes new Live server
> * Live server is restarted and failback is performed
> *Expectation:* Failback performs successfully. Original Live becomes Live again and original Backup becomes Backup again.
> *Reality:* After the Live is restarted, it does not detect that there is already another active Live with the same nodeId and it activates (becomes Live) so both Live and Backup are active at the same time.
> *Technical details*
> I found out that original Live server does not detect that its Backup is active, because SharedNothingLiveActivation::isNodeIdUsed returns false. I added more logs to this method and found out that the {{false}} is returned from line \[2\] after that the exception \[1\] is thrown.
> *Investigation report*
> I tried to downgrade Artemis to {{1.5.5.jbossorg-010}} version but I hit the same issue. So the issue is not caused by recent Artemis upgrade.
> It is regression against EAP 7.1.0.GA but it is not regression against Wildfly 12.
> We see the issue only with JGroups. I tried to run the test with Netty discovery and it passed 50 times in row.
> \[1\]
> {code}
> ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ119012: Timed out waiting to receive initial broadcast from cluster]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:749) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:627) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connectNoWarnings(ServerLocatorImpl.java:633) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.isNodeIdUsed(SharedNothingLiveActivation.java:280) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.run(SharedNothingLiveActivation.java:90) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:539) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:485) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:413) [artemis-jms-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:205) [wildfly-messaging-activemq-13.0.0.Beta2-SNAPSHOT.jar:13.0.0.Beta2-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:64) [wildfly-messaging-activemq-13.0.0.Beta2-SNAPSHOT.jar:13.0.0.Beta2-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:99) [wildfly-messaging-activemq-13.0.0.Beta2-SNAPSHOT.jar:13.0.0.Beta2-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_171]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_171]
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> {code}
> \[2\] https://github.com/rh-messaging/jboss-activemq-artemis/blob/465eb8733e465...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFWIP-55) Default value defined on injection point of List and Set fields is not taken into account
by Petr Kremensky (JIRA)
Petr Kremensky created WFWIP-55:
-----------------------------------
Summary: Default value defined on injection point of List and Set fields is not taken into account
Key: WFWIP-55
URL: https://issues.jboss.org/browse/WFWIP-55
Project: WildFly WIP
Issue Type: Bug
Components: MP Config
Reporter: Petr Kremensky
Assignee: Jeff Mesnil
Assume we define a following injection points:
{code:java}
@Inject
@ConfigProperty(name = "myPets", defaultValue = "horse,monkey")
private String[] myArrayPets;
@Inject
@ConfigProperty(name = "myPets", defaultValue = "cat,lama")
private List<String> myListPets;
@Inject
@ConfigProperty(name = "myPets", defaultValue = "dog,mouse")
private Set<String> mySetPets;
{code}
Passing a -DmyPets=snake,ox property work as expected:
{noformat}
myArrayPets : [snake,ox]
myListPets : [snake,ox]
mySetPets : [snake,ox]
{noformat}
but trying to use the defults I get:
{noformat}
myArrayPets : [horse,monkey]
myListPets : <empty list>
mySetPets : <empty set>
{noformat}
defaults are not applied to List and Set fields, no exception is thrown.
Another inconsistency between Array and Set+List I run into is behaviour on missing property (myPets is not set):
*Array*
{code:java}
@Inject
@ConfigProperty(name = "myPets")
private String[] myArrayPets;
>>>
08:34:05,178 ERROR [stderr] (MSC service thread 1-2) org.jboss.weld.exceptions.DeploymentException: Error while validating Configuration
08:34:05,178 ERROR [stderr] (MSC service thread 1-2) No Config Value exists for myPets
myArrayPets : [org.eclipse.microprofile.config.configproperty.unconfigureddvalue]
{code}
*Set, List*
{code:java}
@Inject
@ConfigProperty(name = "myPets")
private List<String> myListPets;
@Inject
@ConfigProperty(name = "myPets")
private Set<String> mySetPets;
>>>
no errors
myListPets : <empty list>
mySetPets : <empty set>
{code}
https://microprofile.io/project/eclipse/microprofile-config/spec/src/main...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10652) Mdb Clustered Singleton Delivery is not working
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-10652?page=com.atlassian.jira.plugin... ]
Miroslav Novak commented on WFLY-10652:
---------------------------------------
[~pferraro] Thanks Paul for the fix. I've just set priority to blocker as this was breaking working feature in previous WF releases.
> Mdb Clustered Singleton Delivery is not working
> ------------------------------------------------
>
> Key: WFLY-10652
> URL: https://issues.jboss.org/browse/WFLY-10652
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Flavia Rainone
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 14.0.0.CR1
>
>
> When trying to deploy an application with clustered singleton MDB delivery, we see this error:
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.ejb3.clustered.singleton"],"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"messaging-clustering-singleton.war\".clustered.singleton.dependency is missing [org.wildfly.ejb3.clustered.singleton]"]}}}
> The clustered singleton service is not being installed with the expected name.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10652) Mdb Clustered Singleton Delivery is not working
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-10652?page=com.atlassian.jira.plugin... ]
Miroslav Novak updated WFLY-10652:
----------------------------------
Priority: Blocker (was: Major)
> Mdb Clustered Singleton Delivery is not working
> ------------------------------------------------
>
> Key: WFLY-10652
> URL: https://issues.jboss.org/browse/WFLY-10652
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Flavia Rainone
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 14.0.0.CR1
>
>
> When trying to deploy an application with clustered singleton MDB delivery, we see this error:
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.ejb3.clustered.singleton"],"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"messaging-clustering-singleton.war\".clustered.singleton.dependency is missing [org.wildfly.ejb3.clustered.singleton]"]}}}
> The clustered singleton service is not being installed with the expected name.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10701) Multi JSF Installer generate myfaces installer with old jars inside
by Erick de Oliveira Leal (JIRA)
[ https://issues.jboss.org/browse/WFLY-10701?page=com.atlassian.jira.plugin... ]
Erick de Oliveira Leal updated WFLY-10701:
------------------------------------------
Description:
running mvn -Djsf-version=2.3.1 -Pmyfaces clean assembly:single on multi-jsf-installer directory generates install-myfaces-2.3.1.zip with 2.2.11 jars inside.
Another issue is after replace 2.2.11 jars and install it, wildfly prints:
~JSF version slot 'myfaces-2.3.1' is missing from module org.jboss.as.jsf-injection
Activated the following JSF Implementations: [main]~
was:
running mvn -Djsf-version=2.3.1 -Pmyfaces clean assembly:single on multi-jsf-installer directory generates install-myfaces-2.3.1.zip with 2.2.11 jars inside.
Another issue is after replace 2.2.11 jars and install it, wildfly prints:
~JSF version slot 'myfaces-2.3.1' is missing from module org.jboss.as.jsf-injection
Activated the following JSF Implementations: [main]~
> Multi JSF Installer generate myfaces installer with old jars inside
> -------------------------------------------------------------------
>
> Key: WFLY-10701
> URL: https://issues.jboss.org/browse/WFLY-10701
> Project: WildFly
> Issue Type: Component Upgrade
> Components: JSF
> Affects Versions: 13.0.0.Final
> Reporter: Erick de Oliveira Leal
> Assignee: Farah Juma
>
> running mvn -Djsf-version=2.3.1 -Pmyfaces clean assembly:single on multi-jsf-installer directory generates install-myfaces-2.3.1.zip with 2.2.11 jars inside.
> Another issue is after replace 2.2.11 jars and install it, wildfly prints:
> ~JSF version slot 'myfaces-2.3.1' is missing from module org.jboss.as.jsf-injection
> Activated the following JSF Implementations: [main]~
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10701) Multi JSF Installer generate myfaces installer with old jars inside
by Erick de Oliveira Leal (JIRA)
[ https://issues.jboss.org/browse/WFLY-10701?page=com.atlassian.jira.plugin... ]
Erick de Oliveira Leal updated WFLY-10701:
------------------------------------------
Description:
running mvn -Djsf-version=2.3.1 -Pmyfaces clean assembly:single on multi-jsf-installer directory generates install-myfaces-2.3.1.zip with 2.2.11 jars inside.
Another issue is after replace 2.2.11 jars and install it, wildfly prints:
~JSF version slot 'myfaces-2.3.1' is missing from module org.jboss.as.jsf-injection
Activated the following JSF Implementations: [main]~
was:running mvn -Djsf-version=2.3.1 -Pmyfaces clean assembly:single on multi-jsf-installer directory generates install-myfaces-2.3.1.zip with 2.2.11 jars inside.
> Multi JSF Installer generate myfaces installer with old jars inside
> -------------------------------------------------------------------
>
> Key: WFLY-10701
> URL: https://issues.jboss.org/browse/WFLY-10701
> Project: WildFly
> Issue Type: Component Upgrade
> Components: JSF
> Affects Versions: 13.0.0.Final
> Reporter: Erick de Oliveira Leal
> Assignee: Farah Juma
>
> running mvn -Djsf-version=2.3.1 -Pmyfaces clean assembly:single on multi-jsf-installer directory generates install-myfaces-2.3.1.zip with 2.2.11 jars inside.
> Another issue is after replace 2.2.11 jars and install it, wildfly prints:
> ~JSF version slot 'myfaces-2.3.1' is missing from module org.jboss.as.jsf-injection
> Activated the following JSF Implementations: [main]~
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years