[JBoss JIRA] (ELY-1098) WildFly Elytron Client Configuration File created based on elytron-1_0.xsd is not valid for clients
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-1098?page=com.atlassian.jira.plugin.s... ]
Ondrej Lukas updated ELY-1098:
------------------------------
Affects Version/s: 1.1.0.Beta34
> WildFly Elytron Client Configuration File created based on elytron-1_0.xsd is not valid for clients
> ---------------------------------------------------------------------------------------------------
>
> Key: ELY-1098
> URL: https://issues.jboss.org/browse/ELY-1098
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta34
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> There are some issues which causes that WildFly Elytron Client Configuration File created based on elytron-1_0.xsd is not valid for clients:
> * root element {{configuration}} is not included in elytron-1_0.xsd, it means that configuration with {{configuration}} are handled as invalid and configuration which has {{authentication-client}} as root element as valid
> * XSD elytron-1_0.xsd includes some elements on the highest level of XSD, which for example means that configuration file which includes only element {{<set-user-name name="someUser"/>}} is valid according to XSD.
> We request blocker because validated configuration file will not work correctly in clients. Moreover XSD is source of information which can be used by users for creating wildfly-config.xml correctly or validate their configuration file before using it. Mentioned issues can cause that this validation using elytron-1_0.xsd becomes unusable for users.
> This issue is blocker for GA, not for testing.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1098) WildFly Elytron Client Configuration File created based on elytron-1_0.xsd is not valid for clients
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-1098?page=com.atlassian.jira.plugin.s... ]
Ondrej Lukas updated ELY-1098:
------------------------------
Description:
There are some issues which causes that WildFly Elytron Client Configuration File created based on elytron-1_0.xsd is not valid for clients:
* root element {{configuration}} is not included in elytron-1_0.xsd, it means that configuration with {{configuration}} are handled as invalid and configuration which has {{authentication-client}} as root element as valid
* XSD elytron-1_0.xsd includes some elements on the highest level of XSD, which for example means that configuration file which includes only element {{<set-user-name name="someUser"/>}} is valid according to XSD.
We request blocker because validated configuration file will not work correctly in clients. Moreover XSD is source of information which can be used by users for creating wildfly-config.xml correctly or validate their configuration file before using it. Mentioned issues can cause that this validation using elytron-1_0.xsd becomes unusable for users.
was:
There are some issues which causes that WildFly Elytron Client Configuration File created based on elytron-1_0.xsd is not valid for clients:
* root element {{configuration}} is not included in elytron-1_0.xsd, it means that configuration with {{configuration}} are handled as invalid and configuration which has {{authentication-client}} as root element as valid
* XSD elytron-1_0.xsd includes some elements on the highest level of XSD, which for example means that configuration file which includes only element {{<set-user-name name="someUser"/>}} is valid according to XSD.
We request blocker because validated configuration file will not work correctly in clients. Moreover XSD is source of information which can be used by users for creating wildfly-config.xml correctly or validate their configuration file before using it. Mentioned issues can cause that this validation using elytron-1_0.xsd becomes unusable for users.
This issue is blocker for GA, not for testing.
> WildFly Elytron Client Configuration File created based on elytron-1_0.xsd is not valid for clients
> ---------------------------------------------------------------------------------------------------
>
> Key: ELY-1098
> URL: https://issues.jboss.org/browse/ELY-1098
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta34
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> There are some issues which causes that WildFly Elytron Client Configuration File created based on elytron-1_0.xsd is not valid for clients:
> * root element {{configuration}} is not included in elytron-1_0.xsd, it means that configuration with {{configuration}} are handled as invalid and configuration which has {{authentication-client}} as root element as valid
> * XSD elytron-1_0.xsd includes some elements on the highest level of XSD, which for example means that configuration file which includes only element {{<set-user-name name="someUser"/>}} is valid according to XSD.
> We request blocker because validated configuration file will not work correctly in clients. Moreover XSD is source of information which can be used by users for creating wildfly-config.xml correctly or validate their configuration file before using it. Mentioned issues can cause that this validation using elytron-1_0.xsd becomes unusable for users.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1098) WildFly Elytron Client Configuration File created based on elytron-1_0.xsd is not valid for clients
by Ondrej Lukas (JIRA)
Ondrej Lukas created ELY-1098:
---------------------------------
Summary: WildFly Elytron Client Configuration File created based on elytron-1_0.xsd is not valid for clients
Key: ELY-1098
URL: https://issues.jboss.org/browse/ELY-1098
Project: WildFly Elytron
Issue Type: Bug
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Priority: Blocker
There are some issues which causes that WildFly Elytron Client Configuration File created based on elytron-1_0.xsd is not valid for clients:
* root element {{configuration}} is not included in elytron-1_0.xsd, it means that configuration with {{configuration}} are handled as invalid and configuration which has {{authentication-client}} as root element as valid
* XSD elytron-1_0.xsd includes some elements on the highest level of XSD, which for example means that configuration file which includes only element {{<set-user-name name="someUser"/>}} is valid according to XSD.
We request blocker because validated configuration file will not work correctly in clients. Moreover XSD is source of information which can be used by users for creating wildfly-config.xml correctly or validate their configuration file before using it. Mentioned issues can cause that this validation using elytron-1_0.xsd becomes unusable for users.
This issue is blocker for GA, not for testing.
--
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 updated WFCORE-2721:
--------------------------------
Priority: Minor (was: Major)
> 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:
-------------------------------------
WFLY-8520 would have benefit from such an enhancement (insted of explicitly listing all other allowed values)
> 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
>
> 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)
Jeff Mesnil created WFCORE-2721:
-----------------------------------
Summary: 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
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:
-------------------------------------
WFLY-8636 would benefit from such an EnumValidator by explicitely disallowing external-context value.
> 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
>
> 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-8636) Fix naming rebind resource-description
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-8636:
---------------------------------
Summary: Fix naming rebind resource-description
Key: WFLY-8636
URL: https://issues.jboss.org/browse/WFLY-8636
Project: WildFly
Issue Type: Bug
Components: Naming
Affects Versions: 11.0.0.Alpha1
Reporter: Jeff Mesnil
Priority: Minor
The naming :rebind operation describes the "external-context" value as allowed for its binding-type attribute but the code will fails if that's the case.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2691) Elytron modifiable realms should show existing identities in subsystem
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2691?page=com.atlassian.jira.plugi... ]
Jan Kalina commented on WFCORE-2691:
------------------------------------
Communicated in mailinglist:
Best solution will be *removing identity resouces and using realm operations for access to identities instead*.
> Elytron modifiable realms should show existing identities in subsystem
> ----------------------------------------------------------------------
>
> Key: WFCORE-2691
> URL: https://issues.jboss.org/browse/WFCORE-2691
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta15
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: filesystem-realm, security-realm
>
> Elytron {{filesystem-realm}} should load existing identities from file system. The steps to reproduce results in:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:read-identity
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"elytron\"),
> (\"filesystem-realm\" => \"realm\"),
> (\"identity\" => \"user\")
> ]' not found",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:add
> {
> "outcome" => "failed",
> "failure-description" => "WFLYELY01000: Identity with name [user] already exists.",
> "rolled-back" => true
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (DROOLS-1537) Scheduled activations are rescheduled as if new when unmarshalling session in Drools 6.5
by Kay J (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1537?page=com.atlassian.jira.plugi... ]
Kay J updated DROOLS-1537:
--------------------------
Attachment: RestoreReproducer.java
> 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: Edson Tirelli
> 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