[JBoss JIRA] (SWSQE-775) Identify uncovered areas
by Guilherme Baufaker Rêgo (Jira)
[ https://issues.jboss.org/browse/SWSQE-775?page=com.atlassian.jira.plugin.... ]
Guilherme Baufaker Rêgo commented on SWSQE-775:
-----------------------------------------------
Those files need to removed from coverage
tests/data/destination_rules_data.go
tests/data/gateway_data.go
tests/data/mesh_policy_data.go
tests/data/policy_data.go
tests/data/service_entry_data.go
tests/data/service_role_data.go
tests/data/virtual_service_data.go
tests/data/workload_data.go
kubernetes/kubetest/mock.go
kubernetes/kiali_monitoring/mock/mock.go
prometheus/prometheustest/mock.go
> Identify uncovered areas
> ------------------------
>
> Key: SWSQE-775
> URL: https://issues.jboss.org/browse/SWSQE-775
> Project: Kiali QE
> Issue Type: Sub-task
> Reporter: Filip Brychta
> Priority: Major
>
> We have the code coverage report so we should be able to identify uncovered areas and create tasks to implement automation.
> Also we need to check if all files in the report are expected (remove mock/test data files)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (DROOLS-3625) [DMN Designer] Remove Stunners Explorer widget from the RHS dock
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3625?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-3625:
----------------------------------------
[~roger.martinez] Or I can simply pass the diagram type ({{DefinitionSet}} or something) and have {{StunnerDocksHandler}} lookup a _provider_ of dock definitions with CDI and the diagram type in the event... this sounds better decoupling. WDYT?
> [DMN Designer] Remove Stunners Explorer widget from the RHS dock
> ----------------------------------------------------------------
>
> Key: DROOLS-3625
> URL: https://issues.jboss.org/browse/DROOLS-3625
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.17.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
>
> The DMN Editor has a "Decision Navigator" widget (in the LHS dock) that currently shows the content of the whole DRG however it will also become the DRD explorer too. This duplicates Stunner's _default_ Explorer widget in the RHS dock.
> The DMN Editor should have Stunner's _default_ widget removed.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-11601) Weld vs Undertow bootstrap: Race condition
by Matěj Novotný (Jira)
[ https://issues.jboss.org/browse/WFLY-11601?page=com.atlassian.jira.plugin... ]
Matěj Novotný edited comment on WFLY-11601 at 6/4/19 10:30 AM:
---------------------------------------------------------------
The approach I outlined above turns out to be wrong.
The {{WeldStartCompletionService}} itself relies on going last (after EE components and in cleanup phase) in order to perform cleanup and optimization for Weld.
Trying to add that as a dependency of {{UndertowDeploymentService}} would then mean a circular dependency or at least a delay in undertow service start which is too big (both are bound to another phase anyway).
I am pretty sure we don't want to back off the optimization as that reduces the runtime overhead and footprint of CDI-related components.
But ATM I just don't know how to solve this on service-bootstrap level.
The only thing that comes to mind is splitting the bootstrap even more - basically taking {{WeldStartup#endInitialization()}} and creating two methods, one that does all the remaining bootstrap work (building {{BeanIdentifierIndex}} plus processing {{BeanDeploymentModules}}) and then other that does all the clean ups plus fires initialized event. But that obviously breaks the code of all integrators (pretty much all EE servers out there). Another nasty hack [don't take me seriously on this one] would be to just extract the remaining boot logic into previous step (validation) and leave the end init to be purely cleaning up, but that's not nice and can again break integrators code.
I'd like to hear what [~mkouba] has to say.
was (Author: manovotn):
The approach I outlined above turns out to be wrong.
The {{WeldStartCompletionService}} itself relies on going last (after EE components and in cleanup phase) in order to perform cleanup and optimization for Weld.
Trying to add that as a dependency of {{UndertowDeploymentService}} would then mean a circular dependency or at least a delay in undertow service start which is too big (both are bound to another phase anyway).
I am pretty sure we don't want to back off the optimization as that reduces the runtime overhead and footprint of CDI-related components.
But ATM I just don't know how to solve this on service-bootstrap level.
The only thing that comes to mind is splitting the bootstrap even more - basically taking {{WeldStartup#endInitialization()}} and creating two methods, one that does all the remaining bootstrap work (building {{BeanIdentifierIndex}} plus processing {{BeanDeploymentModules}}) and then other that does all the clean ups plus fires initialized event. But that obviously breaks the code of all integrators (pretty much all EE servers out there). Another nasty hack would be to just extract the remaining boot logic into previous step (validation) and leave the end init to be purely cleaning up, but that's not nice and can again break integrators code.
I'd like to hear what [~mkouba] has to say.
> Weld vs Undertow bootstrap: Race condition
> ------------------------------------------
>
> Key: WFLY-11601
> URL: https://issues.jboss.org/browse/WFLY-11601
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Web (Undertow)
> Affects Versions: 15.0.1.Final
> Reporter: Stefan Gr
> Assignee: Matěj Novotný
> Priority: Major
> Attachments: TestApp.zip, TestLib.zip, changes.diff, deploy-failed.txt, deploy-mixed-success.txt, deploy-success.txt, test-app-1.0.0.war, weld-core-impl-3.0.5.Final.jar, weld-core-impl-3.0.5.Final.jar
>
>
> WFLY-9732 / WFLY-10784 moves the completion of WELD from the WeldStartService to WeldStartCompetionService. This causes a race condition with the UndertowDeploymentService which executes the servlet listeners for context-initialized which again fires ApplicationScope-initialized events in CDI.
> You can find more in [WELD-2557|https://issues.jboss.org/browse/WELD-2557?focusedCommentId=1368...].
> In short: WeldStartCompletionService and UndertowDeploymentService pushes the logic to the executor service. It may happen, that the logik of undertow runs before the weld completion. Events fired in the servlet listeners won't find all event observers.
> A possible solution would bo to set the WeldStartCompletionService as a dependency of the UndertowDeploymentService
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-11601) Weld vs Undertow bootstrap: Race condition
by Matěj Novotný (Jira)
[ https://issues.jboss.org/browse/WFLY-11601?page=com.atlassian.jira.plugin... ]
Matěj Novotný commented on WFLY-11601:
--------------------------------------
The approach I outlined above turns out to be wrong.
The {{WeldStartCompletionService}} itself relies on going last (after EE components and in cleanup phase) in order to perform cleanup and optimization for Weld.
Trying to add that as a dependency of {{UndertowDeploymentService}} would then mean a circular dependency or at least a delay in undertow service start which is too big (both are bound to another phase anyway).
I am pretty sure we don't want to back off the optimization as that reduces the runtime overhead and footprint of CDI-related components.
But ATM I just don't know how to solve this on service-bootstrap level.
The only thing that comes to mind is splitting the bootstrap even more - basically taking {{WeldStartup#endInitialization()}} and creating two methods, one that does all the remaining bootstrap work (building {{BeanIdentifierIndex}} plus processing {{BeanDeploymentModules}}) and then other that does all the clean ups plus fires initialized event. But that obviously breaks the code of all integrators (pretty much all EE servers out there). Another nasty hack would be to just extract the remaining boot logic into previous step (validation) and leave the end init to be purely cleaning up, but that's not nice and can again break integrators code.
I'd like to hear what [~mkouba] has to say.
> Weld vs Undertow bootstrap: Race condition
> ------------------------------------------
>
> Key: WFLY-11601
> URL: https://issues.jboss.org/browse/WFLY-11601
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Web (Undertow)
> Affects Versions: 15.0.1.Final
> Reporter: Stefan Gr
> Assignee: Matěj Novotný
> Priority: Major
> Attachments: TestApp.zip, TestLib.zip, changes.diff, deploy-failed.txt, deploy-mixed-success.txt, deploy-success.txt, test-app-1.0.0.war, weld-core-impl-3.0.5.Final.jar, weld-core-impl-3.0.5.Final.jar
>
>
> WFLY-9732 / WFLY-10784 moves the completion of WELD from the WeldStartService to WeldStartCompetionService. This causes a race condition with the UndertowDeploymentService which executes the servlet listeners for context-initialized which again fires ApplicationScope-initialized events in CDI.
> You can find more in [WELD-2557|https://issues.jboss.org/browse/WELD-2557?focusedCommentId=1368...].
> In short: WeldStartCompletionService and UndertowDeploymentService pushes the logic to the executor service. It may happen, that the logik of undertow runs before the weld completion. Events fired in the servlet listeners won't find all event observers.
> A possible solution would bo to set the WeldStartCompletionService as a dependency of the UndertowDeploymentService
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (SWSQE-776) Investegate Moving To MW AWS Accounts
by Matthew Mahoney (Jira)
Matthew Mahoney created SWSQE-776:
-------------------------------------
Summary: Investegate Moving To MW AWS Accounts
Key: SWSQE-776
URL: https://issues.jboss.org/browse/SWSQE-776
Project: Kiali QE
Issue Type: QE Task
Reporter: Matthew Mahoney
Assignee: Matthew Mahoney
Service Mesh QE will need to move away from using OS QE/DEV AWS accounts.
Thus, investigate what it takes to move to using MW AWS Accounts (aka: procure and learn what needs to be done to move the team to MW AWS account).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months