[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
[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
[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
[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
[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