[JBoss JIRA] (DROOLS-1750) DroolsAuthoringPerspectiveActivity failed in OPEN (KIE Workbench 6.5.0)
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1750?page=com.atlassian.jira.plugi... ]
Edson Tirelli commented on DROOLS-1750:
---------------------------------------
[~rudyatleti] ok. Red Hat offers patches and support for older releases of the product. If your customer has a Red Hat subscription, just ask him to move to the latest patch where this is fixed.
> DroolsAuthoringPerspectiveActivity failed in OPEN (KIE Workbench 6.5.0)
> -----------------------------------------------------------------------
>
> Key: DROOLS-1750
> URL: https://issues.jboss.org/browse/DROOLS-1750
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.5.0.Final
> Environment: WildFly 10.1
> KIE Workbench 6.5.0
> Reporter: R D
> Assignee: Edson Tirelli
> Fix For: 7.3.0.Final
>
> Attachments: Captura.PNG
>
>
> Ever since making visible the KIE execution server in the KIE workbench, I get an error when switchting to the Project Authoring (see attachment).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3323) Initial Elytron configuration includes mapping-mode="first" in simple-permission-mapper
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3323?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-3323:
----------------------------------------
Fix Version/s: 4.0.0.Alpha1
3.0.5.Final
Assignee: ehsavoie Hugonnet (was: Ilia Vassilev)
Resolution: Done
> Initial Elytron configuration includes mapping-mode="first" in simple-permission-mapper
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-3323
> URL: https://issues.jboss.org/browse/WFCORE-3323
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.3.Final
> Reporter: Ondrej Lukas
> Assignee: ehsavoie Hugonnet
> Priority: Minor
> Fix For: 4.0.0.Alpha1, 3.0.5.Final
>
>
> As part of fix JBEAP-12933 there was added attribute {{mapping-mode="first"}} into "default-permission-mapper" {{simple-permission-mapper}} in default configuration. Value {{first}} is default value of {{simple-permission-mapper.mapping-mode}} which means that this attribute disappears after first change in server configuration. It can be confusing since Elytron subsystem configuration in XML is changed even if there was no request for changing that configuration. Attribute {{mapping-mode="first"}} should be removed from default configuration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3337) Logging resources shouldn't be allowed to removed if they are in-use
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3337?page=com.atlassian.jira.plugi... ]
Brian Stansberry edited comment on WFCORE-3337 at 10/6/17 12:05 PM:
--------------------------------------------------------------------
Nope, capabilities don't have to expose services. Definitely if all the wiring between your resources was tracked via caps/reqs then you would get standard failure behavior if people tried to break model integrity.
was (Author: brian.stansberry):
Nope, capabilities don't have to expose services.
> Logging resources shouldn't be allowed to removed if they are in-use
> --------------------------------------------------------------------
>
> Key: WFCORE-3337
> URL: https://issues.jboss.org/browse/WFCORE-3337
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> Currently you can remove a logging resource even if it's used by another resource. An example of this would be the ability to remove a formatter even though that formatter is attached to a handler. Removing handlers does validate it's not attached to a logger first. However all logging resources should do this.
> Note that logging does not use services which is why this needs to be manually checked. This should be doable via the configuration API. Note too that a fix to validate this will also be done in the logmanager, LOGMGR-179.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3337) Logging resources shouldn't be allowed to removed if they are in-use
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3337?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3337:
------------------------------------------
Nope, capabilities don't have to expose services.
> Logging resources shouldn't be allowed to removed if they are in-use
> --------------------------------------------------------------------
>
> Key: WFCORE-3337
> URL: https://issues.jboss.org/browse/WFCORE-3337
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> Currently you can remove a logging resource even if it's used by another resource. An example of this would be the ability to remove a formatter even though that formatter is attached to a handler. Removing handlers does validate it's not attached to a logger first. However all logging resources should do this.
> Note that logging does not use services which is why this needs to be manually checked. This should be doable via the configuration API. Note too that a fix to validate this will also be done in the logmanager, LOGMGR-179.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3338) Management returning success for read-attribute on non-existent domain server path
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3338?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3338:
-------------------------------------
Summary: Management returning success for read-attribute on non-existent domain server path (was: Management returning success for read-attribute on non-existent path)
> Management returning success for read-attribute on non-existent domain server path
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-3338
> URL: https://issues.jboss.org/browse/WFCORE-3338
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.4.Final
> Reporter: Brad Maxwell
> Assignee: ehsavoie Hugonnet
>
> In Wildfly, a command such as this with a non-existent path returns success instead of failed:
> {code}
> /host=master/server=nonExistant:read-attribute(name=runtime-configuration-state)
> {
> "outcome" => "success",
> "result" => "stopped"
> }
> {code}
> Where as in EAP 6.4:
> {code}
> [domain@localhost:9999 /] /host=master/server=server-NOT-EXIST:read-attribute(name=server-state)
> Failed to get the list of the operation properties: "JBAS014883: No resource definition is registered for address [
> ("host" => "master"),
> ("server" => "server-NOT-EXIST")
> ]"
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3338) Management returning success for read-attribute on non-existent path
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3338?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-3338:
----------------------------------------
Assignee: ehsavoie Hugonnet (was: Brian Stansberry)
I believe the problem here is StoppedServerResource. For all the attributes it exposes the OSH needs to do a non-recursive read of the /host=x resource and check the names of the server-config resources. If the name of the server the op is targeting is not present there, the OSH should throw a NoSuchResource exception.
Tests should be added, probably to ServerManagementTestCase.
> Management returning success for read-attribute on non-existent path
> --------------------------------------------------------------------
>
> Key: WFCORE-3338
> URL: https://issues.jboss.org/browse/WFCORE-3338
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.4.Final
> Reporter: Brad Maxwell
> Assignee: ehsavoie Hugonnet
>
> In Wildfly, a command such as this with a non-existent path returns success instead of failed:
> {code}
> /host=master/server=nonExistant:read-attribute(name=runtime-configuration-state)
> {
> "outcome" => "success",
> "result" => "stopped"
> }
> {code}
> Where as in EAP 6.4:
> {code}
> [domain@localhost:9999 /] /host=master/server=server-NOT-EXIST:read-attribute(name=server-state)
> Failed to get the list of the operation properties: "JBAS014883: No resource definition is registered for address [
> ("host" => "master"),
> ("server" => "server-NOT-EXIST")
> ]"
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month