[JBoss JIRA] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly
by Aleksandar Kostadinov (JIRA)
[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ]
Aleksandar Kostadinov commented on WFCORE-433:
----------------------------------------------
[~brian.stansberry], storing diffs as CLI scripts sounds awesome as long as console can generate them and duplication of changes is removed. e.g. first set listen port to 445 and then change to 443. The first rule is then useless as it will be overridden by the second.
On the other hand journal-like diff also makes sense and being easier to implement is IMO good enough for most user stories.
> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
> Key: WFCORE-433
> URL: https://issues.jboss.org/browse/WFCORE-433
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Strachan
> Assignee: Jason Greene
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (WFCORE-324) Resolve startup dependency between master hostController and slave hostControllers.
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-324?page=com.atlassian.jira.plugin... ]
Ken Wills updated WFCORE-324:
-----------------------------
Fix Version/s: 3.0.0.Alpha4
> Resolve startup dependency between master hostController and slave hostControllers.
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-324
> URL: https://issues.jboss.org/browse/WFCORE-324
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: karin k
> Assignee: Ken Wills
> Fix For: 3.0.0.Alpha4
>
>
> *Current situation:*
> * The slave hostController can be started using option --cached-dc
> Result: the slave hostContoller will be started given that a local copy of the domain.xml (exact name domain.cached-remote.xml
> ) is available (created by a startup using -backup and an available master hostController)
> The slave hostController will never register itself towards the master domain hostController (regardless of whether the master domain controller is running during startup or will be started afterwards)
> * The slave hostController can be started without any option
> If the master hostController is not running during startup of the slave, the startup of the slave will fail.
> * The slave hostController can be started with option -backup
> If the master hostController is not running during startup of the slave, the startup of the slave will fail.
> If the master hostController is running, the slave will store a copy of the domain.xml locally.
> A successful startup of the whole domain is only possible when the hostControllers are started in the correct sequence (master hostController must be available when slave host Controllers are trying to register). From my point of view a successful startup means that all hostControllers can start successfully and additionally it is possible to manage the slave hostController by means of the master hostController.
> *Requirement*
> To let a JBoss domain act and started in the correct way (meaning central management is possible) the following should be fullfilled
> * If the master hostController is not running, the slave should still be able to start and work with its local copy of the domain.xml
> * If the master hostController is started after the slave hostController, the slave host controller should still be able to start successfully but should in parallel recognize when the master hostController is finally available and register itself
> * There should be the possiblity to store a local copy of the domain master hostController in parallel with the approach of starting up when the master hostController is not running (in this case the master domain.xml cannot be stored locally but anyway startup is possible).
> (see also https://issues.jboss.org/browse/AS7-4281)
> Regards
> Karin
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (WFCORE-317) Failed to start server when -backup -cached-dc are used together
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-317?page=com.atlassian.jira.plugin... ]
Ken Wills updated WFCORE-317:
-----------------------------
Fix Version/s: 3.0.0.Alpha4
> Failed to start server when -backup -cached-dc are used together
> ----------------------------------------------------------------
>
> Key: WFCORE-317
> URL: https://issues.jboss.org/browse/WFCORE-317
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha4
> Reporter: Rok Bertoncelj
> Assignee: Ken Wills
> Fix For: 3.0.0.Alpha4
>
>
> When starting a slave host controller with *-backup -cached-dc* at the same time, the servers fail to start. Tested with 7.1.1.Final and 7.1.2.Final-SNAPSHOT today.
> Also tried starting only with -backup first (starts OK) and then for the second time with both options, to make sure that cached configuration is already present if it would help, but it didn't.
> Host controller should determine availability of domain controller and either backup domain configuration or use the cached one if domain controller is unavailable.
> {code}
> 10:35:36,093 INFO [org.jboss.modules] (main) JBoss Modules version 1.1.1.GA
> 10:35:36,176 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.2.GA
> 10:35:36,225 INFO [org.jboss.as] (MSC service thread 1-3) JBAS015899: JBoss AS 7.1.2.Final-SNAPSHOT "Brontes" starting
> 10:35:36,612 WARN [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010930: Cannot load the domain model using using --backup
> 10:35:36,617 INFO [org.xnio] (MSC service thread 1-6) XNIO Version 3.0.3.GA
> 10:35:36,631 INFO [org.xnio.nio] (MSC service thread 1-6) XNIO NIO Implementation Version 3.0.3.GA
> 10:35:36,649 INFO [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version 3.2.4.GA
> 10:35:36,970 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010907: Failed to start server (server-one): java.util.NoSuchElementException: No child 'server-group' exists
> at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:362) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.dmr.ObjectModelValue.requireChild(ObjectModelValue.java:298) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.dmr.ModelNode.require(ModelNode.java:812) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.host.controller.ModelCombiner.<init>(ModelCombiner.java:139) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.ServerInventoryImpl.createManagedServer(ServerInventoryImpl.java:474) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:160) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:150) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.startServer(DomainModelControllerService.java:521) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.operations.StartServersHandler.cleanStartServers(StartServersHandler.java:114) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.operations.StartServersHandler.access$300(StartServersHandler.java:50) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.operations.StartServersHandler$1.execute(StartServersHandler.java:94) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.executeDirect(PrepareStepHandler.java:122) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.execute(PrepareStepHandler.java:74) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:121) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.startServers(DomainModelControllerService.java:443) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:403) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:155) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> 10:35:36,989 INFO [org.jboss.as.remoting] (MSC service thread 1-8) JBAS017100: Listening on /127.0.0.1:29999
> 10:35:37,015 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010907: Failed to start server (server-two): java.util.NoSuchElementException: No child 'server-group' exists
> at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:362) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.dmr.ObjectModelValue.requireChild(ObjectModelValue.java:298) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.dmr.ModelNode.require(ModelNode.java:812) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.host.controller.ModelCombiner.<init>(ModelCombiner.java:139) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.ServerInventoryImpl.createManagedServer(ServerInventoryImpl.java:474) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:160) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:150) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.startServer(DomainModelControllerService.java:521) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.operations.StartServersHandler.cleanStartServers(StartServersHandler.java:114) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.operations.StartServersHandler.access$300(StartServersHandler.java:50) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.operations.StartServersHandler$1.execute(StartServersHandler.java:94) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.executeDirect(PrepareStepHandler.java:122) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.execute(PrepareStepHandler.java:74) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:121) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.startServers(DomainModelControllerService.java:443) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:403) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:155) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> 10:35:37,082 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.1.2.Final-SNAPSHOT "Brontes" (Host Controller) started in 1249ms - Started 11 of 11 services (0 services are passive or on-demand)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (WFCORE-317) Failed to start server when -backup -cached-dc are used together
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-317?page=com.atlassian.jira.plugin... ]
Ken Wills updated WFCORE-317:
-----------------------------
Affects Version/s: 3.0.0.Alpha4
> Failed to start server when -backup -cached-dc are used together
> ----------------------------------------------------------------
>
> Key: WFCORE-317
> URL: https://issues.jboss.org/browse/WFCORE-317
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha4
> Reporter: Rok Bertoncelj
> Assignee: Ken Wills
> Fix For: 3.0.0.Alpha4
>
>
> When starting a slave host controller with *-backup -cached-dc* at the same time, the servers fail to start. Tested with 7.1.1.Final and 7.1.2.Final-SNAPSHOT today.
> Also tried starting only with -backup first (starts OK) and then for the second time with both options, to make sure that cached configuration is already present if it would help, but it didn't.
> Host controller should determine availability of domain controller and either backup domain configuration or use the cached one if domain controller is unavailable.
> {code}
> 10:35:36,093 INFO [org.jboss.modules] (main) JBoss Modules version 1.1.1.GA
> 10:35:36,176 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.2.GA
> 10:35:36,225 INFO [org.jboss.as] (MSC service thread 1-3) JBAS015899: JBoss AS 7.1.2.Final-SNAPSHOT "Brontes" starting
> 10:35:36,612 WARN [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010930: Cannot load the domain model using using --backup
> 10:35:36,617 INFO [org.xnio] (MSC service thread 1-6) XNIO Version 3.0.3.GA
> 10:35:36,631 INFO [org.xnio.nio] (MSC service thread 1-6) XNIO NIO Implementation Version 3.0.3.GA
> 10:35:36,649 INFO [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version 3.2.4.GA
> 10:35:36,970 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010907: Failed to start server (server-one): java.util.NoSuchElementException: No child 'server-group' exists
> at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:362) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.dmr.ObjectModelValue.requireChild(ObjectModelValue.java:298) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.dmr.ModelNode.require(ModelNode.java:812) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.host.controller.ModelCombiner.<init>(ModelCombiner.java:139) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.ServerInventoryImpl.createManagedServer(ServerInventoryImpl.java:474) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:160) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:150) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.startServer(DomainModelControllerService.java:521) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.operations.StartServersHandler.cleanStartServers(StartServersHandler.java:114) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.operations.StartServersHandler.access$300(StartServersHandler.java:50) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.operations.StartServersHandler$1.execute(StartServersHandler.java:94) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.executeDirect(PrepareStepHandler.java:122) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.execute(PrepareStepHandler.java:74) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:121) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.startServers(DomainModelControllerService.java:443) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:403) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:155) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> 10:35:36,989 INFO [org.jboss.as.remoting] (MSC service thread 1-8) JBAS017100: Listening on /127.0.0.1:29999
> 10:35:37,015 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010907: Failed to start server (server-two): java.util.NoSuchElementException: No child 'server-group' exists
> at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:362) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.dmr.ObjectModelValue.requireChild(ObjectModelValue.java:298) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.dmr.ModelNode.require(ModelNode.java:812) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.host.controller.ModelCombiner.<init>(ModelCombiner.java:139) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.ServerInventoryImpl.createManagedServer(ServerInventoryImpl.java:474) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:160) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:150) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.startServer(DomainModelControllerService.java:521) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.operations.StartServersHandler.cleanStartServers(StartServersHandler.java:114) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.operations.StartServersHandler.access$300(StartServersHandler.java:50) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.operations.StartServersHandler$1.execute(StartServersHandler.java:94) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.executeDirect(PrepareStepHandler.java:122) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.execute(PrepareStepHandler.java:74) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:121) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.startServers(DomainModelControllerService.java:443) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:403) [jboss-as-host-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:155) [jboss-as-controller-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> 10:35:37,082 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.1.2.Final-SNAPSHOT "Brontes" (Host Controller) started in 1249ms - Started 11 of 11 services (0 services are passive or on-demand)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (DROOLS-477) KieScanner is not working as expected
by Matthew Morrissette (JIRA)
[ https://issues.jboss.org/browse/DROOLS-477?page=com.atlassian.jira.plugin... ]
Matthew Morrissette commented on DROOLS-477:
--------------------------------------------
Matteo:
I think I may have discovered your issue.
Firstly, if you want the KIE Scanner to detect an update to a specific version, it MUST contain "-SNAPSHOT" in the version and you also must update your maven settings.xml for the KIE repository and add the element:
<snapshots>
<updatePolicy>always</updatePolicy>
</snapshots>
If you do that, you should be able to use the "LATEST" version placeholder and ensure the latest snapshot update is reflected.
> KieScanner is not working as expected
> -------------------------------------
>
> Key: DROOLS-477
> URL: https://issues.jboss.org/browse/DROOLS-477
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.0.1.Final
> Environment: Windows 7
> Reporter: Alexander Pykhtin
> Assignee: Mario Fusco
> Fix For: 6.1.0.Beta4
>
> Attachments: drools_jar.zip, drools_sample.zip
>
>
> KieScanner is not dynamically updates the rules in a sample application.
> drools_sample is a parent project, drools_jar is its dependency that is expected to be dynamically updated.
> Here is the sample code:
> Scanner scanner = new Scanner(System.in);
> try {
> KieServices ks = KieServices.Factory.get();
> ReleaseId releaseId = ks.newReleaseId( "com.study", "drools_sample", "0.0.1-SNAPSHOT" );
> KieContainer kContainer = ks.newKieContainer( releaseId );
> KieSession kSession = null;
> KieScanner kScanner = ks.newKieScanner( kContainer );
> boolean repeat = true;
> // go !
> while(repeat)
> {
> kSession = kContainer.newKieSession("ksession-rules_jar");
> Message message = new Message();
> message.setMessage("Hello World");
> message.setStatus(Message.HELLO);
> DynamicFactType dft = new DynamicFactType();
> kSession.insert(message);
> kSession.insert(dft);
> kSession.fireAllRules();
> kSession.dispose();
> String inp = scanner.nextLine();
> if(inp.length() > 0)
> repeat = false;
> else
> {
> kScanner.scanNow();
> }
> }
> } catch (Throwable t) {
> t.printStackTrace();
> }
> scanner.close();
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-433:
-----------------------------------------
That sounds like applying CLI scripts to me.
Our xml formats are not stable API.
> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
> Key: WFCORE-433
> URL: https://issues.jboss.org/browse/WFCORE-433
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Strachan
> Assignee: Jason Greene
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly
by Aleksandar Kostadinov (JIRA)
[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ]
Aleksandar Kostadinov commented on WFCORE-433:
----------------------------------------------
One thing I'd like to suggest, is to make Wildfly able to store configuration in some human readable diff-like approach. That means we have a single file that denotes all configuration changes from the default configuration file and the only place for user to look for what is different than the defaults. This could make upgrading server and changing default values smoother for the users.
Also could make auditing, creating test deployments, etc. much easier.
Storing the file in a git repo will also make much more sense.
> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
> Key: WFCORE-433
> URL: https://issues.jboss.org/browse/WFCORE-433
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Strachan
> Assignee: Jason Greene
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (JASSIST-256) Javassist - add annotation to class doesn't work on reflections
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-256?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-256:
---------------------------------------
Yes, but the version including this fixing has not been released yet.
> Javassist - add annotation to class doesn't work on reflections
> ---------------------------------------------------------------
>
> Key: JASSIST-256
> URL: https://issues.jboss.org/browse/JASSIST-256
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: JDK1.7, IDEA
> Reporter: Rui C.
> Assignee: Shigeru Chiba
> Priority: Minor
> Fix For: 3.21.0-GA
>
>
> {code:java}
> ClassPool pool = ClassPool.getDefault();
> CtClass superclass = pool.getCtClass(AbstractEntity.class.getName());
> CtClass cc = pool.makeClass("com.rapid.develop.entity.Ponit", superclass);
> ClassFile ccFile = cc.getClassFile();
> ConstPool constpool = ccFile.getConstPool();
> AnnotationsAttribute attr = new AnnotationsAttribute(constpool, AnnotationsAttribute.visibleTag);
> Annotation entityAnno = new Annotation("Entity", constpool);
> Annotation tableAnno = new Annotation("Table", constpool);
> tableAnno.addMemberValue("name", new StringMemberValue("test", ccFile.getConstPool()));
> attr.addAnnotation(entityAnno);
> attr.addAnnotation(tableAnno);
> ccFile.addAttribute(attr);
> Class clazz = cc.toClass();
> Object o = clazz.newInstance();
> assertTrue(o.getClass().getName().equals("com.rapid.develop.entity.Ponit"));
> // annotations length = zero
> java.lang.annotation.Annotation[] annotations = clazz.getDeclaredAnnotations();
> assertEquals(2, annotations.length);
> {code}
> I used javassist to add annotation for class， I saw these annotations were added to class file.
> But I can't get them using java API clazz.getDeclaredAnnotations() and clazz.getAnnotations()
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (WFLY-6884) Add XSD schema testing for clustering subsystems
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-6884:
------------------------------------
Summary: Add XSD schema testing for clustering subsystems
Key: WFLY-6884
URL: https://issues.jboss.org/browse/WFLY-6884
Project: WildFly
Issue Type: Feature Request
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Radoslav Husar
Assignee: Radoslav Husar
I noticed a huge batch of ignored tests in clustering subsystems, the missing bits and pieces that allow for XSD testing were missing in infinispan, jgroups and singleton subsystems.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months