November 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3245) [DMN Designer] Updating "Name" from Properties Panel does not update '<< Back to XYZ' link or Decision Navigator

by Michael Anstis (Jira)

Michael Anstis created DROOLS-3245: -------------------------------------- Summary: [DMN Designer] Updating "Name" from Properties Panel does not update '<< Back to XYZ' link or Decision Navigator Key: DROOLS-3245 URL: https://issues.jboss.org/browse/DROOLS-3245 Project: Drools Issue Type: Bug Components: DMN Editor Affects Versions: 7.14.0.Final Reporter: Michael Anstis Assignee: Michael Anstis The "<< Back to XYZ" link text nor "Decision Navigator" node label update when the "Name" of a top-level {{DomainObject}} is changed via the "Properties Panel". This does not appear related to either [JBPM-7166|https://issues.jboss.org/browse/JBPM-7166] or [DROOLS-3231|https://issues.jboss.org/browse/DROOLS-3231] but rather I suspect _masked_ by the cause of JBPM-7166. I tested with the latter reverted locally and the issue reported here remained. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1708) Centralize xstream initialization

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-1708?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-1708. --------------------------------- Resolution: Done > Centralize xstream initialization > --------------------------------- > > Key: DROOLS-1708 > URL: https://issues.jboss.org/browse/DROOLS-1708 > Project: Drools > Issue Type: Enhancement > Reporter: Mario Fusco > Assignee: Michael Biarnes Kiefer > Priority: Major > > In drools I centralized the creation and initialization of the xstream instance with this commit https://github.com/kiegroup/drools/commit/e3e7c44515949d8fb25978cb2040c50... using the new factory method added here https://github.com/kiegroup/droolsjbpm-knowledge/commit/14438e9ad37ea5fa6... > Please extend this enhancement to all other projects using xstream. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3236) Unable to open KJAR project in eclipse due to "Missing parameter for pluginExecutionFilter"

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-3236?page=com.atlassian.jira.plugi... ] Mario Fusco reassigned DROOLS-3236: ----------------------------------- Assignee: Matteo Mortari (was: Mario Fusco) > Unable to open KJAR project in eclipse due to "Missing parameter for pluginExecutionFilter" > ------------------------------------------------------------------------------------------- > > Key: DROOLS-3236 > URL: https://issues.jboss.org/browse/DROOLS-3236 > Project: Drools > Issue Type: Bug > Components: tools > Affects Versions: 7.10.0.Final, 7.11.0.Final, 7.12.0.Final, 7.13.0.Final > Environment: Eclipse photon, Eclipse 2018 09, no special plugin > m2eclipse configured to do-not-manage/ignore any unknown plugin goal (easiest choice) > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > Attachments: image-2018-11-05-10-28-50-255.png > > > Since 7.10.0.Final the following error occurs when opening a KJAR project in Eclipse: > !image-2018-11-05-10-28-50-255.png! > Errors occurred during the build. > Errors running builder 'Maven Project Builder' on project '...'. > Missing parameter for pluginExecutionFilter. groupId, artifactId, versionRange and goals must be specificed, but found: groupId = 'org.kie' > artifactId = 'kie-maven-plugin' > versionRange = '7.10.0.Final' > goals = '[]' > Please notice kie-maven-plugin 7.9.0.Final and earlier do NOT exhibit this issue. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11265) wildfly-feature-pack -- Dependency Error

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11265?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-11265: ----------------------------------------- Hi Dennis, The current active repository for soteria appears to be https://github.com/eclipse-ee4j/soteria. Apparently as part of the move to Jakarta EE the project has moved from the previous https://github.com/javaee/security-soteria/blob/master/README.md. I'm not sure but it looks like they use GitHub issues as an issue tracker: https://github.com/eclipse-ee4j/soteria/issues Best regards, Brian > wildfly-feature-pack -- Dependency Error > ---------------------------------------- > > Key: WFLY-11265 > URL: https://issues.jboss.org/browse/WFLY-11265 > Project: WildFly > Issue Type: Bug > Affects Versions: 14.0.0.Final > Environment: Ubuntu 18.10 > JDK 11 > WildFly 14.0.1.Final > Reporter: Dennis Gesker > Assignee: Jason Greene > Priority: Major > Labels: wildfly-feature-pack > Fix For: 14.0.0.Final > > > In my gradle build I've added: > * providedCompile "org.wildfly:wildfly-feature-pack:14.0.1.Final"* > > But, I'm getting: > > *> Could not resolve javax.security.enterprise:javax.security.enterprise-api:1.1-b01-SNAPSHOT. > Required by: > project : > org.wildfly:wildfly-feature-pack:14.0.1.Final > org.glassfish.soteria:javax.security.enterprise:1.0* > > Could not resolve javax.security.enterprise:javax.security.enterprise-api:1.1-b01-SNAPSHOT. > > Unable to load Maven meta-data from https://repository.jboss.org/nexus/content/groups/public-jboss/javax/secu.... > > Could not get resource 'https://repository.jboss.org/nexus/content/groups/public-jboss/javax/secu...'. > > Could not GET 'https://repository.jboss.org/nexus/content/groups/public-jboss/javax/secu...'. > > extension (10) should not be presented in server_hello > > Presently I have the following repositories in my build: > > jcenter() > mavenCentral() > > maven { > name "Gradle Repository" > url "https://plugins.gradle.org/m2/" > } > maven { > name "JBoss Public Maven Repository Group" > url "https://repository.jboss.org/nexus/content/groups/public-jboss/" > } > maven { > name "JBoss Public Maven Repository Group" > url "http://repository.jboss.org/nexus/content/groups/public/" > } > > > But, I suspect I am missing a repository specific to WildFly. Or, maybe there is a bad entry in the POM? > > Thanks, > Dennis -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10731) core-threads of ManagedScheduledExecutorService limits number of maximal threads

by Jiri Ondrusek (Jira)

[ https://issues.jboss.org/browse/WFLY-10731?page=com.atlassian.jira.plugin... ] Jiri Ondrusek reassigned WFLY-10731: ------------------------------------ Assignee: Jiri Ondrusek > core-threads of ManagedScheduledExecutorService limits number of maximal threads > -------------------------------------------------------------------------------- > > Key: WFLY-10731 > URL: https://issues.jboss.org/browse/WFLY-10731 > Project: WildFly > Issue Type: Bug > Components: EE > Affects Versions: 12.0.0.Final > Reporter: gunter zeilinger > Assignee: Jiri Ondrusek > Priority: Major > > After changing the default configuration: > {noformat} > <managed-scheduled-executor-services> > - <managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" hung-task-threshold="60000" keepalive-time="3000"/> > + <managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" long-running-tasks="true" core-threads="2" keepalive-time="3000"/> > </managed-scheduled-executor-services> > {noformat} > only 2 (= value of core-threads) threads are used by the Scheduled Executer Service: > {code:bash} > $ grep ManagedScheduledExecutorService $WILDFLY/standalone/log/server.log | tail > 2018-07-24 12:03:22,901 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) .. > 2018-07-24 12:03:22,911 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) .. > 2018-07-24 12:03:22,923 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) .. > 2018-07-24 12:03:22,963 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) .. > 2018-07-24 12:03:22,967 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) .. > 2018-07-24 12:03:22,981 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) .. > 2018-07-24 12:03:22,996 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) .. > 2018-07-24 12:03:23,016 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) .. > 2018-07-24 12:03:23,035 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) .. > 2018-07-24 12:03:23,039 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) .. > {code} > I have not yet tested if the issue also effects Wildfly 13.0.0.Final ( cannot use Wildfly 13.0.0.Final because of WFLY-10531 ) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11262) violation of call-by-value if a outbound connection is configured

by Carlo de Wolf (Jira)

[ https://issues.jboss.org/browse/WFLY-11262?page=com.atlassian.jira.plugin... ] Carlo de Wolf updated WFLY-11262: --------------------------------- Priority: Blocker (was: Critical) > violation of call-by-value if a outbound connection is configured > ----------------------------------------------------------------- > > Key: WFLY-11262 > URL: https://issues.jboss.org/browse/WFLY-11262 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Wolf-Dieter Fink > Priority: Blocker > Labels: Regression, spec_violation > > If the server default configuration is used an EJB invocation via @Remote interface is, according to the specification, with call-by-value. > But if the application is configured with jboss-ejb-client.xml to have a remote-outbound-connection the EJB invocation via @Remote is done as call-by-reference no matter whether the configuration is default or > <in-vm-remote-interface-invocation pass-by-value="true"/> > is used. > This is a violation of the specification and can cause serious unexpected issues at runtime for the application if the parameters or return values are mutable -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2312) LazyThreadFactory can keep threads instances alive for a long period

by William Burns (Jira)

[ https://issues.jboss.org/browse/JGRP-2312?page=com.atlassian.jira.plugin.... ] William Burns commented on JGRP-2312: ------------------------------------- [~belaban] Works for me :) I am fine with either approach on here to be honest. To me Dan's approach to not allow change after complete initialization is cleaner, but I don't know if that is possible. > LazyThreadFactory can keep threads instances alive for a long period > -------------------------------------------------------------------- > > Key: JGRP-2312 > URL: https://issues.jboss.org/browse/JGRP-2312 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.15 > Reporter: William Burns > Assignee: Bela Ban > Priority: Major > Fix For: 4.0.16, 3.6.17 > > > The LazyThreadFactory keeps all Thread objects in a ConcurrentLinkedQueue wrapped by a WeakReference. This means that once a thread terminates, its instance along with all native memory required for it can linger until the GC eventually reclaims it. Normally this is not an issue when the JVM heap is being recycled often, but in cases where you have low heap requirement operations (ie. off heap data container) this can cause these objects to pile up and eventually exhaust native memory. > This queue is also a very slow JVM heap leak as threads are tossed out, since the WeakReference and Queue Node objects are never reclaimed unless the transport is stopped. > The best way to fix this would be to plug into when the thread is set to TERMINATED state and to remove these nodes. > Also a workaround is to increase the core thread count and increase the keepalive timeout so that threads are not destroyed and created nearly as often. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3231) [DMN Designer] Stack overflow when undo'ing Name change in top-level grid

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-3231?page=com.atlassian.jira.plugi... ] Michael Anstis resolved DROOLS-3231. ------------------------------------ Resolution: Done > [DMN Designer] Stack overflow when undo'ing Name change in top-level grid > -------------------------------------------------------------------------- > > Key: DROOLS-3231 > URL: https://issues.jboss.org/browse/DROOLS-3231 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.14.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Critical > Labels: drools-tools > Fix For: 7.14.0.Final > > > When undo'ing the change to the {{Name}} on a top-level grid a stack-overflow occurs. > h2. Manual Acceptance test > Undo renaming of > - Literal Expression (/) > - Decision table (/) > - Input Column (/) > - Output Column (/) > - Context (/) > - Context entry (/) > - Function (/) > - Function Parameter (/) > - Relation (/) > - Relation Column (/) > - Invocation (/) > - Invocation Parameter (/) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3231) [DMN Designer] Stack overflow when undo'ing Name change in top-level grid

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-3231?page=com.atlassian.jira.plugi... ] Michael Anstis reopened DROOLS-3231: ------------------------------------ > [DMN Designer] Stack overflow when undo'ing Name change in top-level grid > -------------------------------------------------------------------------- > > Key: DROOLS-3231 > URL: https://issues.jboss.org/browse/DROOLS-3231 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.14.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Critical > Labels: drools-tools > Fix For: 7.14.0.Final > > > When undo'ing the change to the {{Name}} on a top-level grid a stack-overflow occurs. > h2. Manual Acceptance test > Undo renaming of > - Literal Expression (/) > - Decision table (/) > - Input Column (/) > - Output Column (/) > - Context (/) > - Context entry (/) > - Function (/) > - Function Parameter (/) > - Relation (/) > - Relation Column (/) > - Invocation (/) > - Invocation Parameter (/) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3030) [DMN Designer] Expand / Collapse all

by Guilherme Carreiro (Jira)

[ https://issues.jboss.org/browse/DROOLS-3030?page=com.atlassian.jira.plugi... ] Guilherme Carreiro updated DROOLS-3030: --------------------------------------- Sprint: 2018 Week 45-47 > [DMN Designer] Expand / Collapse all > ------------------------------------ > > Key: DROOLS-3030 > URL: https://issues.jboss.org/browse/DROOLS-3030 > Project: Drools > Issue Type: Task > Components: DMN Editor > Affects Versions: 7.12.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Carreiro > Priority: Major > Labels: UX, drools-tools > > User should have possibility to easily expand / collapse all data types in the *manage custom data type* dialog. > h2. Manual acceptance test > - Expand > -- All collapsed initially > -- Something collapsed initially, something expanded already > -- All expanded already > - Collapse > -- All expanded initially > -- Something expanded initially, something collapsed already > -- All collapsed already > - No error warning in browser console log -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 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 November 2018