[JBoss JIRA] (DROOLS-1537) Scheduled activations are rescheduled as if new when unmarshalling session in Drools 6.5
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1537?page=com.atlassian.jira.plugi... ]
Edson Tirelli reassigned DROOLS-1537:
-------------------------------------
Assignee: Mario Fusco (was: Edson Tirelli)
> Scheduled activations are rescheduled as if new when unmarshalling session in Drools 6.5
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-1537
> URL: https://issues.jboss.org/browse/DROOLS-1537
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.5.0.Final
> Reporter: Kay J
> Assignee: Mario Fusco
> Attachments: RestoreReproducer.java
>
>
> Ticket representing question/bug from drools user group: https://groups.google.com/forum/#!topic/drools-usage/Gy3uhkh6J78
> Hello Drools users,
> I found an anomaly in Drools 6.5. I insert an Event, which triggers a rule with a timer after some time. For backup reasons I marshal the session inbetween to back it up and on unmarshal it later. However, after unmarshalling it, the scheduled activations are sometimes scheduled as if just inserted (e.g. 1min scheduling, with marshal/unmarshal after 25s results in the activation firing after 85 (25+60) seconds instead of actual 60s. I know this worked with Drools 5.6 consistently, but now it sometimes works, sometimes not, which is indeterministic.
> I created a test reproducing this behaviour, which has changing output whenever you execute it. What the example does: It create a scheduled activation, which should trigger after 20s. After 10s the session is marshalled, destroyed and unmarshalled into a new session. After another 10s it should finally trigger. (10s + 10s -> the 20s scheduled).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8638) read-resource on workmanager returns wrong value for elytron-enabled attribute
by Martin Simka (JIRA)
[ https://issues.jboss.org/browse/WFLY-8638?page=com.atlassian.jira.plugin.... ]
Martin Simka moved JBEAP-10526 to WFLY-8638:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8638 (was: JBEAP-10526)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JCA
(was: JCA)
Affects Version/s: (was: 7.1.0.DR16)
> read-resource on workmanager returns wrong value for elytron-enabled attribute
> ------------------------------------------------------------------------------
>
> Key: WFLY-8638
> URL: https://issues.jboss.org/browse/WFLY-8638
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: Martin Simka
> Assignee: Martin Simka
>
> *"elytron-enabled" => "myWM"*
> {noformat}
> [standalone@localhost:9990 /] /subsystem=jca/workmanager=myWM:add(name=myWM, elytron-enabled=true
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=jca/workmanager=myWM:read-resource
> {
> "outcome" => "success",
> "result" => {
> "elytron-enabled" => "myWM",
> "name" => "myWM",
> "long-running-threads" => undefined,
> "short-running-threads" => undefined
> }
> }
> [standalone@localhost:9990 /] /subsystem=jca/workmanager=myWM:read-attribute(name=elytron-enabled)
> {
> "outcome" => "success",
> "result" => "myWM"
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2671) CLI Opertation 'load' for Elytron key-store does not correctly re-read keystore
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2671?page=com.atlassian.jira.plugi... ]
Jan Kalina commented on WFCORE-2671:
------------------------------------
Resolved by adding refresh operations into key-managers and ssl-context:
{code}
/subsystem=elytron/key-store=httpsKS:load()
/subsystem=elytron/key-managers=httpsKM:init()
/subsystem=elytron/server-ssl-context=httpsSSC:key-refresh()
{code}
> CLI Opertation 'load' for Elytron key-store does not correctly re-read keystore
> -------------------------------------------------------------------------------
>
> Key: WFCORE-2671
> URL: https://issues.jboss.org/browse/WFCORE-2671
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> When keystore (or cerficate in keystore) is changed during server runtime then CLI opertation {{load}} can be used for {{/subsystem=elytron/key-store=...}} to re-reading this keystore in server. However after calling this operation server still works with original keystore/certificate. Then CLI reads current keystore correctly, but in case when ssl-context which uses that key-store is used then original keystore is still used by server. Reload of server is required to correctly re-read the new keystore. See Steps to Reproduce for more details.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2721) Add EnumValidator with disallowed values
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2721?page=com.atlassian.jira.plugi... ]
Jeff Mesnil edited comment on WFCORE-2721 at 4/25/17 9:31 AM:
--------------------------------------------------------------
The EnumValidator is already able to specify disallowed values by leveraging EnumSet#complementOf
was (Author: jmesnil):
The EnumValidator is alreadyable to specify disallowed values by leveraging EnumSet#complementOf
> Add EnumValidator with disallowed values
> ----------------------------------------
>
> Key: WFCORE-2721
> URL: https://issues.jboss.org/browse/WFCORE-2721
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 3.0.0.Beta16
> Reporter: Jeff Mesnil
> Assignee: Brian Stansberry
> Priority: Minor
>
> When some Enum values are not allowed by some operation, the attribute definition must explicitly state all the allowed values.
> It'd be better if an EnumValidator constructor was added with *disallowed values* so that any other values would be implicitely accepted.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2721) Add EnumValidator with disallowed values
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2721?page=com.atlassian.jira.plugi... ]
Jeff Mesnil resolved WFCORE-2721.
---------------------------------
Resolution: Rejected
The EnumValidator is alreadyable to specify disallowed values by leveraging EnumSet#complementOf
> Add EnumValidator with disallowed values
> ----------------------------------------
>
> Key: WFCORE-2721
> URL: https://issues.jboss.org/browse/WFCORE-2721
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 3.0.0.Beta16
> Reporter: Jeff Mesnil
> Assignee: Brian Stansberry
> Priority: Minor
>
> When some Enum values are not allowed by some operation, the attribute definition must explicitly state all the allowed values.
> It'd be better if an EnumValidator constructor was added with *disallowed values* so that any other values would be implicitely accepted.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2721) Add EnumValidator with disallowed values
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2721?page=com.atlassian.jira.plugi... ]
Jeff Mesnil commented on WFCORE-2721:
-------------------------------------
You're right, we can already do that with WFCORE-2651 even if the syntax is a bit more verbose:
{code}
new EnumValidator<>(Foo.class, EnumSet.complementOf(EnumSet.of(Foo.A, Foo.B))
{code}
> Add EnumValidator with disallowed values
> ----------------------------------------
>
> Key: WFCORE-2721
> URL: https://issues.jboss.org/browse/WFCORE-2721
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 3.0.0.Beta16
> Reporter: Jeff Mesnil
> Assignee: Brian Stansberry
> Priority: Minor
>
> When some Enum values are not allowed by some operation, the attribute definition must explicitly state all the allowed values.
> It'd be better if an EnumValidator constructor was added with *disallowed values* so that any other values would be implicitely accepted.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2721) Add EnumValidator with disallowed values
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2721?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2721:
------------------------------------------
WFCORE-2651 was done with this use case in mind.
setValidator(new EnumValidator(Foo.class, EnumSet.noneOf(Foo.A, Foo.B))
> Add EnumValidator with disallowed values
> ----------------------------------------
>
> Key: WFCORE-2721
> URL: https://issues.jboss.org/browse/WFCORE-2721
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 3.0.0.Beta16
> Reporter: Jeff Mesnil
> Assignee: Brian Stansberry
> Priority: Minor
>
> When some Enum values are not allowed by some operation, the attribute definition must explicitly state all the allowed values.
> It'd be better if an EnumValidator constructor was added with *disallowed values* so that any other values would be implicitely accepted.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8593) Wildfly should log bound ports
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8593?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-8593:
-----------------------------------
Issue Type: Bug (was: Enhancement)
> Wildfly should log bound ports
> ------------------------------
>
> Key: WFLY-8593
> URL: https://issues.jboss.org/browse/WFLY-8593
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Jason Tedor
> Assignee: Stuart Douglas
>
> When binding Wildfly to an ephemeral port (i.e., by specifying port 0), Wildfly does not log the port that it actually binds to, but instead logs the port as 0.
> {{09:11:18,955 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:0}}
> Instead, Wildfly should log the ephemeral port that it actually bound to:
> {{09:11:58,769 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:52928}}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8637) Wildfly should log bound ports
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-8637:
--------------------------------------
Summary: Wildfly should log bound ports
Key: WFLY-8637
URL: https://issues.jboss.org/browse/WFLY-8637
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Jason Tedor
Assignee: Stuart Douglas
When binding Wildfly to an ephemeral port (i.e., by specifying port 0), Wildfly does not log the port that it actually binds to, but instead logs the port as 0.
{{09:11:18,955 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:0}}
Instead, Wildfly should log the ephemeral port that it actually bound to:
{{09:11:58,769 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:52928}}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years