January 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-2236) Cover marshalling of UnaryTests

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2236?page=com.atlassian.jira.plugi... ] Jozef Marko commented on DROOLS-2236: ------------------------------------- To coverage increased enough, after marshaling of decision tables was implemented, see: - [^org.kie.workbench.common.dmn.backend.definition.v1_1.html] > Cover marshalling of UnaryTests > ------------------------------- > > Key: DROOLS-2236 > URL: https://issues.jboss.org/browse/DROOLS-2236 > Project: Drools > Issue Type: Task > Components: DMN Editor > Affects Versions: 7.6.0.Final > Reporter: Jozef Marko > Assignee: Jozef Marko > Fix For: 7.6.0.Final > > Attachments: index.html, org.kie.workbench.common.dmn.backend.definition.v1_1.html > > > According to the attached jacoco report, the coverage of marshaling {{UnaryTests}} class should be increased. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2236) Cover marshalling of UnaryTests

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2236?page=com.atlassian.jira.plugi... ] Jozef Marko resolved DROOLS-2236. --------------------------------- Fix Version/s: 7.6.0.Final Resolution: Done > Cover marshalling of UnaryTests > ------------------------------- > > Key: DROOLS-2236 > URL: https://issues.jboss.org/browse/DROOLS-2236 > Project: Drools > Issue Type: Task > Components: DMN Editor > Affects Versions: 7.6.0.Final > Reporter: Jozef Marko > Assignee: Jozef Marko > Fix For: 7.6.0.Final > > Attachments: index.html, org.kie.workbench.common.dmn.backend.definition.v1_1.html > > > According to the attached jacoco report, the coverage of marshaling {{UnaryTests}} class should be increased. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9663) Remove OSGi obsolete code

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFLY-9663?page=com.atlassian.jira.plugin.... ] Richard Opalka updated WFLY-9663: --------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/10738, https://github.com/wildfly/wildfly/pull/10783 (was: https://github.com/wildfly/wildfly/pull/10738, https://github.com/wildfly/wildfly/pull/10782) > Remove OSGi obsolete code > ------------------------- > > Key: WFLY-9663 > URL: https://issues.jboss.org/browse/WFLY-9663 > Project: WildFly > Issue Type: Task > Components: OSGi > Affects Versions: 11.0.0.Final > Reporter: Richard Opalka > Assignee: Richard Opalka > Fix For: 12.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2236) Cover marshalling of UnaryTests

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2236?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-2236: -------------------------------- Attachment: org.kie.workbench.common.dmn.backend.definition.v1_1.html > Cover marshalling of UnaryTests > ------------------------------- > > Key: DROOLS-2236 > URL: https://issues.jboss.org/browse/DROOLS-2236 > Project: Drools > Issue Type: Task > Components: DMN Editor > Affects Versions: 7.6.0.Final > Reporter: Jozef Marko > Assignee: Jozef Marko > Attachments: index.html, org.kie.workbench.common.dmn.backend.definition.v1_1.html > > > According to the attached jacoco report, the coverage of marshaling {{UnaryTests}} class should be increased. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2234) Unlocked locks stay locked forever

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2234?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2234: -------------------------------- No, I haven't fixed this yet. As per my other comment on a related issue, I'm not too happy about {{CENTRAL_LOCK}}, as it doesn't handle network partitions (split brain scenarios) properly... I've been thinking to replace / complement the backups with a reconciliation protocol after the coordinator leaves, where the new coord fetches lock information from all lock holders and builds its lock table from that information. This means it would take a bit longer to serve lock requests after a coord change, but we wouldn't need to send requests from the coord to all backups. OTOH, this doesn't solve the issue of split brain scenarios and the {{Lock}} abstraction, which is a bad abstraction to take locks away from someone (after a split heals) and allows for multiple holders of the same lock during the split... > Unlocked locks stay locked forever > ---------------------------------- > > Key: JGRP-2234 > URL: https://issues.jboss.org/browse/JGRP-2234 > Project: JGroups > Issue Type: Bug > Reporter: Bram Klein Gunnewiek > Assignee: Bela Ban > Fix For: 4.0.10 > > Attachments: ClusterSplitLockTest.java, jg_clusterlock_output_testfail.txt > > > As discussed in the mailing list we have issues where locks from the central lock protocol stay locked forever when the coordinator of the cluster disconnects. We can reproduce this with the attached ClusterSplitLockTest.java. Its a race condition and we need to run the test a lot of times (sometimes > 20) before we encounter a failure. > What we think is happening: > In a three node cluster (node A, B and C where node A is the coordinator) unlock requests from B and/or C can be missed when node A leaves and B and/or C don't have the new view installed yet. When, for example, node B takes over coordination it creates the lock table based on the back-ups. Lets say node C has locked the lock with name 'lockX'. Node C performs an unlock of 'lockX' just after node A (gracefully) leaves and sends the unlock request to node A since node C doesn't have the correct view installed yet. Node B has and recreated the lock table where 'lockX' is locked by Node C. Node C doesn't resend the unlock request so 'lockX' gets locked forever. > Attached is the testng test we wrote and the output of a test failure. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2261) [DMN Designer] DND Column width is not preserved

by Jozef Marko (JIRA)

Jozef Marko created DROOLS-2261: ----------------------------------- Summary: [DMN Designer] DND Column width is not preserved Key: DROOLS-2261 URL: https://issues.jboss.org/browse/DROOLS-2261 Project: Drools Issue Type: Bug Components: DMN Editor Affects Versions: 7.6.0.Final Reporter: Jozef Marko Assignee: Michael Anstis Attachments: after-reopen.png, non-saved.png The DND Grid Columns don't preserve column width between savings. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2260) [DMN Designer] Background Color change throws an Exception

by Jozef Marko (JIRA)

Jozef Marko created DROOLS-2260: ----------------------------------- Summary: [DMN Designer] Background Color change throws an Exception Key: DROOLS-2260 URL: https://issues.jboss.org/browse/DROOLS-2260 Project: Drools Issue Type: Bug Components: DMN Editor Affects Versions: 7.6.0.Final Reporter: Jozef Marko Assignee: Michael Anstis Attachments: Screenshot from 2018-01-23 09-04-01.png If user click on the background color picker, the attached exception is thrown. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9663) Remove OSGi obsolete code

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFLY-9663?page=com.atlassian.jira.plugin.... ] Richard Opalka reopened WFLY-9663: ---------------------------------- > Remove OSGi obsolete code > ------------------------- > > Key: WFLY-9663 > URL: https://issues.jboss.org/browse/WFLY-9663 > Project: WildFly > Issue Type: Task > Components: OSGi > Affects Versions: 11.0.0.Final > Reporter: Richard Opalka > Assignee: Richard Opalka > Fix For: 12.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9721) AsyncInvocationTask.get() throws CancellationException

by Denis Shklyaev (JIRA)

Denis Shklyaev created WFLY-9721: ------------------------------------ Summary: AsyncInvocationTask.get() throws CancellationException Key: WFLY-9721 URL: https://issues.jboss.org/browse/WFLY-9721 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 11.0.0.Final Reporter: Denis Shklyaev Priority: Optional AsyncInvocationTask.get() on cancelled task in Wildfly 11 throws CancellationException via EjbLogger, but the behavior is not declared in method signature: {{ public synchronized Object get() throws InterruptedException, ExecutionException { for (;;) switch (status) { case ST_RUNNING: wait(); break; *case ST_CANCELLED: throw EjbLogger.ROOT_LOGGER.taskWasCancelled();* case ST_FAILED: throw new ExecutionException(failed); case ST_DONE: return result; default: throw Assert.impossibleSwitchCase(status); } } }} Wildfly 10.01.0 code is different: {{ public synchronized Object get() throws InterruptedException, ExecutionException { while (!isDone()) { wait(); } if (failed != null) { throw new ExecutionException(failed); } return result; } }} It throws InterruptedException instead as declared. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3594) Wildfly showing the war file status as Failed after restart the server

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-3594?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski commented on WFLY-3594: ------------------------------------------ [~daoudam] - I did not, was not able to reproduce in any way. Are you using latest master? if you do, can you please post exact steps/config and example app? ( and reopen) > Wildfly showing the war file status as Failed after restart the server > ---------------------------------------------------------------------- > > Key: WFLY-3594 > URL: https://issues.jboss.org/browse/WFLY-3594 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 8.0.0.Final > Environment: windows server 2003 32 bit O.S,Java 7,flex, Apache axis web services > Reporter: shaik masthan > Assignee: Bartosz Baranowski > Priority: Minor > Labels: restarting > Original Estimate: 2 days > Remaining Estimate: 2 days > > after successful deployment , war file status is deployed. When i restart the server , war files status is showing as failed. there were no errors in the logs and i am able to access the the application without any problems. > After some time happen , again i restart the server this time war file status is deployed. > intermittently i am viewing this weird behavior with war files w.r. t restarting the server. > let me know any workaround or fix for this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 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 January 2018