March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-573) Kie Server: bugs and enhancements

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-573?page=com.atlassian.jira.plugin... ] Petr Široký resolved DROOLS-573. -------------------------------- Resolution: Done I marking this as resolved as all the issues were likely solved long time ago. > Kie Server: bugs and enhancements > --------------------------------- > > Key: DROOLS-573 > URL: https://issues.jboss.org/browse/DROOLS-573 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.Beta1 > Reporter: Petr Široký > Assignee: Edson Tirelli > > As discussed with Edson, I am creating list of possible bugs and enhancements for the KIE Server. > Bugs: > * Server returns NPE when the request body is empty (and is required). This happens for example when creating new container using /container/{id}, but not providing any data within the body (the XML/JSON specifying release-id, etc). > * The server returns 201 (Created) even when the container was not actually created. Easy reproducer: try to create container using non-existing kjar GAV. The response code will be 201 and the response will be failure with message "Failed to create container 1...." > Enhancements: > * I think it it would useful to move the KieServer interface into -api module so that user's can use e.g. RestEasy ClientProxy to create own REST client in case the don't want to use the provided client. > * When deplying the WAR into EAP 6.3.0 warning is dispalyed: JBAS016012: Deployment deployment "kie-server.war" contains CDI annotations but beans.xml was not found. The WAR file should contain beans.xml. > The description will be updated if I found more such bugs/enhancements. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1363) revapi-maven-plugin forks exutions

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1363?page=com.atlassian.jira.plugi... ] Petr Široký commented on DROOLS-1363: ------------------------------------- [~mmacik] I believe this has been fixed few weeks back with the upgrade of the plugin. Could you please confirm and possibly mark this as resolved? > revapi-maven-plugin forks exutions > ---------------------------------- > > Key: DROOLS-1363 > URL: https://issues.jboss.org/browse/DROOLS-1363 > Project: Drools > Issue Type: Bug > Components: build > Reporter: Petr Široký > Assignee: Marián Macik > > Revapi Maven plugin, as used in kie-api, forks the exeuctions causing almost the whole build to be executed three times. This needs to be fixed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1341) Account for additional DB2 FATAL connection errors

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1341?page=com.atlassian.jira.plugin... ] Ingo Weiss commented on JBJCA-1341: ----------------------------------- I agree with trimming the messages, that's fine. About the {{,}} char, I refactored to use {{.contains()}} instead of {{.equalsIgnoreCase()}}, that should take care of it. > Account for additional DB2 FATAL connection errors > -------------------------------------------------- > > Key: JBJCA-1341 > URL: https://issues.jboss.org/browse/JBJCA-1341 > Project: IronJacamar > Issue Type: Enhancement > Components: Validator > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Original Estimate: 2 days > Time Spent: 2 days > Remaining Estimate: 0 minutes > > Various version of pre 11.x DB2 drivers utilize the -99999 error code for a SQLException. Not all -99999 errors are fatal. For those variations that are known to be fatal, a check should be added to treat as such. > One example would be the -99999 error that indicates "Connection is closed" -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1483) Support default expiration for events

by Jochen Welle (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1483?page=com.atlassian.jira.plugi... ] Jochen Welle updated DROOLS-1483: --------------------------------- Description: We would like to be able to specify a "default" expiration offset for events. The default expiration offset should be used if the inferred expiration offset is infinite. Benefits would be: * Expiration is guaranteed: either after the specified offset or after the inferred offset. * Rule authors are not required to include a temporal constraint in all rules. * Event classes can be designed if the rules are not yet known. The current behavior of @Expires (fixed expiration offset) could be the default and an optional attribute could be added to enable the new behavior. {code:java} @Role(Type.EVENT) @Expires(value = "10m") // fixed expiration offset or @Expires(value = "10m", type="fixed") // fixed expiration offset public class MyEvent { ... {code} New behavior: {code:java} @Role(Type.EVENT) @Expires(value = "10m", type="default") // new feature public class MyEvent { ... {code} The goal is to have automatic event lifetime/memory management at all times. At the moment either a fixed expiration offset has to be set, which is only possible after analysing all rules and determining the expiration offset manually. Or every rule must include some temporal constraint, which is sometimes a tough burden on the rule author. This feature is related to: * [link DROOLS-1227|https://issues.jboss.org/browse/DROOLS-1227] I think the new behavior would touch the same code as the fix implemented there by [~mfusco] * [link DROOLS-586|https://issues.jboss.org/browse/DROOLS-586] was: We would like to be able to specify a "default" expiration offset for events. The default expiration offset should be used if the inferred expiration offset is infinite. Benefits would be: * Expiration is guaranteed: either after the specified offset or after the inferred offset. * Rule authors are not required to include a temporal constraint in all rules. * Event classes can be designed if the rules are not yet known. The current behavior of @Expires (fixed expiration offset) could be the default and an optional attribute could be added to enable the new behavior. {code:java} @Role(Type.EVENT) @Expires(value = "10m") // fixed expiration offset or @Expires(value = "10m", type="fixed") // fixed expiration offset public class MyEvent { ... {code} New behavior: {code:java} @Role(Type.EVENT) @Expires(value = "10m", type="default") // new feature public class MyEvent { ... {code} The goal is to have automatic event lifetime/memory management at all times. At the moment either a fixed expiration offset has to be set, which is only possible after analysing all rules and determining the expiration offset manually. Or every rule must include some temporal constraint, which is sometimes a tough burden on the rule author. This feature is related to: * [link DROOLS-1227|https://issues.jboss.org/browse/DROOLS-1227] * [link DROOLS-586|https://issues.jboss.org/browse/DROOLS-586] > Support default expiration for events > ------------------------------------- > > Key: DROOLS-1483 > URL: https://issues.jboss.org/browse/DROOLS-1483 > Project: Drools > Issue Type: Feature Request > Environment: Drools >= 6.5 in STREAM mode > Reporter: Jochen Welle > Assignee: Edson Tirelli > > We would like to be able to specify a "default" expiration offset for events. The default expiration offset should be used if the inferred expiration offset is infinite. > Benefits would be: > * Expiration is guaranteed: either after the specified offset or after the inferred offset. > * Rule authors are not required to include a temporal constraint in all rules. > * Event classes can be designed if the rules are not yet known. > The current behavior of @Expires (fixed expiration offset) could be the default and an optional attribute could be added to enable the new behavior. > {code:java} > @Role(Type.EVENT) > @Expires(value = "10m") // fixed expiration offset or > @Expires(value = "10m", type="fixed") // fixed expiration offset > public class MyEvent { > ... > {code} > New behavior: > {code:java} > @Role(Type.EVENT) > @Expires(value = "10m", type="default") // new feature > public class MyEvent { > ... > {code} > The goal is to have automatic event lifetime/memory management at all times. At the moment either a fixed expiration offset has to be set, which is only possible after analysing all rules and determining the expiration offset manually. Or every rule must include some temporal constraint, which is sometimes a tough burden on the rule author. > This feature is related to: > * [link DROOLS-1227|https://issues.jboss.org/browse/DROOLS-1227] I think the new behavior would touch the same code as the fix implemented there by [~mfusco] > * [link DROOLS-586|https://issues.jboss.org/browse/DROOLS-586] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1483) Support default expiration for events

by Jochen Welle (JIRA)

Jochen Welle created DROOLS-1483: ------------------------------------ Summary: Support default expiration for events Key: DROOLS-1483 URL: https://issues.jboss.org/browse/DROOLS-1483 Project: Drools Issue Type: Feature Request Environment: Drools >= 6.5 in STREAM mode Reporter: Jochen Welle Assignee: Edson Tirelli We would like to be able to specify a "default" expiration offset for events. The default expiration offset should be used if the inferred expiration offset is infinite. Benefits would be: * Expiration is guaranteed: either after the specified offset or after the inferred offset. * Rule authors are not required to include a temporal constraint in all rules. * Event classes can be designed if the rules are not yet known. The current behavior of @Expires (fixed expiration offset) could be the default and an optional attribute could be added to enable the new behavior. {code:java} @Role(Type.EVENT) @Expires(value = "10m") // fixed expiration offset or @Expires(value = "10m", type="fixed") // fixed expiration offset public class MyEvent { ... {code} New behavior: {code:java} @Role(Type.EVENT) @Expires(value = "10m", type="default") // new feature public class MyEvent { ... {code} The goal is to have automatic event lifetime/memory management at all times. At the moment either a fixed expiration offset has to be set, which is only possible after analysing all rules and determining the expiration offset manually. Or every rule must include some temporal constraint, which is sometimes a tough burden on the rule author. This feature is related to: * [link DROOLS-1227|https://issues.jboss.org/browse/DROOLS-1227] * [link DROOLS-586|https://issues.jboss.org/browse/DROOLS-586] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2554) batch --file=... could ignore empty lines in file

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2554?page=com.atlassian.jira.plugi... ] Jean-Francois Denise moved JBEAP-9659 to WFCORE-2554: ----------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2554 (was: JBEAP-9659) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: CLI (was: CLI) Affects Version/s: (was: 7.1.0.DR14) > batch --file=... could ignore empty lines in file > ------------------------------------------------- > > Key: WFCORE-2554 > URL: https://issues.jboss.org/browse/WFCORE-2554 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > batch command could ignore empty lines in file > {code} > domain@localhost:9990 /] batch --file=/tmp/ely.cli > Failed to create batch from /tmp/ely.cli: The line is null or empty. > {code} > cli file contains: > {code} > command > <empty_line> > command > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8399) Upgrade jboss-negotiation to 3.0.4

by Tomas Hofman (JIRA)

Tomas Hofman created WFLY-8399: ---------------------------------- Summary: Upgrade jboss-negotiation to 3.0.4 Key: WFLY-8399 URL: https://issues.jboss.org/browse/WFLY-8399 Project: WildFly Issue Type: Component Upgrade Components: Security Reporter: Tomas Hofman Assignee: Darran Lofthouse -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8399) Upgrade jboss-negotiation to 3.0.5

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFLY-8399?page=com.atlassian.jira.plugin.... ] Tomas Hofman updated WFLY-8399: ------------------------------- Summary: Upgrade jboss-negotiation to 3.0.5 (was: Upgrade jboss-negotiation to 3.0.4) > Upgrade jboss-negotiation to 3.0.5 > ---------------------------------- > > Key: WFLY-8399 > URL: https://issues.jboss.org/browse/WFLY-8399 > Project: WildFly > Issue Type: Component Upgrade > Components: Security > Reporter: Tomas Hofman > Assignee: Darran Lofthouse > Labels: legacy > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8400) Upgrade jboss-negotiation to 3.0.5

by Tomas Hofman (JIRA)

Tomas Hofman created WFLY-8400: ---------------------------------- Summary: Upgrade jboss-negotiation to 3.0.5 Key: WFLY-8400 URL: https://issues.jboss.org/browse/WFLY-8400 Project: WildFly Issue Type: Component Upgrade Components: Security Reporter: Tomas Hofman Assignee: Darran Lofthouse -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8398) (7.1.0) AdvancedLdapLoginModule - skip roles search when rolesCtxDN is null

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFLY-8398?page=com.atlassian.jira.plugin.... ] Tomas Hofman moved JBEAP-9656 to WFLY-8398: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8398 (was: JBEAP-9656) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) > (7.1.0) AdvancedLdapLoginModule - skip roles search when rolesCtxDN is null > --------------------------------------------------------------------------- > > Key: WFLY-8398 > URL: https://issues.jboss.org/browse/WFLY-8398 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Tomas Hofman > Assignee: Tomas Hofman > Labels: legacy > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

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 March 2017