September 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11040) mod_cluster integration test with custom load metric class

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-11040?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-11040: ---------------------------------- Description: Would be nice to prevent issues like WFLY-11033. QE have a test in their own testsuite... (was: Would be nice to prevent issues like WFLY-11033.) > mod_cluster integration test with custom load metric class > ---------------------------------------------------------- > > Key: WFLY-11040 > URL: https://issues.jboss.org/browse/WFLY-11040 > Project: WildFly > Issue Type: Task > Components: mod_cluster, Test Suite > Affects Versions: 14.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: Awaiting Volunteers > > > Would be nice to prevent issues like WFLY-11033. QE have a test in their own testsuite... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11033) "'module' isn't an allowed attribute for the 'custom-load-metric'" - it should be

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-11033?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-11033: ---------------------------------- Fix Version/s: 15.0.0.Alpha1 > "'module' isn't an allowed attribute for the 'custom-load-metric'" - it should be > --------------------------------------------------------------------------------- > > Key: WFLY-11033 > URL: https://issues.jboss.org/browse/WFLY-11033 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 14.0.0.Final > Reporter: Jan Kašík > Assignee: Radoslav Husar > Priority: Critical > Fix For: 15.0.0.Alpha1 > > > This message shows up if I try to define module attribute for 'custom-load-metric'. It doesn't make sense, since it says both, that 'module' attribute is and isn't allowed. This also means, that the module attribute is not usable. > {code} > OPVDX001: Validation error in standalone-ha.xml -------------------------------- > | > | 448: <proxy name="default" advertise-socket="modcluster" auto-enable-contexts="true" listener="ajp"> > | 449: <dynamic-load-provider> > | 450: <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" module="org.jboss.mod_cluster" weight="1" capacity="1000.0"> > | ^^^^ 'module' isn't an allowed attribute for the 'custom-load-metric' > | element > | > | Attributes allowed here are: capacity, class, module, weight > | > | 451: <property name="parseexpression" value="^LOAD: ([0-9]*)$"/> > | 452: <property name="loadfile" value="/home/virtual/mod_cluster_workspace/loadfileA"/> > | 453: </custom-load-metric> > | > | 'module' is allowed on elements: > | - server > profile > {urn:jboss:domain:naming:2.0}subsystem > bindings > object-factory > | - server > profile > {urn:jboss:domain:naming:2.0}subsystem > bindings > external-context > | - server > profile > {urn:jboss:domain:security-manager:1.0}subsystem > deployment-permissions > minimum-set > permission > | - server > profile > {urn:jboss:domain:security-manager:1.0}subsystem > deployment-permissions > maximum-set > permission > | - server > profile > {urn:jboss:domain:datasources:5.0}subsystem > datasources > drivers > driver > | - server > profile > {urn:wildfly:microprofile-config-smallrye:1.0}subsystem > config-source > class > | - server > profile > {urn:wildfly:microprofile-config-smallrye:1.0}subsystem > config-source-provider > class > | - server > extensions > extension > | - server > vault > | - server > management > security-realms > security-realm > plug-ins > plug-in > | - server > profile > {urn:jboss:domain:infinispan:7.0}subsystem > cache-container > | - server > profile > {urn:jboss:domain:infinispan:7.0}subsystem > cache-container > local-cache > | - server > profile > {urn:jboss:domain:infinispan:7.0}subsystem > remote-cache-container > | - server > profile > {urn:jboss:domain:modcluster:4.0}subsystem > proxy > dynamic-load-provider > custom-load-metric > | - server > profile > {urn:jboss:domain:security:2.0}subsystem > security-domains > security-domain > authentication > login-module > | - server > profile > {urn:jboss:domain:security:2.0}subsystem > security-domains > security-domain > authentication-jaspi > login-module-stack > login-module > | - server > profile > {urn:jboss:domain:security:2.0}subsystem > security-domains > security-domain > authentication-jaspi > auth-module > | - server > profile > {urn:jboss:domain:security:2.0}subsystem > security-domains > security-domain > authorization > policy-module > | - server > profile > {urn:jboss:domain:security:2.0}subsystem > security-domains > security-domain > acl > acl-module > | - server > profile > {urn:jboss:domain:security:2.0}subsystem > security-domains > security-domain > mapping > mapping-module > | (and 26 more) > | > | The primary underlying error message was: > | > ParseError at [row,col]:[450,21] > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2921) [DMN Designer] Stack overflow when a Context has two Relations

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2921?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-2921: -------------------------------- Description: Create a {{Context}} with two {{ContextEntries}}. Set both to be a {{Relation}}. Stack overflow :-( You can have multiple {{Relation}} in different {{Contexts}} it only happens when within the same {{Context}}. h2. Manual acceptance test - Top level context, multiple entries of different kinds - Nested level context, multiple entries of different kinds was: Create a {{Context}} with two {{ContextEntries}}. Set both to be a {{Relation}}. Stack overflow :-( You can have multiple {{Relation}} in different {{Contexts}} it only happens when within the same {{Context}}. > [DMN Designer] Stack overflow when a Context has two Relations > -------------------------------------------------------------- > > Key: DROOLS-2921 > URL: https://issues.jboss.org/browse/DROOLS-2921 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.10.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Critical > Labels: drools-tools > > Create a {{Context}} with two {{ContextEntries}}. Set both to be a {{Relation}}. Stack overflow :-( > You can have multiple {{Relation}} in different {{Contexts}} it only happens when within the same {{Context}}. > h2. Manual acceptance test > - Top level context, multiple entries of different kinds > - Nested level context, multiple entries of different kinds -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2429) [DMN Editor] Decision Navigator dock (Mini Map)

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2429?page=com.atlassian.jira.plugi... ] Michael Anstis commented on DROOLS-2429: ---------------------------------------- [~uxdlc] [~bdellasc] Can we close this JIRA in preference of https://issues.jboss.org/browse/JBPM-6697 > [DMN Editor] Decision Navigator dock (Mini Map) > ----------------------------------------------- > > Key: DROOLS-2429 > URL: https://issues.jboss.org/browse/DROOLS-2429 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Carreiro > Assignee: Guilherme Carreiro > Attachments: prototype.png > > > Add a preview of the selected diagram to the Decision Navigator doc. > !prototype.png|thumbnail! > See more details [here|https://docs.google.com/document/d/14pnw6QUTj5BsUJyz4uP_ozLLkYBvCYGX...]. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2922) CSS: Pop-over menu for DMN decision tables.

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2922?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-2922: ----------------------------------- Sprint: (was: 2018 Week 39-41) > CSS: Pop-over menu for DMN decision tables. > ------------------------------------------- > > Key: DROOLS-2922 > URL: https://issues.jboss.org/browse/DROOLS-2922 > Project: Drools > Issue Type: Story > Components: DMN Editor > Reporter: Liz Clayton > Assignee: Michael Anstis > Labels: UX, UXTeam, drools-tools > Attachments: DataType selection ('Properties Panel' and 'in-grid').png, Screen Shot 2018-08-10 at 10.23.36 AM.png, pop-overc.png, pop-overcSpecs.png, select.png > > > *Background* > Persona: Business analyst or Rules practitioner > Use Cases from the DMN canvas view, as a user I want to: > * Search a list of available data types from a decision table, as part of an input/selection process. > * Select a data type inline from a decision table. > * Have a means to rename the Decision (node.) > * Have a means to access the Manage Data Types dialog. > Notes: > Design requires a Pop-over, which includes: > * Form field labels for usability (context) and accessibility. > * Variant 1 of the PF pop-over patterns, which supports a the pop-up title. > * Drop down component with Live Search > * "Manage" link opens a dialog. > * Pop-up is initiated by a single-left mouse click within the respective decision table cell. > * Design needs to be reasonably consistent with Stunner and PF components. > Verification conditions: > * Scrum team and PO review. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11039) Upgrade WildFly Core 7.0.0.Alpha1

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-11039: ---------------------------------- Summary: Upgrade WildFly Core 7.0.0.Alpha1 Key: WFLY-11039 URL: https://issues.jboss.org/browse/WFLY-11039 Project: WildFly Issue Type: Component Upgrade Components: Management Reporter: Jeff Mesnil Assignee: Jeff Mesnil -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2294) ForkProtocolStack ignores UnknownForkHandler for message batches

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/JGRP-2294?page=com.atlassian.jira.plugin.... ] Dan Berindei updated JGRP-2294: ------------------------------- Description: {{ForkProtocolStack.up(MessageBatch)}} discards messages if it doesn't the fork channel id isn't registered and they are part of a batch: {code:java} log.debug("fork-channel for id=%s not found; discarding message", fork_channel_id); {code} ~~I believe the check should also be enhanced to invoke the {{UnknownForkHandler}} if the {{ForkChannel}} is registered but is not yet connected. Otherwise messages that arrive after the {{ForkChannel}} registers itself in the constructor and before our {{JGroupsTransport}} registers itself as an {{UpHandler}} with the {{ForkChannel}} will also be discarded.~~ I misread the {{ForkChannel}} code, the registratioon in the {{ForkProtocolStack}} only happens in {{ForkChannel.connect()}}. was: {{ForkProtocolStack.up(MessageBatch)}} discards messages if it doesn't the fork channel id isn't registered and they are part of a batch: {code:java} log.debug("fork-channel for id=%s not found; discarding message", fork_channel_id); {code} I believe the check should also be enhanced to invoke the {{UnknownForkHandler}} if the {{ForkChannel}} is registered but is not yet connected. Otherwise messages that arrive after the {{ForkChannel}} registers itself in the constructor and before our {{JGroupsTransport}} registers itself as an {{UpHandler}} with the {{ForkChannel}} will also be discarded. > ForkProtocolStack ignores UnknownForkHandler for message batches > ---------------------------------------------------------------- > > Key: JGRP-2294 > URL: https://issues.jboss.org/browse/JGRP-2294 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.13 > Reporter: Dan Berindei > Assignee: Bela Ban > > {{ForkProtocolStack.up(MessageBatch)}} discards messages if it doesn't the fork channel id isn't registered and they are part of a batch: > {code:java} > log.debug("fork-channel for id=%s not found; discarding message", fork_channel_id); > {code} > ~~I believe the check should also be enhanced to invoke the {{UnknownForkHandler}} if the {{ForkChannel}} is registered but is not yet connected. Otherwise messages that arrive after the {{ForkChannel}} registers itself in the constructor and before our {{JGroupsTransport}} registers itself as an {{UpHandler}} with the {{ForkChannel}} will also be discarded.~~ > I misread the {{ForkChannel}} code, the registratioon in the {{ForkProtocolStack}} only happens in {{ForkChannel.connect()}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2294) ForkProtocolStack ignores UnknownForkHandler for message batches

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/JGRP-2294?page=com.atlassian.jira.plugin.... ] Dan Berindei updated JGRP-2294: ------------------------------- Description: {{ForkProtocolStack.up(MessageBatch)}} discards messages if it doesn't the fork channel id isn't registered and they are part of a batch: {code:java} log.debug("fork-channel for id=%s not found; discarding message", fork_channel_id); {code} -I believe the check should also be enhanced to invoke the {{UnknownForkHandler}} if the {{ForkChannel}} is registered but is not yet connected. Otherwise messages that arrive after the {{ForkChannel}} registers itself in the constructor and before our {{JGroupsTransport}} registers itself as an {{UpHandler}} with the {{ForkChannel}} will also be discarded.- I misread the {{ForkChannel}} code, the registratioon in the {{ForkProtocolStack}} only happens in {{ForkChannel.connect()}}. was: {{ForkProtocolStack.up(MessageBatch)}} discards messages if it doesn't the fork channel id isn't registered and they are part of a batch: {code:java} log.debug("fork-channel for id=%s not found; discarding message", fork_channel_id); {code} ~~I believe the check should also be enhanced to invoke the {{UnknownForkHandler}} if the {{ForkChannel}} is registered but is not yet connected. Otherwise messages that arrive after the {{ForkChannel}} registers itself in the constructor and before our {{JGroupsTransport}} registers itself as an {{UpHandler}} with the {{ForkChannel}} will also be discarded.~~ I misread the {{ForkChannel}} code, the registratioon in the {{ForkProtocolStack}} only happens in {{ForkChannel.connect()}}. > ForkProtocolStack ignores UnknownForkHandler for message batches > ---------------------------------------------------------------- > > Key: JGRP-2294 > URL: https://issues.jboss.org/browse/JGRP-2294 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.13 > Reporter: Dan Berindei > Assignee: Bela Ban > > {{ForkProtocolStack.up(MessageBatch)}} discards messages if it doesn't the fork channel id isn't registered and they are part of a batch: > {code:java} > log.debug("fork-channel for id=%s not found; discarding message", fork_channel_id); > {code} > -I believe the check should also be enhanced to invoke the {{UnknownForkHandler}} if the {{ForkChannel}} is registered but is not yet connected. Otherwise messages that arrive after the {{ForkChannel}} registers itself in the constructor and before our {{JGroupsTransport}} registers itself as an {{UpHandler}} with the {{ForkChannel}} will also be discarded.- > I misread the {{ForkChannel}} code, the registratioon in the {{ForkProtocolStack}} only happens in {{ForkChannel.connect()}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4116) JDK 10: illegal reflective access

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/WFCORE-4116?page=com.atlassian.jira.plugi... ] Rostislav Svoboda commented on WFCORE-4116: ------------------------------------------- This is not visible when you boot vanilla server without deployments. You will see this when you deploy an application of boot server with applications already deployed. > JDK 10: illegal reflective access > --------------------------------- > > Key: WFCORE-4116 > URL: https://issues.jboss.org/browse/WFCORE-4116 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 6.0.0.Final, 6.0.2.Final > Reporter: Thorsten Moeller > Assignee: Jason Greene > > Using WF14 and Oracle JDK 10.0.2, there is an illegal reflective access warning while WF boots: > {code} > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by org.jboss.as.server.deployment.reflect.ClassReflectionIndex (jar:file:/Users/.../wildfly-14.0.0.Final/modules/system/layers/base/org/jboss/as/server/main/wildfly-server-6.0.1.Final.jar!/) to method java.lang.Object.finalize() > WARNING: Please consider reporting this to the maintainers of org.jboss.as.server.deployment.reflect.ClassReflectionIndex > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4117) JDK 11: illegal reflective access

by Rostislav Svoboda (JIRA)

Rostislav Svoboda created WFCORE-4117: ----------------------------------------- Summary: JDK 11: illegal reflective access Key: WFCORE-4117 URL: https://issues.jboss.org/browse/WFCORE-4117 Project: WildFly Core Issue Type: Bug Components: Server Affects Versions: 6.0.0.Final, 6.0.2.Final Reporter: Rostislav Svoboda Assignee: Jason Greene Using WF14 and Oracle JDK 10.0.2, there is an illegal reflective access warning while WF boots: {code} WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.jboss.as.server.deployment.reflect.ClassReflectionIndex (jar:file:/Users/.../wildfly-14.0.0.Final/modules/system/layers/base/org/jboss/as/server/main/wildfly-server-6.0.1.Final.jar!/) to method java.lang.Object.finalize() WARNING: Please consider reporting this to the maintainers of org.jboss.as.server.deployment.reflect.ClassReflectionIndex {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 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 September 2018