[JBoss JIRA] (WFCORE-1677) Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates cope with substitutions properly
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1677?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFCORE-1677:
-----------------------------------
Summary: Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates cope with substitutions properly (was: Make org.jboss.as.subsystem.test.AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates cope with substitutions)
> Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates cope with substitutions properly
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1677
> URL: https://issues.jboss.org/browse/WFCORE-1677
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 2.2.0.CR8
> Reporter: Radoslav Husar
> Assignee: Kabir Khan
> Priority: Minor
>
> It sounds to me that the test should really be validating the generated XML files, rather than the templates.
> {noformat}
> testSchemaOfSubsystemTemplates[8](org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase) Time elapsed: 0.052 sec <<< FAILURE!
> java.lang.AssertionError: error: cvc-complex-type.2.4.b: The content of element 'subsystem' is not complete. One of '{"urn:jboss:domain:infinispan:4.0":cache-container}' is expected.
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.subsystem.test.SchemaValidator$1.error(SchemaValidator.java:73)
> at org.apache.xerces.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:135)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:394)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:325)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:282)
> at org.apache.xerces.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:481)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3571)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidComplexType(XMLSchemaValidator.java:3508)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidType(XMLSchemaValidator.java:3434)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.processElementContent(XMLSchemaValidator.java:3336)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.handleEndElement(XMLSchemaValidator.java:2383)
> at org.apache.xerces.impl.xs.XMLSchemaValidator.endElement(XMLSchemaValidator.java:894)
> at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(XMLNSDocumentScannerImpl.java:673)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1645)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
> at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
> at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
> at org.apache.xerces.jaxp.validation.StreamValidatorHelper.validate(StreamValidatorHelper.java:186)
> at org.apache.xerces.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:129)
> at javax.xml.validation.Validator.validate(Validator.java:124)
> at org.jboss.as.subsystem.test.SchemaValidator.validateXML(SchemaValidator.java:123)
> at org.jboss.as.subsystem.test.SchemaValidator.validateXML(SchemaValidator.java:101)
> at org.jboss.as.subsystem.test.AbstractSubsystemBaseTest.testSchemaOfSubsystemTemplates(AbstractSubsystemBaseTest.java:144)
> at org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase.testSchemaOfSubsystemTemplates(SubsystemParsingTestCase.java:130)
> Results :
> Failed tests:
> SubsystemParsingTestCase.testSchemaOfSubsystemTemplates:130->AbstractSubsystemBaseTest.testSchemaOfSubsystemTemplates:144 error: cvc-complex-type.2.4.b: The content of element 'subsystem' is not complete. One of '{"urn:jboss:domain:infinispan:4.0":cache-container}' is expected.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFCORE-1677) Make org.jboss.as.subsystem.test.AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates cope with substitutions
by Radoslav Husar (JIRA)
Radoslav Husar created WFCORE-1677:
--------------------------------------
Summary: Make org.jboss.as.subsystem.test.AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates cope with substitutions
Key: WFCORE-1677
URL: https://issues.jboss.org/browse/WFCORE-1677
Project: WildFly Core
Issue Type: Feature Request
Components: Test Suite
Affects Versions: 2.2.0.CR8
Reporter: Radoslav Husar
Assignee: Kabir Khan
Priority: Minor
It sounds to me that the test should really be validating the generated XML files, rather than the templates.
{noformat}
testSchemaOfSubsystemTemplates[8](org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase) Time elapsed: 0.052 sec <<< FAILURE!
java.lang.AssertionError: error: cvc-complex-type.2.4.b: The content of element 'subsystem' is not complete. One of '{"urn:jboss:domain:infinispan:4.0":cache-container}' is expected.
at org.junit.Assert.fail(Assert.java:88)
at org.jboss.as.subsystem.test.SchemaValidator$1.error(SchemaValidator.java:73)
at org.apache.xerces.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:135)
at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:394)
at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:325)
at org.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:282)
at org.apache.xerces.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:481)
at org.apache.xerces.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3571)
at org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidComplexType(XMLSchemaValidator.java:3508)
at org.apache.xerces.impl.xs.XMLSchemaValidator.elementLocallyValidType(XMLSchemaValidator.java:3434)
at org.apache.xerces.impl.xs.XMLSchemaValidator.processElementContent(XMLSchemaValidator.java:3336)
at org.apache.xerces.impl.xs.XMLSchemaValidator.handleEndElement(XMLSchemaValidator.java:2383)
at org.apache.xerces.impl.xs.XMLSchemaValidator.endElement(XMLSchemaValidator.java:894)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(XMLNSDocumentScannerImpl.java:673)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1645)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
at org.apache.xerces.jaxp.validation.StreamValidatorHelper.validate(StreamValidatorHelper.java:186)
at org.apache.xerces.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:129)
at javax.xml.validation.Validator.validate(Validator.java:124)
at org.jboss.as.subsystem.test.SchemaValidator.validateXML(SchemaValidator.java:123)
at org.jboss.as.subsystem.test.SchemaValidator.validateXML(SchemaValidator.java:101)
at org.jboss.as.subsystem.test.AbstractSubsystemBaseTest.testSchemaOfSubsystemTemplates(AbstractSubsystemBaseTest.java:144)
at org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase.testSchemaOfSubsystemTemplates(SubsystemParsingTestCase.java:130)
Results :
Failed tests:
SubsystemParsingTestCase.testSchemaOfSubsystemTemplates:130->AbstractSubsystemBaseTest.testSchemaOfSubsystemTemplates:144 error: cvc-complex-type.2.4.b: The content of element 'subsystem' is not complete. One of '{"urn:jboss:domain:infinispan:4.0":cache-container}' is expected.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFCORE-1676) read-attribute --node is badly handled
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-1676:
--------------------------------------------
Summary: read-attribute --node is badly handled
Key: WFCORE-1676
URL: https://issues.jboss.org/browse/WFCORE-1676
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
read-attribute --node=interface=public namespaces should fail and fails
read-attribute namespaces --node=interface=public should fail and doesn't
read-attribute --node=interface=public init-address should succeed and succeeds
read-attribute init-address --node=interface=public should succeed and fails
This is due to some logic in place to retrieve the node value.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFCORE-1563) Failed CLI batch command with "deploy --force" for replace deployment
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1563?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFCORE-1563.
--------------------------------------
Fix Version/s: (was: 2.2.0.CR2)
Resolution: Done
> Failed CLI batch command with "deploy --force" for replace deployment
> ---------------------------------------------------------------------
>
> Key: WFCORE-1563
> URL: https://issues.jboss.org/browse/WFCORE-1563
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.1.0.Final, 3.0.0.Alpha1
> Reporter: ted won
> Assignee: ted won
> Priority: Minor
> Labels: cli, jboss
> Fix For: 3.0.0.Alpha2
>
> Attachments: jboss-ejb-in-ear.ear
>
>
> Using 'deploy --force' command on CLI batch mode fails and returns an error message: "Request is missing the address part."
> {code:title=Command}
> jboss-cli.sh --connect --controller=127.0.0.1:9999 --user=admin --password=xxx --file="deploy.cli"
> {code}
> {code:title=deploy.cli}
> batch
> deploy --force ./jboss-ejb-in-ear.ear
> run-batch
> {code}
> {panel:title=Full Error message}
> Failed to handle 'run-batch': org.jboss.as.cli.CommandFormatException: Request is missing the address part.: Request is missing the address part.
> or
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): Request is missing the address part.
> {panel}
> {panel:title=Expected message}
> The batch executed successfully
> {panel}
> However, it's working in "WildFly 10 CLI interactive mode" and "JBoss AS 7 CLI batch" without error.
> There is no adding "address" key in buildDeploymentReplace() of DeployHandler like below.
> Even though on CLI batch mode it validates existence of "address" key in request with Util.validateRequest(), when 'run-batch' command execute in org.jboss.as.cli.handlers.batch.BatchRunHandler.doHandle()
> -------------------------------------------------------------------------------------------
> * First deploy: add by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentAdd()
> {code}
> {
> "operation" => "add",
> "address" => {"deployment" => "jboss-ejb-in-ear.ear"},
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
> * After deploy: replace by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace()
> {code}
> {
> "operation" => "full-replace-deployment",
> "name" => "jboss-ejb-in-ear.ear",
> "enabled" => true,
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
> * Expected by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace()
> {code}
> {
> "operation" => "full-replace-deployment",
> "name" => "jboss-ejb-in-ear.ear",
> "address" => [],
> "enabled" => true,
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFCORE-1563) Failed CLI batch command with "deploy --force" for replace deployment
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1563?page=com.atlassian.jira.plugi... ]
Brian Stansberry reopened WFCORE-1563:
--------------------------------------
Reopening to correct Fix Version.
> Failed CLI batch command with "deploy --force" for replace deployment
> ---------------------------------------------------------------------
>
> Key: WFCORE-1563
> URL: https://issues.jboss.org/browse/WFCORE-1563
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.1.0.Final, 3.0.0.Alpha1
> Reporter: ted won
> Assignee: ted won
> Priority: Minor
> Labels: cli, jboss
> Fix For: 2.2.0.CR2, 3.0.0.Alpha2
>
> Attachments: jboss-ejb-in-ear.ear
>
>
> Using 'deploy --force' command on CLI batch mode fails and returns an error message: "Request is missing the address part."
> {code:title=Command}
> jboss-cli.sh --connect --controller=127.0.0.1:9999 --user=admin --password=xxx --file="deploy.cli"
> {code}
> {code:title=deploy.cli}
> batch
> deploy --force ./jboss-ejb-in-ear.ear
> run-batch
> {code}
> {panel:title=Full Error message}
> Failed to handle 'run-batch': org.jboss.as.cli.CommandFormatException: Request is missing the address part.: Request is missing the address part.
> or
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): Request is missing the address part.
> {panel}
> {panel:title=Expected message}
> The batch executed successfully
> {panel}
> However, it's working in "WildFly 10 CLI interactive mode" and "JBoss AS 7 CLI batch" without error.
> There is no adding "address" key in buildDeploymentReplace() of DeployHandler like below.
> Even though on CLI batch mode it validates existence of "address" key in request with Util.validateRequest(), when 'run-batch' command execute in org.jboss.as.cli.handlers.batch.BatchRunHandler.doHandle()
> -------------------------------------------------------------------------------------------
> * First deploy: add by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentAdd()
> {code}
> {
> "operation" => "add",
> "address" => {"deployment" => "jboss-ejb-in-ear.ear"},
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
> * After deploy: replace by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace()
> {code}
> {
> "operation" => "full-replace-deployment",
> "name" => "jboss-ejb-in-ear.ear",
> "enabled" => true,
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
> * Expected by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace()
> {code}
> {
> "operation" => "full-replace-deployment",
> "name" => "jboss-ejb-in-ear.ear",
> "address" => [],
> "enabled" => true,
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFCORE-1665) Enable gc logging function in startup scripts; require env var to enable it
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1665?page=com.atlassian.jira.plugi... ]
Tomaz Cerar updated WFCORE-1665:
--------------------------------
Summary: Enable gc logging function in startup scripts; require env var to enable it (was: Uncomment gc logging function in startup scripts; require env var to enable it)
> Enable gc logging function in startup scripts; require env var to enable it
> ---------------------------------------------------------------------------
>
> Key: WFCORE-1665
> URL: https://issues.jboss.org/browse/WFCORE-1665
> Project: WildFly Core
> Issue Type: Task
> Components: Scripts
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
> Fix For: 3.0.0.Alpha4
>
>
> Our startup scripts have gc logging functionality specified by EAP6-121 that is commented out by default.
> This approach to disabling this function makes it difficult to use these scripts in EAP; see JBEAP-5374.
> We should uncomment function this but only enable it if an env var is set. The .conf files core ships will not set this env var. The ones EAP ships can.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (JGRP-2093) Remove Externalizable from Address
by Bela Ban (JIRA)
Bela Ban created JGRP-2093:
------------------------------
Summary: Remove Externalizable from Address
Key: JGRP-2093
URL: https://issues.jboss.org/browse/JGRP-2093
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Minor
Fix For: 4.0
This allows us to remove {{writeExternal()}} and {{readExternal()}} from all addresses, plus {{serialVersionUUID}} as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6512) Missing explanation which services failed to start
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6512?page=com.atlassian.jira.plugin.... ]
Radoslav Husar closed WFLY-6512.
--------------------------------
Resolution: Duplicate
Duplicates WFLY-5688.
> Missing explanation which services failed to start
> --------------------------------------------------
>
> Key: WFLY-6512
> URL: https://issues.jboss.org/browse/WFLY-6512
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.0.0.Final
> Reporter: Fedor Gavrilov
> Assignee: Fedor Gavrilov
>
> Missing info which services failed to start on server startup
> E.g. when I change in mod_cluster subsystem connector reference to invalid one (/subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=connector, value=invalid), the server fails to start several services without explaining which ones. This is user unfriendly as it creates hard effort to find out what is actually wrong. There should be at least pointed out which services failed to start.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months