[JBoss JIRA] (WFLY-8245) AuthenticationContext should not be loaded from wildfly-config.xml automatically in deployment
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-8245?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-8245:
-------------------------------
Description:
In case when wildfly-config.xml is located in deployment and application server does not have configured default-authentication-context for Elytron subsystem, then AuthenticationContext is automatically parsed from wildfly-config.xml.
In case when default-authentication-context for Elytron subsystem is configured, then AuthenticationContext is correctly loaded from application server.
If this is intended then it should be reflect in documentation - it currently says that "... they can make use of a configuration file using the _parseAuthenticationClientConfiguration(URI)_ method ...", but in current implementation it is parsed automatically.
[~dlofthouse] Could you please clarify whether this is intended change or it is an issue?
was:
In case when wildfly-config.xml is located in deployment and application server does not have configured default-authentication-context for Elytron subsystem, then AuthenticationContext is automatically parsed from wildfly-config.xml.
This behavior was changed between EAP 7.1.0.DR11 and EAP 7.1.0.DR12 (try Steps to Reproduce with DR12 as well as DR11).
In case when default-authentication-context for Elytron subsystem is configured, then AuthenticationContext is correctly loaded from application server.
If this is intended then it should be reflect in documentation - it currently says that "... they can make use of a configuration file using the _parseAuthenticationClientConfiguration(URI)_ method ...", but in current implementation it is parsed automatically.
[~dlofthouse] Could you please clarify whether this is intended change or it is an issue?
> AuthenticationContext should not be loaded from wildfly-config.xml automatically in deployment
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-8245
> URL: https://issues.jboss.org/browse/WFLY-8245
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
>
> In case when wildfly-config.xml is located in deployment and application server does not have configured default-authentication-context for Elytron subsystem, then AuthenticationContext is automatically parsed from wildfly-config.xml.
> In case when default-authentication-context for Elytron subsystem is configured, then AuthenticationContext is correctly loaded from application server.
> If this is intended then it should be reflect in documentation - it currently says that "... they can make use of a configuration file using the _parseAuthenticationClientConfiguration(URI)_ method ...", but in current implementation it is parsed automatically.
> [~dlofthouse] Could you please clarify whether this is intended change or it is an issue?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-8245) AuthenticationContext should not be loaded from wildfly-config.xml automatically in deployment
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-8245:
----------------------------------
Summary: AuthenticationContext should not be loaded from wildfly-config.xml automatically in deployment
Key: WFLY-8245
URL: https://issues.jboss.org/browse/WFLY-8245
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Priority: Critical
In case when wildfly-config.xml is located in deployment and application server does not have configured default-authentication-context for Elytron subsystem, then AuthenticationContext is automatically parsed from wildfly-config.xml.
This behavior was changed between EAP 7.1.0.DR11 and EAP 7.1.0.DR12 (try Steps to Reproduce with DR12 as well as DR11).
In case when default-authentication-context for Elytron subsystem is configured, then AuthenticationContext is correctly loaded from application server.
If this is intended then it should be reflect in documentation - it currently says that "... they can make use of a configuration file using the _parseAuthenticationClientConfiguration(URI)_ method ...", but in current implementation it is parsed automatically.
[~dlofthouse] Could you please clarify whether this is intended change or it is an issue?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JGRP-2159) Delta view cannot be installed
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2159?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2159:
--------------------------------
Here's how this can be reproduced (unit test: {{DeltaViewTest}}):
* J is the coordinator and has view J|0=K
* K joins and sends a JOIN-REQ to J
* J creates new view J|1=J,K (setting {{ltime}} to 1) and multicasts it, but the multicast is delayed (e.g. dropped and retransmitted)
* Finally, J sends a JOIN-RSP with view J|1 to K
* Before receiving the new view, K times out and sends another JOIN-REQ to J
* K receives view J|1 and installs it
* J creates a new view J|2=J,K (setting {{ltime}} to 2) and multicasts it. The multicast is again delayed.
* J sends a JOIN-RSP to K with view J|2, K installs it
* J finally gets the first view multicast and installs J|1=J,K
* New member L sends a JOIN-RSP to J
* J creates view J|3=JKL and multicasts it, and then sends a JOIN-RSP to L
* The multicast of J|3 is a *DeltaView* with ref-view-id=J|1 and joiners=L
* L installs the new view
* J installs the new view J|3
* However, K cannot install the new view as ref-view-id=J|1 is not known as it has view=J|2!
SOLUTION:
* The reason why spurious view J|2 is sent to K is that J hasn't yet installed view J|1 locally. If that was the case, it would see that K is already a member and simply resend view J|1, instead of creating view J|2.
* We therefore need to make sure a new view is installed in the coordinator *before* multicasting it, and this can be done by setting {{install_view_locally_first}} to true by default (or even removing the attribute)
* As a second line of defense, make the recepient of a DeltaView that cannot be installed send a request to the coordinator to resend the view as a full- instead of a delta- view.
* J creates new view J|3=JL
> Delta view cannot be installed
> ------------------------------
>
> Key: JGRP-2159
> URL: https://issues.jboss.org/browse/JGRP-2159
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.1, 4.0.1
>
> Attachments: discarded_delta_view.log
>
>
> A DeltaView cannot be installed because the ref view-id is not the current view-id.
> Looking at the view sequence for members J, K and L:
> {noformat}
> 19:22:54,278 DEBUG (testng-Test:[]) [GMS] J: installing view [J|0] (1) [J]
> 19:22:56,519 DEBUG (testng-Test:[]) [GMS] K: installing view [J|1] (2) [J, K]
> 19:22:56,572 DEBUG (jgroups-7,J:[]) [GMS] J: installing view [J|1] (2) [J, K]
> 19:22:56,590 DEBUG (jgroups-5,K:[]) [GMS] K: installing view [J|2] (2) [J, K]
> 19:22:58,585 DEBUG (jgroups-5,J:[]) [GMS] J: installing view [J|3] (3) [J, K, L]
> 19:23:00,603 DEBUG (testng-Test:[]) [GMS] L: installing view [J|3] (3) [J, K, L]
> {noformat}
> K cannot install DeltaView J|3 because it has view J|2 but the DeltaView has ref view-id J|1.
> The reason is that J|2 was apparently installed *only* at K (but not at coordinator J1!), despite it being the same view as J|1.
> We need to look into why J|2 was installed at K only. Second line of defense: when a DeltaView cannot be installed, send a message to the view sender (coord) and solicit the full view instead.
> See the attached log.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JGRP-2159) Delta view cannot be installed
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2159?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2159 at 2/27/17 2:44 AM:
---------------------------------------------------------
Workaround: {{GMS.use_delta_views="false"}} or {{GMS.install_view_locally_first="true"}}
was (Author: belaban):
Workaround: {{GMS.use_delta_views="false"}}
> Delta view cannot be installed
> ------------------------------
>
> Key: JGRP-2159
> URL: https://issues.jboss.org/browse/JGRP-2159
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.1, 4.0.1
>
> Attachments: discarded_delta_view.log
>
>
> A DeltaView cannot be installed because the ref view-id is not the current view-id.
> Looking at the view sequence for members J, K and L:
> {noformat}
> 19:22:54,278 DEBUG (testng-Test:[]) [GMS] J: installing view [J|0] (1) [J]
> 19:22:56,519 DEBUG (testng-Test:[]) [GMS] K: installing view [J|1] (2) [J, K]
> 19:22:56,572 DEBUG (jgroups-7,J:[]) [GMS] J: installing view [J|1] (2) [J, K]
> 19:22:56,590 DEBUG (jgroups-5,K:[]) [GMS] K: installing view [J|2] (2) [J, K]
> 19:22:58,585 DEBUG (jgroups-5,J:[]) [GMS] J: installing view [J|3] (3) [J, K, L]
> 19:23:00,603 DEBUG (testng-Test:[]) [GMS] L: installing view [J|3] (3) [J, K, L]
> {noformat}
> K cannot install DeltaView J|3 because it has view J|2 but the DeltaView has ref view-id J|1.
> The reason is that J|2 was apparently installed *only* at K (but not at coordinator J1!), despite it being the same view as J|1.
> We need to look into why J|2 was installed at K only. Second line of defense: when a DeltaView cannot be installed, send a message to the view sender (coord) and solicit the full view instead.
> See the attached log.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-8244) Changing management interface with allow-resource-service-restart ends in reload-required state
by Martin Choma (JIRA)
Martin Choma created WFLY-8244:
----------------------------------
Summary: Changing management interface with allow-resource-service-restart ends in reload-required state
Key: WFLY-8244
URL: https://issues.jboss.org/browse/WFLY-8244
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Martin Choma
Assignee: Darran Lofthouse
If I try to change elytron authentication for management interface with header {{allow-resource-service-restart=true}} server ends in {{reload-required}} state.
{code}
[standalone@localhost:9990 /] /core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory, value=application-http-authentication){allow-resource-service-restart=true}
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
{code}
Using header {{allow-resource-service-restart=true}} should restart necessary services.
If it can't be implemented for some reason, rather throw UnsupportedOperationException - it seems to me to be more fair.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFCORE-2331) When --cached-dc used HC does not inform on configuration change if DC reconnection happens
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2331?page=com.atlassian.jira.plugi... ]
Ken Wills moved JBEAP-9133 to WFCORE-2331:
------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2331 (was: JBEAP-9133)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: Domain Management)
Affects Version/s: (was: 7.1.0.DR11)
> When --cached-dc used HC does not inform on configuration change if DC reconnection happens
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-2331
> URL: https://issues.jboss.org/browse/WFCORE-2331
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ken Wills
> Assignee: Ken Wills
>
> HC does not inform that DC changed configuration and reload/restart is required when `--cached-dc` is used.
> This issue was created based on discussion at https://issues.jboss.org/browse/EAP7-496.
> HC starts with `--cached-dc` and DC is down. If DC contains changed attribute and is started HC receives configuration updates that was changed in comparison to existing
> "domain.cached-remote.xml". The change seems to be propagated to HC but it's not "activated" (it's not part of model at HC) neither information that reload/restart of HC is needed is provided.
> This could be checked with following steps
> # start DC and HC with {{--cached-dc}} parameter
> {code}
> cd $JBOSS_HOME
> ./bin/domain.sh --host-config=host-master.xml
> ./bin/domain.sh --host-config=host-slave.xml -Djboss.domain.master.address=127.0.0.1 -Djboss.management.native.port=9899 -Djboss.host.name=slave --cached-dc
> {code}
> # stop HC
> # configure logging at DC
> {code}
> cd $JBOSS_HOME
> ./bin/jboss-cli.sh -c
> /profile=full/subsystem=logging/logger=my.test:add(category=my.test, level=FINE)
> {code}
> # stop DC
> # start HC
> {code}
> ./bin/domain.sh --host-config=host-slave.xml -Djboss.domain.master.address=127.0.0.1 -Djboss.management.native.port=9899 -Djboss.host.name=slave --cached-dc
> {code}
> # check that logging is not configured
> {code}
> ./bin/jboss-cli.sh -c --controller=remoting://localhost:9899
> /host=slave/server=server-one/subsystem=logging:read-children-resources(child-type=logger)
> {code}
> # start DC and wait a while when HC is connected to it
> {code}
> INFO [org.jboss.as.host.controller] (Host Controller Service Threads - 33) WFLYHC0150: Trying to reconnect to master host controller.
> INFO [org.jboss.as.host.controller] (Host Controller Service Threads - 33) WFLYHC0148: Connected to master host controller at remote://127.0.0.1:9999
> {code}
> # check what DC says about server-one
> {code}
> ./bin/jboss-cli.sh -c
> /host=slave/server=server-one/subsystem=logging:read-children-resources(child-type=logger)
> {code}
> The result is that the new logger {{my.test}} is not part of the configuration of {{server-one}}. There is no warning about such fact in server log what I can see.
> True is that here behaves differently against my testing before that after printing resources of the subsystem {{logging}} node there is information {{reload-required}}.
> From your point of view - is this correct behavior? If so I think some warning message in server log at least that content of {{domain.cached-remote.xml}} is not in sync with servers' model should be promoted.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFCORE-2330) JBoss-CLI "deploy -l" always returns exit code 1 even when it succeeds
by Masafumi Miura (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2330?page=com.atlassian.jira.plugi... ]
Masafumi Miura updated WFCORE-2330:
-----------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2207
> JBoss-CLI "deploy -l" always returns exit code 1 even when it succeeds
> ----------------------------------------------------------------------
>
> Key: WFCORE-2330
> URL: https://issues.jboss.org/browse/WFCORE-2330
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Masafumi Miura
>
> JBoss-CLI "deploy -l" always returns exit code 1 even when it succeededs.
> It looks that DeploymentHandler.listDeployments() always throws CommandFormatException and this causes the "deploy -l" command returns exit code 1.
> {code:java|title=cli/src/main/java/org/jboss/as/cli/handlers/DeploymentHandler.java}
> 55 protected void listDeployments(CommandContext ctx, boolean l) throws CommandFormatException {
> 56 if(!l) {
> 57 printList(ctx, Util.getDeployments(ctx.getModelControllerClient()), l);
> 58 return;
> 59 }
> 60 final ModelControllerClient client = ctx.getModelControllerClient();
> 61 final List<String> names = Util.getDeployments(client);
> 62 if(names.isEmpty()) {
> 63 return;
> 64 }
> 65
> 66 final StrictSizeTable table = new StrictSizeTable(names.size());
> 67 final List<Property> descriptions = getDeploymentDescriptions(ctx, names).asPropertyList();
> 68 for(Property prop : descriptions) {
> 69 final ModelNode step = prop.getValue();
> 70 if(step.hasDefined(Util.RESULT)) {
> 71 final ModelNode result = step.get(Util.RESULT);
> 72 table.addCell(Util.NAME, result.get(Util.NAME).asString());
> 73 table.addCell(Util.RUNTIME_NAME, result.get(Util.RUNTIME_NAME).asString());
> 74 if(result.has(Util.ENABLED)) {
> 75 table.addCell(Util.ENABLED, result.get(Util.ENABLED).asString());
> 76 }
> 77 if(result.has(Util.STATUS)) {
> 78 table.addCell(Util.STATUS, result.get(Util.STATUS).asString());
> 79 }
> 80 }
> 81 if(!table.isAtLastRow()) {
> 82 table.nextRow();
> 83 }
> 84 }
> 85 throw new CommandFormatException(table.toString()); // -> CommandFormatException is always thrown. This looks a root cause.
> 86 }
> {code}
> {code:java|title=cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java}
> 907 public void handleSafe(String line) {
> 908 exitCode = 0;
> 909 try {
> 910 handle(line);
> 911 } catch(Throwable t) {
> 912 error(Util.getMessagesFromThrowable(t)); // -> This is invoked when CommandFormatException happened in the above listDeployments.
> 913 }
> 914 }
> :
> 993 protected void error(String message) {
> 994 this.exitCode = 1;
> 995 printLine(message);
> 996 }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFCORE-2330) JBoss-CLI "deploy -l" always returns exit code 1 even when it succeeds
by Masafumi Miura (JIRA)
Masafumi Miura created WFCORE-2330:
--------------------------------------
Summary: JBoss-CLI "deploy -l" always returns exit code 1 even when it succeeds
Key: WFCORE-2330
URL: https://issues.jboss.org/browse/WFCORE-2330
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Masafumi Miura
JBoss-CLI "deploy -l" always returns exit code 1 even when it succeededs.
It looks that DeploymentHandler.listDeployments() always throws CommandFormatException and this causes the "deploy -l" command returns exit code 1.
{code:java|title=cli/src/main/java/org/jboss/as/cli/handlers/DeploymentHandler.java}
55 protected void listDeployments(CommandContext ctx, boolean l) throws CommandFormatException {
56 if(!l) {
57 printList(ctx, Util.getDeployments(ctx.getModelControllerClient()), l);
58 return;
59 }
60 final ModelControllerClient client = ctx.getModelControllerClient();
61 final List<String> names = Util.getDeployments(client);
62 if(names.isEmpty()) {
63 return;
64 }
65
66 final StrictSizeTable table = new StrictSizeTable(names.size());
67 final List<Property> descriptions = getDeploymentDescriptions(ctx, names).asPropertyList();
68 for(Property prop : descriptions) {
69 final ModelNode step = prop.getValue();
70 if(step.hasDefined(Util.RESULT)) {
71 final ModelNode result = step.get(Util.RESULT);
72 table.addCell(Util.NAME, result.get(Util.NAME).asString());
73 table.addCell(Util.RUNTIME_NAME, result.get(Util.RUNTIME_NAME).asString());
74 if(result.has(Util.ENABLED)) {
75 table.addCell(Util.ENABLED, result.get(Util.ENABLED).asString());
76 }
77 if(result.has(Util.STATUS)) {
78 table.addCell(Util.STATUS, result.get(Util.STATUS).asString());
79 }
80 }
81 if(!table.isAtLastRow()) {
82 table.nextRow();
83 }
84 }
85 throw new CommandFormatException(table.toString()); // -> CommandFormatException is always thrown. This looks a root cause.
86 }
{code}
{code:java|title=cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java}
907 public void handleSafe(String line) {
908 exitCode = 0;
909 try {
910 handle(line);
911 } catch(Throwable t) {
912 error(Util.getMessagesFromThrowable(t)); // -> This is invoked when CommandFormatException happened in the above listDeployments.
913 }
914 }
:
993 protected void error(String message) {
994 this.exitCode = 1;
995 printLine(message);
996 }
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1432) Improve error messages when compiling models with errors
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1432?page=com.atlassian.jira.plugi... ]
Edson Tirelli commented on DROOLS-1432:
---------------------------------------
Major infrastructure changes to properly support error validation are now implemented. Type definition and resolution is now correlated between DMN layer and FEEL layer. Additional work will be done through other tickets.
> Improve error messages when compiling models with errors
> --------------------------------------------------------
>
> Key: DROOLS-1432
> URL: https://issues.jboss.org/browse/DROOLS-1432
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.0.0.Beta6
> Reporter: Edson Tirelli
> Assignee: Edson Tirelli
> Fix For: 7.0.0.Final
>
> Attachments: car_damage_responsibility2.dmn
>
>
> When a model contains errors that prevent compilation, the engine should provide a better error message pointing to the specific error.
> At the moment, the attached model fails with a NPE and a message:
> {quote}Message [id=1, kieBase=defaultKieBase, level=ERROR, path=car_damage_responsibility2.dmn, line=-1, column=0 text=Unable to compile DMN model for the resource]{quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months