[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)
9 years, 2 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)
9 years, 2 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)
9 years, 2 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)
9 years, 2 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)
9 years, 2 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 updated DROOLS-1432:
----------------------------------
Release Notes Text: (was: 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)
9 years, 2 months
[JBoss JIRA] (WFLY-8243) Clustered Singleton MDB does not activate
by Flavia Rainone (JIRA)
[ https://issues.jboss.org/browse/WFLY-8243?page=com.atlassian.jira.plugin.... ]
Flavia Rainone moved JBEAP-9130 to WFLY-8243:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8243 (was: JBEAP-9130)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
EJB
JMS
(was: Clustering)
(was: EJB)
(was: JMS)
Affects Version/s: (was: 7.1.0.DR8)
(was: 7.1.0.DR10)
(was: 7.1.0.DR11)
(was: 7.1.0.DR12)
Affects Testing: (was: Regression)
> Clustered Singleton MDB does not activate
> -----------------------------------------
>
> Key: WFLY-8243
> URL: https://issues.jboss.org/browse/WFLY-8243
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB, JMS
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
> Priority: Blocker
>
> Clustered Singleton MDB does not activate. It's regression in EAP 7.1.0.DR8 (against DR7).
> Customer impact: No Clustered Singleton MDB will activate in cluster and service will not operate. No warning or error will show in server logs. There is no workaround for this issue.
> Test scenario:
> - Start two EAP 7.1.0.DR8 servers in cluster with active delivery-group named "group"
> - Deploy queues InQueue and OutQueue to both of the servers. There is also Artemis cluster configured between servers so all messages will be load-balanced between the nodes.
> - Deploy MDB configured as clustered singletons to both of the server. MDBs belong to delivery-group "group"
> -- MDB consumes messages from InQueue and resends to OutQueue
> - Start sending messages to InQueue and consume from OutQueue.
> - Check that MDB on node 1 is active as it's sigleton master
> - Check that MDB on node 2 is NOT active
> - Kill node-1 (by kill -9 ...)
> - Check that MDB on node 2 is active as it's sigleton master
> Expected result:
> Consumer will receive all messages from OutQueue. All checks passes.
> Actual result:
> MDB on node 1 is not delivery active at the beginning of the test. Consumer timed out as there are no processed messages in OutQueue
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8242) EjbSuspendHandler.endSuspension throws NPE
by Flavia Rainone (JIRA)
Flavia Rainone created WFLY-8242:
------------------------------------
Summary: EjbSuspendHandler.endSuspension throws NPE
Key: WFLY-8242
URL: https://issues.jboss.org/browse/WFLY-8242
Project: WildFly
Issue Type: Bug
Components: EJB
Reporter: Flavia Rainone
Assignee: Flavia Rainone
This exception occurs sometimes:
java.lang.NullPointerException
at org.jboss.as.ejb3.suspend.EJBSuspendHandlerService.doneSuspended(EJBSuspendHandlerService.java:303) [wildfly-ejb3-7.1.0.Alpha1-redhat-SNAPSHOT.jar:7.1.0.Alpha1-redhat-SNAPSHOT]
at org.jboss.as.ejb3.suspend.EJBSuspendHandlerService.decrementTransactionCount(EJBSuspendHandlerService.java:315) [wildfly-ejb3-7.1.0.Alpha1-redhat-SNAPSHOT.jar:7.1.0.Alpha1-redhat-SNAPSHOT]
at org.jboss.as.ejb3.suspend.EJBSuspendHandlerService.afterCompletion(EJBSuspendHandlerService.java:285) [wildfly-ejb3-7.1.0.Alpha1-redhat-SNAPSHOT.jar:7.1.0.Alpha1-redhat-SNAPSHOT]
at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:101)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1216)
at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:69) [wildfly-transaction-client-1.0.0.Beta17.jar:1.0.0.Beta17]
at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:61) [wildfly-transaction-client-1.0.0.Beta17.jar:1.0.0.Beta17]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:91) [wildfly-ejb3-7.1.0.Alpha1-redhat-SNAPSHOT.jar:7.1.0.Alpha1-redhat-SNAPSHOT]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279) [wildfly-ejb3-7.1.0.Alpha1-redhat-SNAPSHOT.jar:7.1.0.Alpha1-redhat-SNAPSHOT]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:349) [wildfly-ejb3-7.1.0.Alpha1-redhat-SNAPSHOT.jar:7.1.0.Alpha1-redhat-SNAPSHOT]
at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:68) [wildfly-ejb3-7.1.0.Alpha1-redhat-SNAPSHOT.jar:7.1.0.Alpha1-redhat-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-7.1.0.Alpha1-redhat-SNAPSHOT.jar:7.1.0.Alpha1-redhat-SNAPSHOT]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months