May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10221) Hot deployment causes cascading redeployment of dependent artfacts when using jboss-all.xml configuration files

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-10221?page=com.atlassian.jira.plugin... ] Brian Stansberry resolved WFLY-10221. ------------------------------------- Assignee: Brian Stansberry (was: Jason Greene) Resolution: Won't Fix > Hot deployment causes cascading redeployment of dependent artfacts when using jboss-all.xml configuration files > --------------------------------------------------------------------------------------------------------------- > > Key: WFLY-10221 > URL: https://issues.jboss.org/browse/WFLY-10221 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Final > Reporter: John Doe > Assignee: Brian Stansberry > Priority: Minor > > Let's assume I have 2 files _app.ear_ and _framework.ear_ deployed in WildFly 11. > _framework.ear_ needs to be deployed before _app.ear_ which is expressed by the _jboss-all.xml_ file contained in the app.ear/META-INF folder: > {code:java} > <jboss umlns="urn:jboss:1.0"> > <jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0"> > <dependency name="framework.ear" /> > </jboss-deployment-dependencies> > </jboss> > {code} > Now something changes in _framework.ear_ and a redeployment of _framework.ear_ becomes necessary. > _app.ear_ does get redeployed, too, immediately after a hot deployment of _framework.ear_ has been carried out. > *Observations:* After the redeployment of _framework.ear_ a new _framework.ear.deployed_ marker gets created, but same does not hold for _app.ear.deployed_. > In fact no new _app.ear.deployed_ gets created at all (same timestamp for this file as before) despite a redeployment takes place. > Nevertheless, in the console I see a redeployment for the dependent _app.ear_ occurs. > Extending the example above, this is time consuming when you have a couple of additional dependencies cascading through. > I don't understand why this happens because _app.ear_ did not change. > My expectation is that only a redeployment of _framework.ear_ will take place. In my opinion there is no reason to redeploy _app.ear_, too. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-3866) CLI pom has an unneeded dependency on MSC, causing MSC to get included in the shaded jboss-cli-client.jar

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3866?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3866: ------------------------------------- Description: The cli/pom.xml has this in the "dependencies" section: {code}  <dependency> <groupId>org.jboss.msc</groupId> <artifactId>jboss-msc</artifactId> </dependency> {code} But that's out of date. The analysis for WFCORE-3765 showed that any need for MSC is only on the "embedded server" side, loaded by JBoss Modules, and is not on the embedding app side, needed on the classpath. There used to be use of MSC on the embedding app side but that was removed long ago. Fixing this will reduce the size of the jboss-cli-client.jar. was: The cli/pom.xml has this in the "dependencies" section: {code}  <dependency> <groupId>org.jboss.msc</groupId> <artifactId>jboss-msc</artifactId> </dependency> {code} But that's out of date. The analysis for WFCORE3765 showed that any need for MSC is only on the "embedded server" side, loaded by JBoss Modules, and is not on the embedding app side, needed on the classpath. There used to be use of MSC on the embedding app side but that was removed long ago. Fixing this will reduce the size of the jboss-cli-client.jar. > CLI pom has an unneeded dependency on MSC, causing MSC to get included in the shaded jboss-cli-client.jar > ---------------------------------------------------------------------------------------------------------- > > Key: WFCORE-3866 > URL: https://issues.jboss.org/browse/WFCORE-3866 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Fix For: 6.0.0.Alpha1 > > > The cli/pom.xml has this in the "dependencies" section: > {code} >  > <dependency> > <groupId>org.jboss.msc</groupId> > <artifactId>jboss-msc</artifactId> > </dependency> > {code} > But that's out of date. The analysis for WFCORE-3765 showed that any need for MSC is only on the "embedded server" side, loaded by JBoss Modules, and is not on the embedding app side, needed on the classpath. There used to be use of MSC on the embedding app side but that was removed long ago. > Fixing this will reduce the size of the jboss-cli-client.jar. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-3866) CLI pom has an unneeded dependency on MSC, causing MSC to get included in the shaded jboss-cli-client.jar

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3866: ---------------------------------------- Summary: CLI pom has an unneeded dependency on MSC, causing MSC to get included in the shaded jboss-cli-client.jar Key: WFCORE-3866 URL: https://issues.jboss.org/browse/WFCORE-3866 Project: WildFly Core Issue Type: Bug Components: CLI Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Fix For: 6.0.0.Alpha1 The cli/pom.xml has this in the "dependencies" section: {code}  <dependency> <groupId>org.jboss.msc</groupId> <artifactId>jboss-msc</artifactId> </dependency> {code} But that's out of date. The analysis for WFCORE3765 showed that any need for MSC is only on the "embedded server" side, loaded by JBoss Modules, and is not on the embedding app side, needed on the classpath. There used to be use of MSC on the embedding app side but that was removed long ago. Fixing this will reduce the size of the jboss-cli-client.jar. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-241) Bookinfo app is not accessible on b18

by Filip Brychta (JIRA)

[ https://issues.jboss.org/browse/SWSQE-241?page=com.atlassian.jira.plugin.... ] Filip Brychta commented on SWSQE-241: ------------------------------------- Here is error visible in k8s_istio-proxy_productpage container (istio/proxy sidecar): 2018-05-21T07:48:21.140301Z info Envoy command: [-c /etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster productpage --service-node sidecar~10.129.0.120~productpage-v1-586897968d-ssvqw.bookinfo~bookinfo.svc.cluster.local --max-obj-name-len 189 -l info --v2-config-only] 2018-05-21T07:49:06.398090Z info Unable to retrieve availability zone from pilot: Get http://istio-pilot.istio-system:8080/v1/az/productpage/sidecar~10.129.0.1...: dial tcp 172.30.29.218:8080: getsockopt: no route to host > Bookinfo app is not accessible on b18 > ------------------------------------- > > Key: SWSQE-241 > URL: https://issues.jboss.org/browse/SWSQE-241 > Project: Kiali QE > Issue Type: Bug > Reporter: Filip Brychta > Assignee: Michael Foley > > Following job can deploy bookinfo app: > http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/view/istio/job/insta... > It's working fine e.g. on b16 but not on b18. The application is successfully deployed but not accessible via browser -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-241) Bookinfo app is not accessible on b18

by Filip Brychta (JIRA)

[ https://issues.jboss.org/browse/SWSQE-241?page=com.atlassian.jira.plugin.... ] Filip Brychta updated SWSQE-241: -------------------------------- Description: Following job can deploy bookinfo app: http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/view/istio/job/insta... It's working fine e.g. on b16 but not on b18. The application is successfully deployed but not accessible via browser was: Following jobs can deploy bookinfo app: http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Istio-Ansible/ http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/view/istio-apps/job/... It's working fine e.g. on b16 but not on b18. The application is successfully deployed but not accessible via browser > Bookinfo app is not accessible on b18 > ------------------------------------- > > Key: SWSQE-241 > URL: https://issues.jboss.org/browse/SWSQE-241 > Project: Kiali QE > Issue Type: Bug > Reporter: Filip Brychta > Assignee: Michael Foley > > Following job can deploy bookinfo app: > http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/view/istio/job/insta... > It's working fine e.g. on b16 but not on b18. The application is successfully deployed but not accessible via browser -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-246) Move necessary content of hawkular-qe-utils to kiali-qe-utils

by Filip Brychta (JIRA)

[ https://issues.jboss.org/browse/SWSQE-246?page=com.atlassian.jira.plugin.... ] Filip Brychta edited comment on SWSQE-246 at 5/21/18 3:31 PM: -------------------------------------------------------------- Moved hawkular-qe-utils/sws scripts to kiali-qe-utils/scripts/kiali Reconfigured http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Istio-and-Kiali-... http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Nightly-Public-K... http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/IstioOC-cluster-up/ http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/view/kiali/job/Kiali... Disabled following: http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Istio-on-Openshift/ http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/EAP%20Instance%2... http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Openstack%20Inst... was (Author: fbrychta): Moved hawkular-qe-utils/sws scripts to kiali-qe-utils/scripts/kiali Reconfigured http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Istio-and-Kiali-... http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Nightly-Public-K... http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/IstioOC-cluster-up/ Disabled following: http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Istio-on-Openshift/ http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/EAP%20Instance%2... http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Openstack%20Inst... > Move necessary content of hawkular-qe-utils to kiali-qe-utils > ------------------------------------------------------------- > > Key: SWSQE-246 > URL: https://issues.jboss.org/browse/SWSQE-246 > Project: Kiali QE > Issue Type: Task > Reporter: Filip Brychta > Assignee: Filip Brychta > > We still have some scripts in hawkular-qe-utils which are used by kiali. We need to move them to kiali-qe-utils and update jenkins job configs accordingly. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-246) Move necessary content of hawkular-qe-utils to kiali-qe-utils

by Filip Brychta (JIRA)

[ https://issues.jboss.org/browse/SWSQE-246?page=com.atlassian.jira.plugin.... ] Filip Brychta commented on SWSQE-246: ------------------------------------- Moved hawkular-qe-utils/sws scripts to kiali-qe-utils/scripts/kiali Reconfigured http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Istio-and-Kiali-... http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Nightly-Public-K... http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/IstioOC-cluster-up/ Disabled following: http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Istio-on-Openshift/ http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/EAP%20Instance%2... http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Openstack%20Inst... > Move necessary content of hawkular-qe-utils to kiali-qe-utils > ------------------------------------------------------------- > > Key: SWSQE-246 > URL: https://issues.jboss.org/browse/SWSQE-246 > Project: Kiali QE > Issue Type: Task > Reporter: Filip Brychta > Assignee: Filip Brychta > > We still have some scripts in hawkular-qe-utils which are used by kiali. We need to move them to kiali-qe-utils and update jenkins job configs accordingly. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-2569) [DMN Designer] Marshalling of magnet positions

by Roger Martínez (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2569?page=com.atlassian.jira.plugi... ] Roger Martínez commented on DROOLS-2569: ---------------------------------------- Hey [~tari_manga] [~manstis] IIRC once you save a diagam, the locations for the magnets that are being stored are the relative locations respect the shape. So once you load the diagram, it obtain the relative location for the connection, and then it "detects" which is the magnet to use that is nearest to those coordinates (location) - this job is done in the _SetCanvasConnectionCommand_. So the way it uses a certain magnet index it's by comparing the location (given from the xml file, which is also in the Edge domain object) against each of the magnets of the shape. Does that help? > [DMN Designer] Marshalling of magnet positions > ---------------------------------------------- > > Key: DROOLS-2569 > URL: https://issues.jboss.org/browse/DROOLS-2569 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Reporter: Michael Anstis > Assignee: Matteo Mortari > > When attaching connectors to different magnets (other than "centre") re-opening a DMN diagram resets connections to the "centre" magnet. IDK if this is an issue with writing magnet positions to the XML or recreating the connections from the XML. > [~tari_manga] could you please liaise with [~roger600] to understand where the issue is? > h2. PR Acceptance test > In DMN Designer, change magnet position in: > - Source node > -- BKM, BKS, Decision, Input > - Target node > -- BKM, BKS, Decision, Annotation -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-2569) [DMN Designer] Marshalling of magnet positions

by Roger Martínez (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2569?page=com.atlassian.jira.plugi... ] Roger Martínez edited comment on DROOLS-2569 at 5/21/18 3:05 PM: ----------------------------------------------------------------- Hey [~tari_manga] [~manstis] IIRC once you save a diagram, the locations for the magnets that are being stored are the relative locations respect the shape. So once you load the diagram, it obtain the relative location for the connection, and then it "detects" which is the magnet to use that is nearest to those coordinates (location) - this job is done in the _SetCanvasConnectionCommand_. So the way it uses a certain magnet index it's by comparing the location (given from the xml file, which is also in the Edge domain object) against each of the magnets of the shape. Does that help? was (Author: roger600): Hey [~tari_manga] [~manstis] IIRC once you save a diagam, the locations for the magnets that are being stored are the relative locations respect the shape. So once you load the diagram, it obtain the relative location for the connection, and then it "detects" which is the magnet to use that is nearest to those coordinates (location) - this job is done in the _SetCanvasConnectionCommand_. So the way it uses a certain magnet index it's by comparing the location (given from the xml file, which is also in the Edge domain object) against each of the magnets of the shape. Does that help? > [DMN Designer] Marshalling of magnet positions > ---------------------------------------------- > > Key: DROOLS-2569 > URL: https://issues.jboss.org/browse/DROOLS-2569 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Reporter: Michael Anstis > Assignee: Matteo Mortari > > When attaching connectors to different magnets (other than "centre") re-opening a DMN diagram resets connections to the "centre" magnet. IDK if this is an issue with writing magnet positions to the XML or recreating the connections from the XML. > [~tari_manga] could you please liaise with [~roger600] to understand where the issue is? > h2. PR Acceptance test > In DMN Designer, change magnet position in: > - Source node > -- BKM, BKS, Decision, Input > - Target node > -- BKM, BKS, Decision, Annotation -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-201) Bookinfo reinstall step in pipeline

by Filip Brychta (JIRA)

[ https://issues.jboss.org/browse/SWSQE-201?page=com.atlassian.jira.plugin.... ] Filip Brychta resolved SWSQE-201. --------------------------------- Resolution: Done http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Istio-and-Kiali-... now runs http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/view/istio/job/insta... and http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/view/istio/job/insta... See job description for details. There is one issue not related to bookinfo job but is blocking for that - https://issues.jboss.org/browse/SWSQE-241 > Bookinfo reinstall step in pipeline > ----------------------------------- > > Key: SWSQE-201 > URL: https://issues.jboss.org/browse/SWSQE-201 > Project: Kiali QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Filip Brychta > > Done: > In [Istio-and-Kiali-on-Openshift|http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Istio-and-Kiali-on-Openshift/] Pipeline in a step "Install Istio" it installs bookinfo app. But when It does not reinstall Istio, bookinfo will remain the old installed. We need clean installed Bookinfo for test purposes. > The [Istio-Features-Bookinfo|http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Istio-Features-Bookinfo/] job is a separate job which installs bookinfo only. > TODO: > Make sure that Istio-Features-Bookinfo job have an option to "Clean" and "Clean/Reinstall Bookinfo", which means that all Istio related objets are deleted from Bookinfo and Bookinfo is reinstalled. > Make sure that the above job is included in Istio-and-Kiali-on-Openshift pipeline with optional param to activate. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

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 May 2018