[JBoss JIRA] (WFCORE-1806) Split DomainModelControllerService into separate services for initializing as a master versus as a slave
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1806?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1806:
-------------------------------------
Fix Version/s: (was: 4.0.0.Beta2)
> Split DomainModelControllerService into separate services for initializing as a master versus as a slave
> --------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1806
> URL: https://issues.jboss.org/browse/WFCORE-1806
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Labels: domain-mode
>
> This is an aspect of WFCORE-338, although it's valid in its own right as a conceptually cleaner approach to host controller boot.
> Using different services is a prerequisite to WFCORE-338 as it allows those elements of HC behavior to be started/stopped as a DC candidate is elected or unelected. It also makes it feasible to wire in the service that performs the election.
> The method that installs the service with MSC will return a Future<Boolean>, with the service setting the future's value at the completion of start(). DMCS during boot can block reading the future, from that confirm that the service completed successfully, and then proceed with the rest of boot. The boolean is basically an ok/not ok signal.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-456) Add a content-stream attribute to the root deployment=* resources
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-456?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-456:
------------------------------------
Fix Version/s: (was: 4.0.0.Beta2)
> Add a content-stream attribute to the root deployment=* resources
> -----------------------------------------------------------------
>
> Key: WFCORE-456
> URL: https://issues.jboss.org/browse/WFCORE-456
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
>
> Add a new attribute to the deployment resource that allows the user to get a stream with the deployment content attached to the response, a la what we do with the subsystem=logging/log-file=* resource's "stream" attribute.
> The attribute must be configured as runtime-only and read-only.
> The read handler that handles the attribute should only attach a stream if the following conditions are met, otherwise the value for the attribute should remain as 'undefined'.
> 1) The resource's "content" attribute has only a single element in the list. (This is always the case today; adding a check for this is just future proofing)
> 2) The first element in the "content" attribute list has a defined value in its "hash" field. (This confirms the content is stored in the content repo. We won't support serving unmanaged content as we have insufficient control over it.)
> 3) The first element in the "content" attribute list has a 'true' as value of its "archive" field. (Current this will always be the case; this is future proofing for when we add support for exploded content in the content repo. Trying to assemble a stream from exploded content is currently out of scope for this feature.)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-2830) Split testsuite/shared to distinguish things meant for sharing within the core testsuite from things usable in other projects
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2830?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2830:
-------------------------------------
Fix Version/s: (was: 4.0.0.Beta2)
> Split testsuite/shared to distinguish things meant for sharing within the core testsuite from things usable in other projects
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2830
> URL: https://issues.jboss.org/browse/WFCORE-2830
> Project: WildFly Core
> Issue Type: Task
> Components: Test Suite
> Reporter: Brian Stansberry
>
> The testsuite/shared module includes two conceptually different types of code:
> 1) Things that are meant to be usable across different modules in core's own testsuite.
> 2) Things that we are willing to support for use in other projects that rely on WildFly Core.
> Since the two things are mixed, we are essentially supporting externally things that are not intended for use outside core. And it makes it difficult to evaluate new additions to testsuite/shared, to see whether the addition is really relevant to core and to see whether proposed external use is something we want.
> The purpose of WildFly Core is not to be a provider of testsuite utilities. For anything we expose for external use, there should be a substantial code maintenance benefit that comes from sharing it, something beyond avoiding code duplication.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-583) Think about interactive slave domain controller registration.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-583?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-583:
------------------------------------
Fix Version/s: (was: 4.0.0.Beta2)
> Think about interactive slave domain controller registration.
> -------------------------------------------------------------
>
> Key: WFCORE-583
> URL: https://issues.jboss.org/browse/WFCORE-583
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: domain-mode
>
> We can never eliminate pre-defined installations but we could potentially offer a capability to make it easier to register a slave with it's master and enable TLS with client-cert based authentication for the slave.
> As an example if you have a master running with TLS enabled and it's own CA certificate the following flow could be possible.
> - Start slave domain controller disconnected.
> - Start CLI and connect to slave using local auth.
> - Execute join-domain(hostname, port)
> At this point a message is displayed asking if the masters cert is trusted, an opportunity to check the fingerprints - if accepted the master's cert goes into the slave's trust store.
> Next we use a proxied authentication so the administrator sitting in front of slave can enter their credentials to authenticate against master.
> The slave process generates a public and private key and with interaction with the administrator a certificate signing request.
> The certificate signing request is passed to master over the previously established TLS connection, master signs it and passes it back to the slave.
> The slave populates it's local KeyStore with the two keys and the master signed certificate. Master may store something or it may rely on the fact it signed the cert and use CRLs instead.
> Slave can now disconnect, then reconnect using the key and trust stores populated in the above flow. Master will then verify it using whatever policy it is using, this could be trust all signed certs except the ones in the CRL or it could have also stored currently trusted certs.
> This may even be possible in a provisioned environment where the base config contains enough information to establish that first connection - in that case you may want to bundle master's cert to eliminate it's validation.
> Overall not planning this as a short term implementation but tracking here as the kind of advanced capability we could add with all of the building blocks from Elytron.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-2669) Deprecate setValidator method in builders for ListAttributeDefinition and MapAttributeDefinition
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2669?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2669:
-------------------------------------
Fix Version/s: (was: 4.0.0.Beta2)
Low priority; we're likely to redo the entire Extension API and deprecate this stuff entirely.
> Deprecate setValidator method in builders for ListAttributeDefinition and MapAttributeDefinition
> ------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2669
> URL: https://issues.jboss.org/browse/WFCORE-2669
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Priority: Minor
>
> Let's discuss before doing anything on this.
> For lists and maps, the builder call to setValidator is really a call to setElementValidator, with a call to set[List|Map]Validator being necessary if some special validation of the overall list/map is desired.
> We should deprecate setValidator to help emphasize to people that really setElementValidator is what is happening.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-1960) Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1960?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1960:
-------------------------------------
Fix Version/s: 5.0.0.Alpha1
(was: 4.0.0.Beta2)
> Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING
> --------------------------------------------------------------------
>
> Key: WFCORE-1960
> URL: https://issues.jboss.org/browse/WFCORE-1960
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
> Fix For: 5.0.0.Alpha1
>
> Attachments: rrd.txt
>
>
> A read-resource-description output of a standalone-full-ha.xml server (see attached) shows a couple attributes that are of type LIST, value-type PROPERTY. (Just text search for PROPERTY.) We should convert those to OBJECT, value-type STRING. Both represent a resource address. An object of string is equivalent to a LinkedHashMap<String, String>, with ordering based on insertion. So such a description is fine for a path address attribute.
> I'd like to get rid of the notion of PROPERTY in our spec definition of how to describe attributes, parameters and value-types (https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+...) so removing the only usage of it will help.
> We should still accept PROPERTY as inputs when we can do conversion to the defined type. This is all about tightening up the spec to remove the not-really-necessary PROPERTY concept.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 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: (was: 4.0.0.Beta2)
> 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
>
> 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.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-482?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFCORE-482:
------------------------------
Fix Version/s: 4.0.0.Beta2
(was: 4.0.0.Beta1)
> Add log4j2 support for WildFly
> ------------------------------
>
> Key: WFCORE-482
> URL: https://issues.jboss.org/browse/WFCORE-482
> Project: WildFly Core
> Issue Type: Task
> Components: Logging
> Environment: Spring 3, Hibernate, Wicket, JBoss AS7
> Reporter: Amarkanth Ranganamayna
> Assignee: James Perkins
> Priority: Optional
> Fix For: 4.0.0.Beta2
>
>
> I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2.
> Looks like Jboss AS7 by default use log4j 1.x
> Are you guys already working on using log4j2 ?
> If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging.
> Thanks,
> Amar
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-456) Add a content-stream attribute to the root deployment=* resources
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-456?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFCORE-456:
------------------------------
Fix Version/s: 4.0.0.Beta2
(was: 4.0.0.Beta1)
> Add a content-stream attribute to the root deployment=* resources
> -----------------------------------------------------------------
>
> Key: WFCORE-456
> URL: https://issues.jboss.org/browse/WFCORE-456
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 4.0.0.Beta2
>
>
> Add a new attribute to the deployment resource that allows the user to get a stream with the deployment content attached to the response, a la what we do with the subsystem=logging/log-file=* resource's "stream" attribute.
> The attribute must be configured as runtime-only and read-only.
> The read handler that handles the attribute should only attach a stream if the following conditions are met, otherwise the value for the attribute should remain as 'undefined'.
> 1) The resource's "content" attribute has only a single element in the list. (This is always the case today; adding a check for this is just future proofing)
> 2) The first element in the "content" attribute list has a defined value in its "hash" field. (This confirms the content is stored in the content repo. We won't support serving unmanaged content as we have insufficient control over it.)
> 3) The first element in the "content" attribute list has a 'true' as value of its "archive" field. (Current this will always be the case; this is future proofing for when we add support for exploded content in the content repo. Trying to assemble a stream from exploded content is currently out of scope for this feature.)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months