[JBoss JIRA] (WFCORE-2857) Usage of wildfly.sasl.local-user.default-user in core configuration files
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2857?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2857:
-------------------------------------
Fix Version/s: 4.0.0.Alpha1
(was: 3.0.0.CR1)
> Usage of wildfly.sasl.local-user.default-user in core configuration files
> -------------------------------------------------------------------------
>
> Key: WFCORE-2857
> URL: https://issues.jboss.org/browse/WFCORE-2857
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Test Suite
> Reporter: Ken Wills
> Assignee: Ken Wills
> Fix For: 4.0.0.Alpha1
>
>
> The property wildfly.sasl.local-user.default-user is present in some, commented out on other, and absent from some default configuation files in core. (the default host-slave.xml for example has it, but it appears to have no effect if removed). There is uneven usage of it throughout the testsuite config files.
> We should review and make the usage (or non-usage) consistent.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-1307) jboss-cli returns success when WFLYCTL0009: Failed to store configuration occurred
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1307?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1307:
-------------------------------------
Fix Version/s: 4.0.0.Alpha1
(was: 3.0.0.CR1)
> jboss-cli returns success when WFLYCTL0009: Failed to store configuration occurred
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-1307
> URL: https://issues.jboss.org/browse/WFCORE-1307
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.7.Final
> Reporter: Brad Maxwell
> Assignee: Ken Wills
> Fix For: 4.0.0.Alpha1
>
>
> If the server is started, and a cli call is made that fails to persist to the standalone.xml returns success even though it failed.
> Start the server.
> Simple way to reproduce is to change the permissions on the configuration directory then run some cli commands such as shown below:
> {code}
> $ ./bin/jboss-cli.sh -c
> [standalone@localhost:9990 /] /system-property=foo1:add(value=bar1)
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=ejb3:write-attribute(name=enable-statistics,value=true)
> {"outcome" => "success"}
> {code}
> {code}
> 19:53:17,823 ERROR [stderr] (management-handler-thread - 1) java.nio.file.AccessDeniedException: /tmp/wildfly-10.0.0.CR5/standalone/configuration/standalone.xml.tmp
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at java.nio.file.Files.newByteChannel(Files.java:361)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at java.nio.file.Files.createFile(Files.java:632)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:125)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at java.security.AccessController.doPrivileged(Native Method)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at javax.security.auth.Subject.doAs(Subject.java:422)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 19:53:17,831 ERROR [stderr] (management-handler-thread - 1) at java.lang.Thread.run(Thread.java:745)
> 19:53:17,831 ERROR [stderr] (management-handler-thread - 1) at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 19:53:17,831 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0009: Failed to store configuration to standalone.xml: java.nio.file.AccessDeniedException: /tmp/wildfly-10.0.0.CR5/standalone/configuration/standalone.xml.tmp
> at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
> at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
> at java.nio.file.Files.deleteIfExists(Files.java:1165)
> at java.nio.file.Files.copy(Files.java:3004)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:109)
> at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-887) "Deprecate" using an expression in model refs to interfaces
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-887:
------------------------------------
Fix Version/s: 4.0.0.Alpha1
(was: 3.0.0.Beta29)
> "Deprecate" using an expression in model refs to interfaces
> -----------------------------------------------------------
>
> Key: WFCORE-887
> URL: https://issues.jboss.org/browse/WFCORE-887
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 4.0.0.Alpha1
>
>
> SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions.
> Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1.
> There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support.
> We should look for other cases like this too, although those changes should be separate JIRAs.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-2968) Servers in a domain won't boot if local auth is disabled on the host controller
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2968?page=com.atlassian.jira.plugi... ]
Brian Stansberry reopened WFCORE-2968:
--------------------------------------
Although this should work now I'm reopening as there's still some ongoing stuff related to this.
> Servers in a domain won't boot if local auth is disabled on the host controller
> -------------------------------------------------------------------------------
>
> Key: WFCORE-2968
> URL: https://issues.jboss.org/browse/WFCORE-2968
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: James Perkins
> Assignee: Ken Wills
> Priority: Blocker
> Fix For: 3.0.0.Beta29
>
>
> If local authentication has been disabled on the host controller servers cannot communicate with the host controller and fail to start.
> {code}
> [Server:server-one] 15:10:51,241 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 2) MSC000001: Failed to start service jboss.server-boot-operations: org.jboss.msc.service.StartException in service jboss.server-boot-operations: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://127.0.0.1:9990. The connection failed
> [Server:server-one] at org.jboss.as.server.mgmt.domain.ServerBootOperationsService$1.run(ServerBootOperationsService.java:72)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:server-one] at java.lang.Thread.run(Thread.java:748)
> [Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [Server:server-one] Caused by: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://127.0.0.1:9990. The connection failed
> [Server:server-one] at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:126)
> [Server:server-one] at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259)
> [Server:server-one] at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> [Server:server-one] at org.jboss.as.server.mgmt.domain.HostControllerConnection.openConnection(HostControllerConnection.java:128)
> [Server:server-one] at org.jboss.as.server.mgmt.domain.HostControllerClient.resolveBootUpdates(HostControllerClient.java:110)
> [Server:server-one] at org.jboss.as.server.mgmt.domain.ServerBootOperationsService$1.run(ServerBootOperationsService.java:68)
> [Server:server-one] ... 4 more
> [Server:server-one] Caused by: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (DIGEST-MD5) are supported
> [Server:server-one] at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:438)
> [Server:server-one] at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:246)
> [Server:server-one] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> [Server:server-one] at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> [Server:server-one] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> [Server:server-one] at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> [Server:server-one] at ...asynchronous invocation...(Unknown Source)
> [Server:server-one] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:545)
> [Server:server-one] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:509)
> [Server:server-one] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:497)
> [Server:server-one] at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:194)
> [Server:server-one] at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:118)
> [Server:server-one] ... 9 more
> [Server:server-one]
> [Server:server-one] 15:10:51,241 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: java.util.concurrent.ExecutionException: Operation failed
> [Server:server-one] at org.jboss.as.server.ServerStartTask$2$1.load(ServerStartTask.java:188)
> [Server:server-one] at org.jboss.as.server.ServerService.boot(ServerService.java:387)
> [Server:server-one] at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:370)
> [Server:server-one] at java.lang.Thread.run(Thread.java:748)
> [Server:server-one] Caused by: java.util.concurrent.ExecutionException: Operation failed
> [Server:server-one] at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
> [Server:server-one] at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
> [Server:server-one] at org.jboss.as.server.mgmt.domain.ServerBootOperationsService$2.get(ServerBootOperationsService.java:113)
> [Server:server-one] at org.jboss.as.server.mgmt.domain.ServerBootOperationsService$2.get(ServerBootOperationsService.java:95)
> [Server:server-one] at org.jboss.as.server.ServerStartTask$2$1.load(ServerStartTask.java:185)
> [Server:server-one] ... 3 more
> [Server:server-one] Caused by: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://127.0.0.1:9990. The connection failed
> [Server:server-one] at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:126)
> [Server:server-one] at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259)
> [Server:server-one] at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> [Server:server-one] at org.jboss.as.server.mgmt.domain.HostControllerConnection.openConnection(HostControllerConnection.java:128)
> [Server:server-one] at org.jboss.as.server.mgmt.domain.HostControllerClient.resolveBootUpdates(HostControllerClient.java:110)
> [Server:server-one] at org.jboss.as.server.mgmt.domain.ServerBootOperationsService$1.run(ServerBootOperationsService.java:68)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:server-one] at java.lang.Thread.run(Thread.java:748)
> [Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [Server:server-one] Caused by: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (DIGEST-MD5) are supported
> [Server:server-one] at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:438)
> [Server:server-one] at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:246)
> [Server:server-one] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> [Server:server-one] at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> [Server:server-one] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> [Server:server-one] at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> [Server:server-one] at ...asynchronous invocation...(Unknown Source)
> [Server:server-one] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:545)
> [Server:server-one] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:509)
> [Server:server-one] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:497)
> [Server:server-one] at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:194)
> [Server:server-one] at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:118)
> [Server:server-one] ... 9 more
> [Server:server-one]
> [Server:server-one] 15:10:51,243 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> [Server:server-one] 15:10:51,254 INFO [org.jboss.as] (MSC service thread 1-8) WFLYSRV0050: WildFly Core 3.0.0.Beta27-SNAPSHOT "Kenny" stopped in 6ms
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1649:
-------------------------------------
Fix Version/s: 4.0.0.Alpha1
(was: 3.0.0.Beta29)
I've changed my mind and am rescheduling this back to core 4. We have transformers in place for the new elytron sensitivity classifications, and the WFCORE-3107 subtask is not critical.
> RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1649
> URL: https://issues.jboss.org/browse/WFCORE-1649
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Labels: domain-mode
> Fix For: 4.0.0.Alpha1
>
>
> The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems.
> This is a big problem in the following scenarios:
> 1) Mixed domain, where legacy slaves do not know about newly introduced classifications.
> 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present.
> A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But:
> -- that doesn't help with problem 2)
> -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-2402) Required attributes of elytron key-store creation add operation
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2402?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2402:
------------------------------------------
[~dlofthouse] Should this be closed like the downstream JBEAP-6034 is?
> Required attributes of elytron key-store creation add operation
> ---------------------------------------------------------------
>
> Key: WFCORE-2402
> URL: https://issues.jboss.org/browse/WFCORE-2402
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta7
> Reporter: Martin Choma
> Assignee: ehsavoie Hugonnet
> Priority: Critical
> Labels: user_experience
> Fix For: 4.0.0.Alpha1
>
>
> Minimal CLI command to create key store is
> {code}
> /subsystem=elytron/key-store=server:add(type="JKS")
> {code}
> But it has these problems:
> * Password attribute has to be required. I can't think of case when that could be ommited.
> * Attribute {{type}} could be optional. If not set default value can be Keystore.getDefaultType(). As model cant't express this, it can be documented in description.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months