February 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9763) Move legacy subsystems to a legacy feature pack

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-9763: --------------------------------- Summary: Move legacy subsystems to a legacy feature pack Key: WFLY-9763 URL: https://issues.jboss.org/browse/WFLY-9763 Project: WildFly Issue Type: Task Affects Versions: 11.0.0.Final Reporter: Jeff Mesnil Assignee: Jeff Mesnil This issue is the result of the proposal to move legacy subsystems in a a legacy feature pack as explained in http://wildfly-development.1055759.n5.nabble.com/proposal-Move-legacy-ext... Impacted subsystems: * cmp * configadmin * jaxr * messaging * web GAV of the created feature-pack: org.wildfly:wildfly-legacy-feature-pack:${wildfly.version} Proposed GitHub repository: github.com/wildfly/wildfly-legacy All the subsystems will keep the same versions than WildFly for the time being. The main functional change is that migration tests are no longer in the legacy subsystems but in the new subsystems that takes responsibility for the migration (e.g. undertow for web, messaging-activemq for messaging). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3797) Need post-timeout for WildFly / Undertow

by Prakash Boda (JIRA)

[ https://issues.jboss.org/browse/WFLY-3797?page=com.atlassian.jira.plugin.... ] Prakash Boda commented on WFLY-3797: ------------------------------------ [~swd847] Do you have idea about what is the default value for all three params your told above? Also guide me if these default values will be effective against Slowloris DOS kind of attack? > Need post-timeout for WildFly / Undertow > ---------------------------------------- > > Key: WFLY-3797 > URL: https://issues.jboss.org/browse/WFLY-3797 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Lyle Wang > Assignee: Stuart Douglas > Fix For: 8.2.0.Final, 9.0.0.Beta1 > > > Is that possible to provide post timeout to prevent DoS ? JBoss AS 7 or WildFly has no such feature/option, but weblogic provides this: > http://docs.oracle.com/cd/E17904_01/web.1111/e13701/web_server.htm#i1059782 > Currently only "max-post-size" is supported: > https://docs.jboss.org/author/display/WFLY8/Undertow+%28web%29+subsystem+... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9762) JMS message is not received when using a non-transactional JMSConnectionFactoryDefinition

by Jiri Ondrusek (JIRA)

[ https://issues.jboss.org/browse/WFLY-9762?page=com.atlassian.jira.plugin.... ] Jiri Ondrusek moved JBEAP-14200 to WFLY-9762: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-9762 (was: JBEAP-14200) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: (was: ActiveMQ) Affects Version/s: (was: 7.1.0.CR1) > JMS message is not received when using a non-transactional JMSConnectionFactoryDefinition > ----------------------------------------------------------------------------------------- > > Key: WFLY-9762 > URL: https://issues.jboss.org/browse/WFLY-9762 > Project: WildFly > Issue Type: Bug > Reporter: Jiri Ondrusek > Assignee: Jiri Ondrusek > > When using a JMSConnectionFactoryDefinition annotation, and specifying a non transactional connection factory, message is not being sent (or at least received by MDB). Example: > {code:java} > @JMSConnectionFactoryDefinitions( > value = { > @JMSConnectionFactoryDefinition( > name = "java:app/jms/nonXAconnectionFactorySample", > transactional = false, > properties = { > "connectors=in-vm",} > ) > } > ) > {code} > When using an MDB message isn't received. Removing "transactional" attribute makes it work again. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2303) [DMN Designer] Add column to whole row outline

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2303?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-2303: ----------------------------------- Sprint: 2018 Week 05-06 > [DMN Designer] Add column to whole row outline > ---------------------------------------------- > > Key: DROOLS-2303 > URL: https://issues.jboss.org/browse/DROOLS-2303 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Affects Versions: 7.6.0.Final > Reporter: Jozef Marko > Assignee: Michael Anstis > Priority: Minor > > Currently, if the user has outlined whole row of the decision table, and new column is added to this decision table, the new column is not added to the outline. > This could be enhanced not just for decision tables but in general, if there is outlined whole row of decision table, relation etc., then adding new column in the given editor should cause new column is included in the current outline. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2304) [DMN Designer] Add context entry from literal expression cell

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2304?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-2304: ----------------------------------- Sprint: 2018 Week 05-06 > [DMN Designer] Add context entry from literal expression cell > ------------------------------------------------------------- > > Key: DROOLS-2304 > URL: https://issues.jboss.org/browse/DROOLS-2304 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.6.0.Final > Reporter: Jozef Marko > Assignee: Michael Anstis > Priority: Minor > > If the context entry is specified as literal expression, then user can not add context entry while this literal expression cell is selected. It can be seen in the last row of context entry table, where last entry is pair *default : literal expression cell*. > If user clicks on *default*, the table offers show button *add entry* over the table, however if user clicks to *literal expression cell* next to *default* this button is not shown. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2302) [DMN Designer] Outline is not refreshed after new editor type selected

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2302?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-2302: ----------------------------------- Sprint: 2018 Week 05-06 > [DMN Designer] Outline is not refreshed after new editor type selected > ---------------------------------------------------------------------- > > Key: DROOLS-2302 > URL: https://issues.jboss.org/browse/DROOLS-2302 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.6.0.Final > Reporter: Jozef Marko > Assignee: Michael Anstis > Priority: Minor > > If the context entry table has at least two rows where: > # first row is selected (outline is shown) and the editor type is specified (decision table for example) > # second row has not the editor type specified (6 blue squares shown in that row) > Then if user clicks on some of these blue squares, the outline should be refreshed to overlap the last added cell / editor. -- 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: -------------------------------- Perhaps this can be solved by acking a {{RELEASE_LOCK}} request with a {{RELEASE_LOCK_OK}} response message from the coord to the releasing member. The releasing member would add the release request to a list and resend them on coordinator change. The {{ClientLock}} would only get released and removed from the lock table when the ack has been received. > 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.11 > > 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 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] (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 updated JGRP-2234: --------------------------- Description: 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 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. was: 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. > 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.11 > > 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 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] (WFLY-7040) Add a set of tests for HTTP authentication when backed by Elytron

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7040?page=com.atlassian.jira.plugin.... ] Jan Kalina updated WFLY-7040: ----------------------------- Priority: Blocker (was: Critical) > Add a set of tests for HTTP authentication when backed by Elytron > ----------------------------------------------------------------- > > Key: WFLY-7040 > URL: https://issues.jboss.org/browse/WFLY-7040 > Project: WildFly > Issue Type: Task > Components: Test Suite, Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Priority: Blocker > Labels: elytron_testing > 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-7040) Add a set of tests for HTTP authentication when backed by Elytron

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7040?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7040: ---------------------------------- Setting as blocker, as it blocks blocker WFLY-7042 > Add a set of tests for HTTP authentication when backed by Elytron > ----------------------------------------------------------------- > > Key: WFLY-7040 > URL: https://issues.jboss.org/browse/WFLY-7040 > Project: WildFly > Issue Type: Task > Components: Test Suite, Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Priority: Critical > Labels: elytron_testing > 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2018