[JBoss JIRA] (WFLY-8058) Can't undefine attribute restart-jobs-on-resume in batch-jberet subsystem
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-8058?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFLY-8058:
--------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/9621
> Can't undefine attribute restart-jobs-on-resume in batch-jberet subsystem
> -------------------------------------------------------------------------
>
> Key: WFLY-8058
> URL: https://issues.jboss.org/browse/WFLY-8058
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> {noformat}
> [standalone@localhost:9990 /] /subsystem=batch-jberet:undefine-attribute(name=restart-jobs-on-resume
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
> "rolled-back" => true
> }
> {noformat}
> Stack trace on server side:
> {noformat}
> 12:42:08,192 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("undefine-attribute") failed - address: ([("subsystem" => "batch-jberet")]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> at org.wildfly.extension.batch.jberet.BatchSubsystemDefinition$1.setValue(BatchSubsystemDefinition.java:159)
> at org.wildfly.extension.batch.jberet.BatchSubsystemDefinition$1.applyUpdateToRuntime(BatchSubsystemDefinition.java:147)
> at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:921)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:664)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:383)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1390)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:419)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:240)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:193)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:240)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:212)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
> The problem is that the write handler of this attribute doesn't properly handle an undefined value: https://github.com/wildfly/wildfly/blob/9390551b93126e2216e49b4b02bc9f646...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8058) Can't undefine attribute restart-jobs-on-resume in batch-jberet subsystem
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-8058?page=com.atlassian.jira.plugin.... ]
James Perkins reassigned WFLY-8058:
-----------------------------------
Assignee: James Perkins (was: Dmitrii Tikhomirov)
> Can't undefine attribute restart-jobs-on-resume in batch-jberet subsystem
> -------------------------------------------------------------------------
>
> Key: WFLY-8058
> URL: https://issues.jboss.org/browse/WFLY-8058
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> {noformat}
> [standalone@localhost:9990 /] /subsystem=batch-jberet:undefine-attribute(name=restart-jobs-on-resume
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
> "rolled-back" => true
> }
> {noformat}
> Stack trace on server side:
> {noformat}
> 12:42:08,192 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("undefine-attribute") failed - address: ([("subsystem" => "batch-jberet")]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> at org.wildfly.extension.batch.jberet.BatchSubsystemDefinition$1.setValue(BatchSubsystemDefinition.java:159)
> at org.wildfly.extension.batch.jberet.BatchSubsystemDefinition$1.applyUpdateToRuntime(BatchSubsystemDefinition.java:147)
> at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:921)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:664)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:383)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1390)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:419)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:240)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:193)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:240)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:212)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
> The problem is that the write handler of this attribute doesn't properly handle an undefined value: https://github.com/wildfly/wildfly/blob/9390551b93126e2216e49b4b02bc9f646...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8059) Nanosecond precision lost in SqlTimestampExternalizer and InstantExternalizer
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-8059:
------------------------------------
Summary: Nanosecond precision lost in SqlTimestampExternalizer and InstantExternalizer
Key: WFLY-8059
URL: https://issues.jboss.org/browse/WFLY-8059
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.1.0.Final
Reporter: Radoslav Husar
Assignee: Radoslav Husar
This is evident with JDK fix for https://bugs.openjdk.java.net/browse/JDK-8068730
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running org.wildfly.clustering.marshalling.spi.IndexExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec - in org.wildfly.clustering.marshalling.spi.IndexExternalizerTestCase
Running org.wildfly.clustering.marshalling.spi.net.NetExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec - in org.wildfly.clustering.marshalling.spi.net.NetExternalizerTestCase
Running org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec <<< FAILURE! - in org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase
test(org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase) Time elapsed: 0.019 sec <<< FAILURE!
java.lang.AssertionError: expected:<2017-02-08T11:02:48.240513Z> but was:<2017-02-08T11:02:48.240Z>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.lambda$test$0(ExternalizerTestUtil.java:42)
at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:55)
at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:42)
at org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase.test(TimeExternalizerTestCase.java:54)
Running org.wildfly.clustering.marshalling.spi.util.AtomicExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec - in org.wildfly.clustering.marshalling.spi.util.AtomicExternalizerTestCase
Running org.wildfly.clustering.marshalling.spi.util.CollectionExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec - in org.wildfly.clustering.marshalling.spi.util.CollectionExternalizerTestCase
Running org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec <<< FAILURE! - in org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase
test(org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase) Time elapsed: 0.017 sec <<< FAILURE!
java.lang.AssertionError: expected:<2017-02-08 12:02:48.30185> but was:<2017-02-08 12:02:48.301>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.lambda$test$0(ExternalizerTestUtil.java:42)
at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:55)
at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:42)
at org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase.test(DateExternalizerTestCase.java:49)
Running org.wildfly.clustering.marshalling.spi.util.MapEntryExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec - in org.wildfly.clustering.marshalling.spi.util.MapEntryExternalizerTestCase
Running org.wildfly.clustering.marshalling.spi.util.MapExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec - in org.wildfly.clustering.marshalling.spi.util.MapExternalizerTestCase
Running org.wildfly.clustering.marshalling.spi.util.UtilExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec - in org.wildfly.clustering.marshalling.spi.util.UtilExternalizerTestCase
Results :
Failed tests:
TimeExternalizerTestCase.test:54 expected:<2017-02-08T11:02:48.240513Z> but was:<2017-02-08T11:02:48.240Z>
DateExternalizerTestCase.test:49 expected:<2017-02-08 12:02:48.30185> but was:<2017-02-08 12:02:48.301>
Tests run: 9, Failures: 2, Errors: 0, Skipped: 0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1809) JBoss CLI patch command doesn't honor custom configuration location
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1809?page=com.atlassian.jira.plugi... ]
Alexey Loubyansky closed WFCORE-1809.
-------------------------------------
Resolution: Rejected
This is not going to be supported by the current patching mechanism.
> JBoss CLI patch command doesn't honor custom configuration location
> -------------------------------------------------------------------
>
> Key: WFCORE-1809
> URL: https://issues.jboss.org/browse/WFCORE-1809
> Project: WildFly Core
> Issue Type: Bug
> Components: Patching
> Affects Versions: 3.0.0.Alpha8
> Reporter: Alexey Loubyansky
> Assignee: Alexey Loubyansky
>
> Suppose we are using custom standalone directory(example: standalone_dev) and if we try to rollback applied CP patch, with "--rest-configuration=true" option, it always restore configuration files from default location(JBOSS_HOME/standalone) not from the "standalone_dev" directory. I can see same result when I try to rollback patch through management console and through JBoss CLI in connected mode.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFCORE-13:
-----------------------------
Fix Version/s: 3.0.0.Alpha25
(was: 3.0.0.Alpha24)
> End users can call non-published management API operations
> ----------------------------------------------------------
>
> Key: WFCORE-13
> URL: https://issues.jboss.org/browse/WFCORE-13
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Labels: EAP
> Fix For: 3.0.0.Alpha25
>
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1351:
-------------------------------
Fix Version/s: 3.0.0.Alpha25
(was: 3.0.0.Alpha24)
> FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1351
> URL: https://issues.jboss.org/browse/WFCORE-1351
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting, Security
> Reporter: Ondrej Kotek
> Assignee: David Lloyd
> Priority: Critical
> Fix For: 3.0.0.Alpha25
>
> Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace
>
>
> # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like
> {noformat}
> ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager
> {noformat}
> results in exception:
> {noformat}
> java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> {noformat}
> To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_:
> {noformat}
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"),
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"),
> new RemotingPermission("createEndpoint"),
> new RuntimePermission("createXnioWorker"),
> new RemotingPermission("addConnectionProvider"),
> new RuntimePermission("modifyThread"),
> new RuntimePermission("accessDeclaredMembers"),
> new ReflectPermission("suppressAccessChecks")
> {noformat}
> which is very confusing.
> Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1282:
-------------------------------
Fix Version/s: 3.0.0.Alpha25
(was: 3.0.0.Alpha24)
> Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-1282
> URL: https://issues.jboss.org/browse/WFCORE-1282
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 1.0.2.Final
> Environment: Oracle Java
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 3.0.0.Alpha25
>
> Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log
>
>
> User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7.
> Setting as critical as these cipher suites, are considered for strong and widely used in my opinion.
> In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all.
> Note, that analogous configuration in EAP6 works fine.
> Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites().
> Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1145:
-------------------------------
Fix Version/s: 3.0.0.Alpha25
(was: 3.0.0.Alpha24)
> Review of HostController / Application Server Remoting connections
> ------------------------------------------------------------------
>
> Key: WFCORE-1145
> URL: https://issues.jboss.org/browse/WFCORE-1145
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha25
>
>
> Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access.
> The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months