January 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4529) BPMN processes don't work when CanonicalKieModule is used

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-4529?page=com.atlassian.jira.plug... ] Mario Fusco commented on DROOLS-4529: ------------------------------------- Fixed by https://github.com/kiegroup/drools/commit/f88212552867d1107b66245eefe4463... > BPMN processes don't work when CanonicalKieModule is used > --------------------------------------------------------- > > Key: DROOLS-4529 > URL: https://issues.redhat.com/browse/DROOLS-4529 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.26.0.Final > Reporter: Tibor Zimanyi > Assignee: Tibor Zimanyi > Priority: Major > Fix For: 7.28.0.Final > > > When using executable model in a kjar that contains BPMN process definitions in the form of bpmn files, the processes don't work. > To reproduce the problem, run RuleFlowIntegrationTest [1], with executable model enabled in the ruleflow-group kjar. > [1] https://github.com/kiegroup/droolsjbpm-integration/blob/78cb770577679cb46... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4931) [DMN Designer] Add Indexer of DMN files

by Michael Anstis (Jira)

Michael Anstis created DROOLS-4931: -------------------------------------- Summary: [DMN Designer] Add Indexer of DMN files Key: DROOLS-4931 URL: https://issues.redhat.com/browse/DROOLS-4931 Project: Drools Issue Type: Enhancement Components: DMN Editor Affects Versions: 7.31.0.Final Reporter: Michael Anstis Assignee: Michael Anstis There is a growing need to _index_ DMN files with an {{Indexer}} implementation. The exact meta-data to be stored in the index is to be ascertained. Implementation should be in {{kie-wb-common-dmn-backend}}. This is a Business Central only requirement -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly

by Carl Walker (Jira)

[ https://issues.redhat.com/browse/WFCORE-482?page=com.atlassian.jira.plugi... ] Carl Walker commented on WFCORE-482: ------------------------------------ Will https://nvd.nist.gov/vuln/detail/CVE-2019-17571 which has to do with the ServerSocket class in Log4J (1) be addressed by this ticket? > Add log4j2 support for WildFly > ------------------------------ > > Key: WFCORE-482 > URL: https://issues.redhat.com/browse/WFCORE-482 > Project: WildFly Core > Issue Type: Task > Components: Logging > Environment: Spring 3, Hibernate, Wicket, JBoss AS7 > Reporter: Amarkanth Ranganamayna > Assignee: James Perkins > Priority: Major > > I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2. > Looks like Jboss AS7 by default use log4j 1.x > Are you guys already working on using log4j2 ? > If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging. > Thanks, > Amar -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12959) Upgrade microprofile-fault-tolerance-api to 2.0.3

by Radoslav Husar (Jira)

Radoslav Husar created WFLY-12959: ------------------------------------- Summary: Upgrade microprofile-fault-tolerance-api to 2.0.3 Key: WFLY-12959 URL: https://issues.redhat.com/browse/WFLY-12959 Project: WildFly Issue Type: Component Upgrade Components: MP Fault Tolerance Affects Versions: No Release Reporter: Radoslav Husar Assignee: Radoslav Husar Fix For: 19.0.0.Beta1 TCK fixes only. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-298) Full reload is needed after microprofile-jwt-smallrye subsystem removal

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFWIP-298?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFWIP-298: ---------------------------------------- TBH this is just the nature of a subsystem that has registered deployment unit processors, as the subsystem is added and removed a reload is required to ensure the correct set of deployment unit processors are registered and used for the deployments. This is consistent with other subsystems that process deployments. I know the adding and removing of subsystems is tested regularly but I don't believe this is a prominent feature that end users will be making a lot of use of - if a user is experimenting with adding and removing subsystems I expect they can cope with the reload but I would not be expecting them to make this kind of change on a production installation. > Full reload is needed after microprofile-jwt-smallrye subsystem removal > ----------------------------------------------------------------------- > > Key: WFWIP-298 > URL: https://issues.redhat.com/browse/WFWIP-298 > Project: WildFly WIP > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Major > > When user is removing MP subsystem, full reload is required. This is partly a benefit because it provides a fast fail solution for deployments which requires classes from this subsystem. On the other hand, reload might not be feasible for user under in their current conditions. This is why it has to be reduced as much as possible. > Is there other way to provide fast fail without requiring full reload? -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2433) Smaller changes in Message/BaseMessage

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2433?page=com.atlassian.jira.plugin... ] Bela Ban edited comment on JGRP-2433 at 1/13/20 10:28 AM: ---------------------------------------------------------- * Implemented {{copy()}} in {{BaseMessage}} and also introduced a method {{copyPayload()}} that's overwritten by subclasses * I guess perf tests should be run once Infinispan has switched to JGroups 5.0 in a temp branch. Preliminary perf numbers for JGroups itself were added to JGRP-2218 some time ago. * I prefer to continue using a short for {{flags}} and a byte for {{transient_flags}}, and not collapse them into one short, as this would leave me with only 3 additional flags. Once I remove flags (e.g. RSVP...), and possibly also remove the {{dest}} field from {{Message}}, I might reconsider this suggestion... * I added {{msg_factory_class}} which requires the fully qualified name of a {{MsgFactory}} impl class; this cannot be set at runtime (as you mentioned, we'd not propagate that to other protocols, which fetch a ref at {{init()}} time). * Changed ID for message type from byte -> short was (Author: belaban): * Implemented {{copy()}} in {{BaseMessage}} and also introduced a method {{copyPayload()}} that's overwritten by subclasses * I guess perf tests should be run once Infinispan has switched to JGroups 5.0 in a temp branch. Preliminary perf numbers for JGroups itself were added to JGRP-2218 some time ago. * I prefer to continue using a short for {{flags}} and a byte for {{transient_flags}}, and not collapse them into one short, as this would leave me with only 3 additional flags. Once I remove flags (e.g. RSVP...), and possibly also remove the {{dest}} field from {{Message}}, I might reconsider this suggestion... * I added {{msg_factory_class}} which requires the fully qualified name of a {{MsgFactory}} impl class; this cannot be set at runtime (as you mentioned, we'd not propagate that to other protocols, which fetch a ref at {{init()}} time). > Smaller changes in Message/BaseMessage > -------------------------------------- > > Key: JGRP-2433 > URL: https://issues.redhat.com/browse/JGRP-2433 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 5.0 > > > Based on Pedro's suggestions (copied from \[1\]): > *Comments/Suggestions* > I've created a new custom {{Message}} class to replace an ISPN command. It can be found here: https://github.com/pruivo/infinispan/blob/t_jgroups_5/core/src/main/java/... > * The set/get...Array/Object must have a default implementation in the interface. I doubt that any custom implementation will ever implement those methods. Similar idea for {{hasArray()}} > * Probably the {{size()}} shouldn't be implemented in the base class. Initially, I forgot to implement it :). A {{headersSize()}} method would be needed. > > * It would be nice to have an abstract method write/read payload instead of overriding the writeTo/readFrom > * {{copy()}} should be implemented in the base class and be final. Just add an abstract method {{copyPayload()}} that is invoked when the payload needs to be copied. The first parameter for {{copy()}} should have a better name, IMO. > * {{MessageFactory}} is kind of difficult to find. Can we have a method in the {{Channel}}? or {{getMessageFactory()}} or {{registerMessage(type, constructor)}}. Also, I found some protocol creating a new {{MessageFactory}}, they should use the same instance, right? And you allow to set a different {{MessageFactory}} that isn't propagated everywhere... is there a use case where an user needs to replace the {{MessageFactory}}? If not, just make it static somewhere :) > * I'm wondering if there is way to avoid conflict to register a new message type. Imagine that wildfly and ispn creates a set new messages type, the conflict will only be detected at runtime. Also, the type is a byte... there is no much room to add custom messages types. > * Can the {{Flag}} and {{TransientFlag}} use the same short? There are only 2 transient flags so far and they can be the last bits of short. You can use a mask to skip sending them through the network > * no perf-ack numbers :( > \[1\] https://issues.redhat.com/browse/JGRP-2218 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2433) Smaller changes in Message/BaseMessage

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2433?page=com.atlassian.jira.plugin... ] Bela Ban edited comment on JGRP-2433 at 1/13/20 10:04 AM: ---------------------------------------------------------- * Implemented {{copy()}} in {{BaseMessage}} and also introduced a method {{copyPayload()}} that's overwritten by subclasses * I guess perf tests should be run once Infinispan has switched to JGroups 5.0 in a temp branch. Preliminary perf numbers for JGroups itself were added to JGRP-2218 some time ago. * I prefer to continue using a short for {{flags}} and a byte for {{transient_flags}}, and not collapse them into one short, as this would leave me with only 3 additional flags. Once I remove flags (e.g. RSVP...), and possibly also remove the {{dest}} field from {{Message}}, I might reconsider this suggestion... * I added {{msg_factory_class}} which requires the fully qualified name of a {{MsgFactory}} impl class; this cannot be set at runtime (as you mentioned, we'd not propagate that to other protocols, which fetch a ref at {{init()}} time). was (Author: belaban): * Implemented {{copy()}} in {{BaseMessage}} and also introduced a method {{copyPayload()}} that's overwritten by subclasses * I guess perf tests should be run once Infinispan has switched to JGroups 5.0 in a temp branch. Preliminary perf numbers for JGroups itself were added to JGRP-2218 some time ago. * I prefer to continue using a short for {{flags}} and a byte for {{transient_flags}}, and not collapse them into one short, as this would leave me with only 3 additional flags. Once I remove flags (e.g. RSVP...), and possibly also remove the {{dest}} field from {{Message}}, I might reconsider this suggestion... > Smaller changes in Message/BaseMessage > -------------------------------------- > > Key: JGRP-2433 > URL: https://issues.redhat.com/browse/JGRP-2433 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 5.0 > > > Based on Pedro's suggestions (copied from \[1\]): > *Comments/Suggestions* > I've created a new custom {{Message}} class to replace an ISPN command. It can be found here: https://github.com/pruivo/infinispan/blob/t_jgroups_5/core/src/main/java/... > * The set/get...Array/Object must have a default implementation in the interface. I doubt that any custom implementation will ever implement those methods. Similar idea for {{hasArray()}} > * Probably the {{size()}} shouldn't be implemented in the base class. Initially, I forgot to implement it :). A {{headersSize()}} method would be needed. > > * It would be nice to have an abstract method write/read payload instead of overriding the writeTo/readFrom > * {{copy()}} should be implemented in the base class and be final. Just add an abstract method {{copyPayload()}} that is invoked when the payload needs to be copied. The first parameter for {{copy()}} should have a better name, IMO. > * {{MessageFactory}} is kind of difficult to find. Can we have a method in the {{Channel}}? or {{getMessageFactory()}} or {{registerMessage(type, constructor)}}. Also, I found some protocol creating a new {{MessageFactory}}, they should use the same instance, right? And you allow to set a different {{MessageFactory}} that isn't propagated everywhere... is there a use case where an user needs to replace the {{MessageFactory}}? If not, just make it static somewhere :) > * I'm wondering if there is way to avoid conflict to register a new message type. Imagine that wildfly and ispn creates a set new messages type, the conflict will only be detected at runtime. Also, the type is a byte... there is no much room to add custom messages types. > * Can the {{Flag}} and {{TransientFlag}} use the same short? There are only 2 transient flags so far and they can be the last bits of short. You can use a mask to skip sending them through the network > * no perf-ack numbers :( > \[1\] https://issues.redhat.com/browse/JGRP-2218 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4930) [DMN Designer] Remove UUID from Alerts panel validation messages

by Michael Anstis (Jira)

Michael Anstis created DROOLS-4930: -------------------------------------- Summary: [DMN Designer] Remove UUID from Alerts panel validation messages Key: DROOLS-4930 URL: https://issues.redhat.com/browse/DROOLS-4930 Project: Drools Issue Type: Enhancement Components: DMN Editor Affects Versions: 7.31.0.Final Reporter: Michael Anstis Assignee: Michael Anstis Validation of a DMN diagram can lead to messages being shown in the Alerts Panel. Stunner is appending the UUID to the message. See [CoreTranslationMessages.getElementValidationMessage()|https://github.com/...] [~tirelli] has requested their removal. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4929) DMN DT Analysis to report all Kie Messages

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-4929?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-4929: ----------------------------------- Description: Either using the single model Validation API or the Fluent API for multiple models (yet validating only a single model) should result in the same KIE Message being reported. This is linked to Workbench behavior which relies on Kie Message level and not typed-message for DT Analysis > DMN DT Analysis to report all Kie Messages > ------------------------------------------ > > Key: DROOLS-4929 > URL: https://issues.redhat.com/browse/DROOLS-4929 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > > Either using the single model Validation API or the Fluent API for multiple models (yet validating only a single model) should result in the same KIE Message being reported. This is linked to Workbench behavior which relies on Kie Message level and not typed-message for DT Analysis -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4929) DMN DT Analysis to report all Kie Messages

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-4929: -------------------------------------- Summary: DMN DT Analysis to report all Kie Messages Key: DROOLS-4929 URL: https://issues.redhat.com/browse/DROOLS-4929 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 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 2020