[JBoss JIRA] (WFCORE-328) Provide deployment manifest information via the CLI
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-328?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-1086 to WFCORE-328:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-328 (was: WFLY-1086)
Component/s: CLI
Domain Management
(was: CLI)
(was: Domain Management)
> Provide deployment manifest information via the CLI
> ---------------------------------------------------
>
> Key: WFCORE-328
> URL: https://issues.jboss.org/browse/WFCORE-328
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Reporter: Brian Stansberry
> Priority: Critical
>
> We've gotten a user request for providing the contents of a deployment's MANIFEST.MF via the CLI.
> The request is to include an option to get the manifest info for a single deployment, and also the info for all deployments.
> This task needs to be evaluated in relationship to the larger request to provide read (and possibly in some cases write) access to all files within a deployment. The manifest is essentially just one file with a standard location.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 6 months
[JBoss JIRA] (WFCORE-329) Allow duplication of configuration parts via management API
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-329?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-1106 to WFCORE-329:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-329 (was: WFLY-1106)
Component/s: Domain Management
(was: Domain Management)
> Allow duplication of configuration parts via management API
> -----------------------------------------------------------
>
> Key: WFCORE-329
> URL: https://issues.jboss.org/browse/WFCORE-329
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Alex Ont
> Assignee: Brian Stansberry
>
> Allow the possibility to read part of the configuration via management API, modify it and add it back under a new id, without knowing the specific details of the resource.
> This would allow for example adding a new server group configured exactly as an existing, creating a new resource (datasource, etc.) based on an existing one or even creating a profile based on a given one.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 6 months
[JBoss JIRA] (WFCORE-324) Resolve startup dependency between master hostController and slave hostControllers.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-324?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-1184 to WFCORE-324:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-324 (was: WFLY-1184)
Component/s: Domain Management
(was: Domain Management)
> 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
>
> *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.3.8#6338)
9 years, 6 months
[JBoss JIRA] (WFCORE-325) Allow socket-binding-group-refType to override default-interface
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-325?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-1148 to WFCORE-325:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-325 (was: WFLY-1148)
Component/s: Domain Management
(was: Domain Management)
> Allow socket-binding-group-refType to override default-interface
> ----------------------------------------------------------------
>
> Key: WFCORE-325
> URL: https://issues.jboss.org/browse/WFCORE-325
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Todd Trimmer
> Priority: Optional
> Labels: configuration, domain, host-controller
>
> I want all the host controllers in my domain to use the same socket-binding-group. However, each host controller can have multiple servers, each with its own IP, but each IP still reuses the same port number (yet still a unique IP+port combo). The problem is that the socket-binding-group-refType will not let me override the @default-interface value from the referent socket-binding-group. I am forced to create a second, equally verbose, socket-binding-group exactly like the first group in every way, except for the @default-interface. I wish to avoid this. My particular scenario cannot rely on @port-offset because my hardware load-balancer needs all nodes in the same pool to use the same ports.
> Under my proposal, the host.xml could thus more easily be written like this:
> ...
> <interfaces>
> <interface name="public">
> <inet-address value="10.10.10.1" />
> </interface>
> <interface name="public-two">
> <inet-address value="10.10.10.2" />
> </interface>
> </interfaces>
> ...
> <servers>
> <server name="server-one" group="prod-server-group" auto-start="true">
> <jvm name="jvm6g" />
> </server>
> <server name="server-two" group="prod-server-group" auto-start="false">
> <jvm name="jvm2g" />
> <socket-binding-group ref="standard-sockets" default-interface="public-two" />
> </server>
> </servers>
> ...
> This alleviates the burden of having to define a second socket-binding-group in domain.xml and maintaining the same set of socket-binding definitions in two places.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 6 months
[JBoss JIRA] (WFCORE-321) Spurious server dirs created when directory-grouping="by-type" is set
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-321?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-89 to WFCORE-321:
---------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-321 (was: WFLY-89)
Component/s: Domain Management
(was: Domain Management)
> Spurious server dirs created when directory-grouping="by-type" is set
> ---------------------------------------------------------------------
>
> Key: WFCORE-321
> URL: https://issues.jboss.org/browse/WFCORE-321
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: James Perkins
> Priority: Minor
>
> Add directory-grouping="by-type" to the <host><servers> element in the stock host.xml and run domain.sh. The following empty directories are created:
> $JBOSS_HOME/domain/servers/server-one
> $JBOSS_HOME/domain/servers/server-two
> The content that would normally be in those dirs if directory-grouping="by-type" wasn't set appears to all be going where it should (e.g. under domain/data, domain/log etc) so the only issue here is the empty directories.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 6 months
[JBoss JIRA] (WFCORE-322) Allow restart of management interface services via allow-resource-restart header
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-322?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-2254 to WFCORE-322:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-322 (was: WFLY-2254)
Component/s: Domain Management
(was: Domain Management)
> Allow restart of management interface services via allow-resource-restart header
> --------------------------------------------------------------------------------
>
> Key: WFCORE-322
> URL: https://issues.jboss.org/browse/WFCORE-322
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Priority: Minor
>
> The management interface resources seem like good candidates for allow-resource-restart handling. A restart of the services should not propagate through a broad range of dependent services, while an admin could quite reasonably want to update these without taking a server outage.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 6 months
[JBoss JIRA] (WFCORE-323) Validate composite operation steps just before executing them
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-323?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-1019 to WFCORE-323:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-323 (was: WFLY-1019)
Component/s: Domain Management
(was: Domain Management)
> Validate composite operation steps just before executing them
> -------------------------------------------------------------
>
> Key: WFCORE-323
> URL: https://issues.jboss.org/browse/WFCORE-323
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Labels: EAP
>
> Say we have a composite operation with 2 steps:
> 1) /extension=org.jboss.as.messaging:add
> 2) /subsystem=messaging:add
> This will fail:
> Failed to execute batch: JBAS014739: No handler for add at address
> [("subsystem" => "messaging")]
> This fails because at the time of validation the /subsystem=messaging:add is not valid.
> To illustrate, the execution order is
> Validate 1-2
> 1
> 2
> A possible solution is to convert this to the following:
> V1
> 1
> V2 (works now because 1 has registered the subsystem API)
> 2
> I think that should work but it's a very complex area, particularly in a managed domain, so it's not at all certain this would prove feasible.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 6 months
[JBoss JIRA] (WFCORE-317) Failed to start server when -backup -cached-dc are used together
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-317?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-773 to WFCORE-317:
----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-317 (was: WFLY-773)
Component/s: Domain Management
(was: Domain Management)
> 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
> Reporter: Rok Bertoncelj
>
> 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.3.8#6338)
9 years, 6 months
[JBoss JIRA] (WFCORE-318) module.xml schema checking should log errors when it encounters them
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-318?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-832 to WFCORE-318:
----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-318 (was: WFLY-832)
Component/s: Domain Management
(was: Domain Management)
> module.xml schema checking should log errors when it encounters them
> ---------------------------------------------------------------------
>
> Key: WFCORE-318
> URL: https://issues.jboss.org/browse/WFCORE-318
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Tom Fonteyne
> Assignee: Brian Stansberry
> Priority: Minor
>
> When defining a JDBC driver, we made a syntax error in the module.xml
> <resources>
> <resource-root path="driver.jar"/>
> </resoruces>
> Note the misspelled closing tag "</resoruces>"
> The driver did not get loaded (logically) but no error message was logged in server.log about this
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 6 months