August 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10867) Agroal: The 'module' and 'classname' attributes on the driver resource allows expressions

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-10867?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-10867: ------------------------------------ Fix Version/s: 14.0.0.CR1 > Agroal: The 'module' and 'classname' attributes on the driver resource allows expressions > ----------------------------------------------------------------------------------------- > > Key: WFLY-10867 > URL: https://issues.jboss.org/browse/WFLY-10867 > Project: WildFly > Issue Type: Bug > Reporter: Martin Simka > Assignee: Luis Barreiro > Priority: Blocker > Fix For: 14.0.0.CR1 > > > item 5 from [Brian's review|https://github.com/wildfly/wildfly/pull/11176#issuecomment-413283172] > {quote} > The 'module' and 'classname' attributes on the driver resource allows expressions. A bit of black art is we don't allow expressions on those kinds of attributes. TBH there's no great reason for it, but we should be consistent. > {quote} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-378) Random TAG is being generated on deploying from kiali/kiali

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-378?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo reopened SWSQE-378: ------------------------------------------- > Random TAG is being generated on deploying from kiali/kiali > ----------------------------------------------------------- > > Key: SWSQE-378 > URL: https://issues.jboss.org/browse/SWSQE-378 > Project: Kiali QE > Issue Type: Bug > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > > The random tag was included because the images weren't been overridden, but when we are deploying from "kiali/kiali" the exactly tag should be matched > Example: Using Docker tag v0.6.0YWZk from Docker Repo docker.io/kiali/kiali from (http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Kiali-on-Openshi...) > YWZk is the random component. > This need to be switched when are using kialiqe/kiali -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-378) Random TAG is being generated on deploying from kiali/kiali

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-378?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo resolved SWSQE-378. ------------------------------------------- Resolution: Done > Random TAG is being generated on deploying from kiali/kiali > ----------------------------------------------------------- > > Key: SWSQE-378 > URL: https://issues.jboss.org/browse/SWSQE-378 > Project: Kiali QE > Issue Type: Bug > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > > The random tag was included because the images weren't been overridden, but when we are deploying from "kiali/kiali" the exactly tag should be matched > Example: Using Docker tag v0.6.0YWZk from Docker Repo docker.io/kiali/kiali from (http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Kiali-on-Openshi...) > YWZk is the random component. > This need to be switched when are using kialiqe/kiali -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10833) Wildfly 13.0.0.Final deployment failed due to WELD-001409: Ambiguous dependencies for type CompensationManager with qualifiers @Default

by Angela Yuan (JIRA)

[ https://issues.jboss.org/browse/WFLY-10833?page=com.atlassian.jira.plugin... ] Angela Yuan commented on WFLY-10833: ------------------------------------ @Ondra Chaloupka, thank you. That's exactly where the problem is! Please resolve this case. On Thu, Aug 16, 2018 at 4:05 AM Ondra Chaloupka (JIRA) <issues(a)jboss.org> > Wildfly 13.0.0.Final deployment failed due to WELD-001409: Ambiguous dependencies for type CompensationManager with qualifiers @Default > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-10833 > URL: https://issues.jboss.org/browse/WFLY-10833 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 13.0.0.Final > Environment: JDK 8 > Wildfly 13.0.0.Final > Reporter: Angela Yuan > Assignee: Ondra Chaloupka > > Able to deploy the same WAR and EAR to Wildfly 10.0.0.Final but not to 13.0.0.Final with the following error: > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."xxxxx.war".WeldStartService: org.jboss.msc.service.S > tartException in service jboss.deployment.unit."fwdm-services-1.0-SNAPSHOT.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1728) > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > at java.lang.Thread.run(Thread.java:748) > Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type CompensationManager with qualifiers @Default > at injection point [UnbackedAnnotatedField] @Inject org.jboss.narayana.compensations.impl.CancelOnFailureInterceptor.compensationManager > at org.jboss.narayana.compensations.impl.CancelOnFailureInterceptor.compensationManager(CancelOnFailureInterceptor.java:0) > Possible dependencies: > - Managed Bean [class org.jboss.narayana.compensations.internal.CompensationManagerImpl] with qualifiers [@Any @Default], > - Managed Bean [class org.jboss.narayana.compensations.impl.CompensationManagerImpl] with qualifiers [@Any @Default] > at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:386) > at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:290) > at org.jboss.weld.bootstrap.Validator.validateInterceptor(Validator.java:564) > at org.jboss.weld.bootstrap.ConcurrentValidator$2.doWork(ConcurrentValidator.java:81) > at org.jboss.weld.bootstrap.ConcurrentValidator$2.doWork(ConcurrentValidator.java:79) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-378) Random TAG is being generated on deploying from kiali/kiali

by Guilherme Baufaker Rêgo (JIRA)

Guilherme Baufaker Rêgo created SWSQE-378: --------------------------------------------- Summary: Random TAG is being generated on deploying from kiali/kiali Key: SWSQE-378 URL: https://issues.jboss.org/browse/SWSQE-378 Project: Kiali QE Issue Type: Bug Reporter: Guilherme Baufaker Rêgo Assignee: Michael Foley The random tag was included because the images weren't been overridden, but when we are deploying from "kiali/kiali" the exactly tag should be matched Example: Using Docker tag v0.6.0YWZk from Docker Repo docker.io/kiali/kiali from (http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Kiali-on-Openshi...) YWZk is the random component. This need to be switched when are using kialiqe/kiali -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-378) Random TAG is being generated on deploying from kiali/kiali

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-378?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo updated SWSQE-378: ------------------------------------------ Sprint: Kiali QE Sprint 9 > Random TAG is being generated on deploying from kiali/kiali > ----------------------------------------------------------- > > Key: SWSQE-378 > URL: https://issues.jboss.org/browse/SWSQE-378 > Project: Kiali QE > Issue Type: Bug > Reporter: Guilherme Baufaker Rêgo > Assignee: Michael Foley > > The random tag was included because the images weren't been overridden, but when we are deploying from "kiali/kiali" the exactly tag should be matched > Example: Using Docker tag v0.6.0YWZk from Docker Repo docker.io/kiali/kiali from (http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Kiali-on-Openshi...) > YWZk is the random component. > This need to be switched when are using kialiqe/kiali -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-378) Random TAG is being generated on deploying from kiali/kiali

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-378?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo reassigned SWSQE-378: --------------------------------------------- Assignee: Guilherme Baufaker Rêgo (was: Michael Foley) > Random TAG is being generated on deploying from kiali/kiali > ----------------------------------------------------------- > > Key: SWSQE-378 > URL: https://issues.jboss.org/browse/SWSQE-378 > Project: Kiali QE > Issue Type: Bug > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > > The random tag was included because the images weren't been overridden, but when we are deploying from "kiali/kiali" the exactly tag should be matched > Example: Using Docker tag v0.6.0YWZk from Docker Repo docker.io/kiali/kiali from (http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Kiali-on-Openshi...) > YWZk is the random component. > This need to be switched when are using kialiqe/kiali -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10847) Multiple service modules in single EAR use same tracer instance

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-10847?page=com.atlassian.jira.plugin... ] Brad Maxwell edited comment on WFLY-10847 at 8/16/18 2:29 PM: -------------------------------------------------------------- Typically in JavaEE the spec talks about applications as being an ear or a war. Practically though customers deploy ejb.jars, wars, ears, rars, etc. And ear is a packaging mechanism to package up multiple sub deployments. An ear could be considered a single application, but that does not mean it has a single entry point, it could be exposing many services such as EJBs that can be invoked inVM or remotely as well as it could be exposing web applications / JAXRS/ JAXWS web services. I looked around and am not clear on what it means to have 1 tracer, but looking at OpenTrace it looks like showing workflow or such? I think since an ear could be considered 1 application, it might also be used to hold multiple applications that have many services and just used to share some libraries. The very simple typical example would be: application.ear - web-app.war - backend-ejb.jar browser -> http://host:8080/web-app/ -> Servlet1 in web-app.war -> EJB1 in backend-ejb browser -> http://host:8080/web-app/ -> Servlet2 in web-app.war -> EJB2 in backend-ejb -> EJB3 in backend-ejb But most customers have more than a single war/ejb such as: application.ear - web-app.war - web-app2.war ... - backend-service-1-ejb.jar - backend-service-2-ejb.jar ... But then services inside of application.ear might also call services in application2.ear deployed on the same server. application2.ear - backend-service-3-ejb.jar - backend-service-4-ejb.jar More complex use cases would involve multiple servers where services in an application.ear might call services on the same JVM but then call remote services on another JVM. So if we are showing the path / workflow of an ear, I can see users wanting to see inside of what happens in the ear. was (Author: bmaxwell): Typically in JavaEE the spec talks about applications as being an ear or a war. Practically though customers deploy ejb.jars, wars, ears, rars, etc. And ear is a packaging mechanism to package up multiple sub deployments. An ear could be considered a single application, but that does not mean it has a single entry point, it could be exposing many services such as EJBs that can be invoked inVM or remotely as well as it could be exposing web applications / JAXRS/ JAXWS web services. I looked around and am not clear on what it means to have 1 tracer, but looking at OpenTrace it looks like showing workflow or such? I think since an ear could be considered 1 application, it might also be used to hold multiple applications that have many services and just used to share some libraries. The very simple typical example would be: application.ear - web-app.war - backend-ejb.jar browser -> http://host:8080/web-app/ -> Servlet1 in web-app.war -> EJB1 in backend-ejb browser -> http://host:8080/web-app/ -> Servlet2 in web-app.war -> EJB2 in backend-ejb -> EJB3 in backend-ejb But most customers have more than a single war/ejb such as: application.ear - web-app.war - web-app2.war ... - backend-service-1-ejb.jar - backend-service-2-ejb.jar ... But then services inside of application.ear might also call services in application2.ear deployed on the same server. application2.ear - backend-service-3-ejb.jar - backend-service-4-ejb.jar More complex use cases would involve multiple servers where services in an application.ear might call services on the same JVM but then call remote services on another JVM. > Multiple service modules in single EAR use same tracer instance > --------------------------------------------------------------- > > Key: WFLY-10847 > URL: https://issues.jboss.org/browse/WFLY-10847 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Reporter: Michal Jurc > Assignee: Juraci Paixão Kröhling > Priority: Blocker > Fix For: 14.0.0.CR1 > > > When deploying an EAR with two stand-alone JAX-RS services in stand-alone WAR modules, both of the services use the same {{Tracer}} instance. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10847) Multiple service modules in single EAR use same tracer instance

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-10847?page=com.atlassian.jira.plugin... ] Brad Maxwell commented on WFLY-10847: ------------------------------------- Typically in JavaEE the spec talks about applications as being an ear or a war. Practically though customers deploy ejb.jars, wars, ears, rars, etc. And ear is a packaging mechanism to package up multiple sub deployments. An ear could be considered a single application, but that does not mean it has a single entry point, it could be exposing many services such as EJBs that can be invoked inVM or remotely as well as it could be exposing web applications / JAXRS/ JAXWS web services. I looked around and am not clear on what it means to have 1 tracer, but looking at OpenTrace it looks like showing workflow or such? I think since an ear could be considered 1 application, it might also be used to hold multiple applications that have many services and just used to share some libraries. The very simple typical example would be: application.ear - web-app.war - backend-ejb.jar browser -> http://host:8080/web-app/ -> Servlet1 in web-app.war -> EJB1 in backend-ejb browser -> http://host:8080/web-app/ -> Servlet2 in web-app.war -> EJB2 in backend-ejb -> EJB3 in backend-ejb But most customers have more than a single war/ejb such as: application.ear - web-app.war - web-app2.war ... - backend-service-1-ejb.jar - backend-service-2-ejb.jar ... But then services inside of application.ear might also call services in application2.ear deployed on the same server. application2.ear - backend-service-3-ejb.jar - backend-service-4-ejb.jar More complex use cases would involve multiple servers where services in an application.ear might call services on the same JVM but then call remote services on another JVM. > Multiple service modules in single EAR use same tracer instance > --------------------------------------------------------------- > > Key: WFLY-10847 > URL: https://issues.jboss.org/browse/WFLY-10847 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Reporter: Michal Jurc > Assignee: Juraci Paixão Kröhling > Priority: Blocker > Fix For: 14.0.0.CR1 > > > When deploying an EAR with two stand-alone JAX-RS services in stand-alone WAR modules, both of the services use the same {{Tracer}} instance. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-21) [Artemis 2.x upgrade] Lost message when MDB is resending messages under high load

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFWIP-21?page=com.atlassian.jira.plugin.s... ] Miroslav Novak commented on WFWIP-21: ------------------------------------- Run with latest WF branch and Artemis 2.x/master passed 20 times: https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag... I'll kill this jobs as I need to trigger the full scale testing. However it seems that this issue might be fixed. > [Artemis 2.x upgrade] Lost message when MDB is resending messages under high load > --------------------------------------------------------------------------------- > > Key: WFWIP-21 > URL: https://issues.jboss.org/browse/WFWIP-21 > Project: WildFly WIP > Issue Type: Bug > Components: Artemis > Reporter: Miroslav Novak > Assignee: Martyn Taylor > Priority: Blocker > Labels: activemq, feature-branch-blocker > > Test scenario: > * Start cluster A of nodes node-1, node-3 > * Start cluster B of nodes node-2, node-4 > * Send messages to queue on node-1 > * Deploy mdbs to servers in cluster A. This mdb reads messages from local queue, sends them to remote queue on cluster B and inserts them into database > * Deploy mdbs to servers in cluster B. This mdb reads messages from local queue and inserts them into database > * Cause CPU overload (for 5 min) on server node-2 when mdbs on cluster1 and 2 are processing mesages > * Restart failed server > * Let MDBs to process remaining messages > Pass Criteria: Number of sent message is equal number of records(lines) in database and messages in > Actual Result: > Sometimes happens that one record is missing in database which means that one message was not processed be MDB in cluster 2. > This looks like broker related regression against Artemis 1.5. > Wildfly: https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (06c878a313d3cad323889d017e60fd5533204d1a) > Artemis tag 2.5.0.Final -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2018