[JBoss JIRA] (WFLY-7127) CMR collection gets corrupted in 2LC on certain concurrent access
by Gail Badner (JIRA)
[ https://issues.jboss.org/browse/WFLY-7127?page=com.atlassian.jira.plugin.... ]
Gail Badner edited comment on WFLY-7127 at 11/2/16 5:17 PM:
------------------------------------------------------------
[~zds], thanks for your test case. I have confirmed that your test uses TRANSACTIONAL cache concurrency strategy (not READ_ONLY). I have reproduced your issue using MySQL.
I believe there are some differences between the ear in your attachment and the ear that is generated using `ant build`. I also don't see anything that configures the CMR. I could be missing something there. Can you point out what it is in your attachment that configures the CRM.
was (Author: gbadner):
@reporter, thanks for your test case. I have confirmed that your test uses TRANSACTIONAL cache concurrency strategy (not READ_ONLY). I have reproduced your issue using MySQL.
I believe there are some differences between the ear in your attachment and the ear that is generated using `ant build`. I also don't see anything that configures the CMR. I could be missing something there. Can you point out what it is in your attachment that configures the CRM.
> CMR collection gets corrupted in 2LC on certain concurrent access
> -----------------------------------------------------------------
>
> Key: WFLY-7127
> URL: https://issues.jboss.org/browse/WFLY-7127
> Project: WildFly
> Issue Type: Bug
> Components: EJB, JPA / Hibernate, Transactions
> Affects Versions: 10.1.0.Final
> Environment: Ubuntu Linux 15.10. Java 1.8.0_66
> Reporter: Jari Juslin
> Assignee: Scott Marlow
> Attachments: infinispan_cmr_corruption_repro.tar.gz, standalone.xml
>
>
> With certain parallel read and write access to same CMR collection it gets corrupted in Hibernate second level cache. After the event of corruption, any read access to that CMR collection ends up in Exception until the cache is cleared manually or Wildfly restarted.
> Steps to reproduce:
> 1) Make sure the CMR collection is not in cache.
> 2) Start a read-only transaction accessing the said collection.
> 3) In a separate transaction delete an element from that collection.
> 4) End the read-only transaction.
> 5) Read the resulting collection. It now throws EntityNotFoundException.
> My understanding is that what happens is that the read-only transaction is read-only from the perspective of the database, so the system handles it as such. However, because for the 2LC it is actually a write transaction, when the transaction ends, the contents of the CMR collection visible to this transaction get committed to 2LC. If the write transaction ends before the read-only transaction, the old version of the collection stays in the 2LC.
> Now, as the CMR collection contains an element already deleted from the DB, any attempt to manifest the collection results in EntityNotFoundException as the child element no longer exists in the DB.
> For sake of repeatibility the test case here manually spawns threads to cause the effect. In real use, of course, this happens randomly when two different threads spawned by Wildfly happen to interleave with exactly a right kind of pattern.
> The tar ball contains everything needed to reproduce the bug, including SQL dump of the MySQL/InnoDB database. The easiest way to run the testcase is to take Wildfly 10.1.0.Final and use the provided standalone.xml, add MySQL driver, import the DB with the provided SQL and then deploy the included packaged testcase.ear.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7127) CMR collection gets corrupted in 2LC on certain concurrent access
by Gail Badner (JIRA)
[ https://issues.jboss.org/browse/WFLY-7127?page=com.atlassian.jira.plugin.... ]
Gail Badner commented on WFLY-7127:
-----------------------------------
@reporter, thanks for your test case. I have confirmed that your test uses TRANSACTIONAL cache concurrency strategy (not READ_ONLY). I have reproduced your issue using MySQL.
I believe there are some differences between the ear in your attachment and the ear that is generated using `ant build`. I also don't see anything that configures the CMR. I could be missing something there. Can you point out what it is in your attachment that configures the CRM.
> CMR collection gets corrupted in 2LC on certain concurrent access
> -----------------------------------------------------------------
>
> Key: WFLY-7127
> URL: https://issues.jboss.org/browse/WFLY-7127
> Project: WildFly
> Issue Type: Bug
> Components: EJB, JPA / Hibernate, Transactions
> Affects Versions: 10.1.0.Final
> Environment: Ubuntu Linux 15.10. Java 1.8.0_66
> Reporter: Jari Juslin
> Assignee: Scott Marlow
> Attachments: infinispan_cmr_corruption_repro.tar.gz, standalone.xml
>
>
> With certain parallel read and write access to same CMR collection it gets corrupted in Hibernate second level cache. After the event of corruption, any read access to that CMR collection ends up in Exception until the cache is cleared manually or Wildfly restarted.
> Steps to reproduce:
> 1) Make sure the CMR collection is not in cache.
> 2) Start a read-only transaction accessing the said collection.
> 3) In a separate transaction delete an element from that collection.
> 4) End the read-only transaction.
> 5) Read the resulting collection. It now throws EntityNotFoundException.
> My understanding is that what happens is that the read-only transaction is read-only from the perspective of the database, so the system handles it as such. However, because for the 2LC it is actually a write transaction, when the transaction ends, the contents of the CMR collection visible to this transaction get committed to 2LC. If the write transaction ends before the read-only transaction, the old version of the collection stays in the 2LC.
> Now, as the CMR collection contains an element already deleted from the DB, any attempt to manifest the collection results in EntityNotFoundException as the child element no longer exists in the DB.
> For sake of repeatibility the test case here manually spawns threads to cause the effect. In real use, of course, this happens randomly when two different threads spawned by Wildfly happen to interleave with exactly a right kind of pattern.
> The tar ball contains everything needed to reproduce the bug, including SQL dump of the MySQL/InnoDB database. The easiest way to run the testcase is to take Wildfly 10.1.0.Final and use the provided standalone.xml, add MySQL driver, import the DB with the provided SQL and then deploy the included packaged testcase.ear.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1926) :validate-address operation produces unclear failure message; pollutes server log with exceptions
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1926?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved JBEAP-6845 to WFCORE-1926:
-------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1926 (was: JBEAP-6845)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: CLI)
(was: User Experience)
Affects Version/s: (was: 7.1.0.DR7)
> :validate-address operation produces unclear failure message; pollutes server log with exceptions
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1926
> URL: https://issues.jboss.org/browse/WFCORE-1926
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Michal Jurc
> Assignee: Brian Stansberry
>
> Operation {{:validate-address}} produces IllegalArgumentException with wrong parameters instead of well formed failure description:
> {{jboss-cli}}:
> {code}[standalone@localhost:9990 /] :validate-address(value=nonsense)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
> "rolled-back" => true
> }
> {code}
> {{server.log}}:
> {code}13:14:39,102 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 15) WFLYCTL0013: Operation ("validate-address") failed - address: ([]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asList(ModelValue.java:143)
> at org.jboss.dmr.ModelNode.asList(ModelNode.java:1389)
> at org.jboss.as.controller.PathAddress.pathAddress(PathAddress.java:72)
> at org.jboss.as.controller.operations.common.ValidateAddressOperationHandler.execute(ValidateAddressOperationHandler.java:77)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 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:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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}
> {{jboss-cli}}:
> {code}[standalone@localhost:9990 /] :validate-address(value=(nonsense))
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
> "rolled-back" => true
> }
> {code}
> {{server.log}}:
> {code}13:16:25,040 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 17) WFLYCTL0013: Operation ("validate-address") failed - address: ([]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asList(ModelValue.java:143)
> at org.jboss.dmr.ModelNode.asList(ModelNode.java:1389)
> at org.jboss.as.controller.PathAddress.pathAddress(PathAddress.java:72)
> at org.jboss.as.controller.operations.common.ValidateAddressOperationHandler.execute(ValidateAddressOperationHandler.java:77)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> 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:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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}
> However, the following erroneous input does not pollute server.log with warning:
> {code}[standalone@localhost:9990 /] :validate-address(value={"nonsense"=>"nonsense"})
> Failed to handle ':validate-address(value={"nonsense"=>"nonsense"})': java.lang.IllegalArgumentException
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1677) Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates cope with substitutions properly
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1677?page=com.atlassian.jira.plugi... ]
Kabir Khan commented on WFCORE-1677:
------------------------------------
As an experiment, I tried to move the @RunWith annotation from core's JvmTransformersTestCase to the superclass AbstractCoreModelTest, and the custom test runner still kicks in. So it would be possible to have a custom runner on AbstractSusbsystemBaseTest which totally skips these tests if not implemented in the subsystem tests. It doesn't really get us much more than 3) though, apart from reporting less tests actually run so I am not sure if it is worth the effort.
> 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
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1677) Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates cope with substitutions properly
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1677?page=com.atlassian.jira.plugi... ]
Kabir Khan commented on WFCORE-1677:
------------------------------------
I found http://www.mikereedell.com/post/2011-12-15-JUnit-Conditional-Ignore-Using... but if I am reading it properly, it is a roundabout way of doing 3)
> 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
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (ELY-715) SPNEGO: missing negstat field in the first reply
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-715?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-715:
--------------------------------
The test expects the server will send REJECTED response (Negotiate oQcwBaADCgEC), but gssContext.acceptSecContext throws GSSException, does not generate token to be sent to the peer.
> SPNEGO: missing negstat field in the first reply
> ------------------------------------------------
>
> Key: ELY-715
> URL: https://issues.jboss.org/browse/ELY-715
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> When the client sends an initial SPNEGO token with Kerberos as preferred mechanism and includes an invalid kerberos token, then client expects to see the {{WWW-Authenticate}} HTTP header with SPNEGO response {{negTokenResp[ negState = reject ]}}.
> As stated in [SPNEGO specification|https://tools.ietf.org/html/rfc4178#section-4.2.2] negstat is required in first reply:
> {code:borderStyle=dashed}
> negState
> ...
> This field is REQUIRED in the first reply from the target, and is
> OPTIONAL thereafter. When negState is absent, the actual state
> should be inferred from the state of the negotiated mechanism
> context.
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[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 commented on WFCORE-1677:
----------------------------------------
Brian's comment perfectly describes my concern. I tried to find a way in JUnit how to not run the test at all (so that the test is neither passed,failed nor ignored) but there doesn't seem to be a reasonable way to do that. So I see we have 3 options:
#1 remove the test completely and rely on StandardConfigsXMLValidationUnitTestCase
#2 Kabir's proposal
#3 Another option to Kabirs proposal is to make the test pass by default (as opposed to being ignored and raise flags): https://github.com/rhusar/wildfly-core/commit/5fc0cbdf1270a186e176b88acb3...
> 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
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1677) Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates cope with substitutions properly
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1677?page=com.atlassian.jira.plugi... ]
Kabir Khan commented on WFCORE-1677:
------------------------------------
One option would be to remote the @Test annotation from AbstractSusbsystemBaseTest. testSchemaOfSubsystemTemplates(), remove the Assume stuff, and make all subsystem tests wanting to implement this add something along the lines of
{code}
@Test
public void testSchemaOfSubsystemTemplates() {
super. testSchemaOfSubsystemTemplates()
}
{code}
Once merged into full, another test could be added to the base class making sure that subsystem tests that had provided getSubsystemXsdPath() and getSubsystemTemplatePaths() also provide a testSchemaOfSubsystemTemplates() method, so cleanup can happen in the next core release.
> 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
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (ELY-715) SPNEGO: missing negstat field in the first reply
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-715?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina moved JBEAP-6843 to ELY-715:
---------------------------------------
Project: WildFly Elytron (was: JBoss Enterprise Application Platform)
Key: ELY-715 (was: JBEAP-6843)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Authentication Mechanisms
(was: Security)
Affects Version/s: (was: 7.0.0.ER7)
> SPNEGO: missing negstat field in the first reply
> ------------------------------------------------
>
> Key: ELY-715
> URL: https://issues.jboss.org/browse/ELY-715
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> When the client sends an initial SPNEGO token with Kerberos as preferred mechanism and includes an invalid kerberos token, then client expects to see the {{WWW-Authenticate}} HTTP header with SPNEGO response {{negTokenResp[ negState = reject ]}}.
> As stated in [SPNEGO specification|https://tools.ietf.org/html/rfc4178#section-4.2.2] negstat is required in first reply:
> {code:borderStyle=dashed}
> negState
> ...
> This field is REQUIRED in the first reply from the target, and is
> OPTIONAL thereafter. When negState is absent, the actual state
> should be inferred from the state of the negotiated mechanism
> context.
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1677) Make AbstractSubsystemBaseTest#testSchemaOfSubsystemTemplates cope with substitutions properly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1677?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1677:
------------------------------------------
We should look into reworking them so "opt in" means explicitly adding the test, as opposed to having them on by default but effectively @Ignored unless the user implements a method. Because of the replacement issue it's likely that a large number of subsystems will never enable these, and that's leading to a high count of "Ignored" tests on our CI runs. Which leads to occasional questions about why our test suite is ignoring so many problems and whether we need an initiative to correct that.
> 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
(v7.2.3#72005)
9 years, 8 months