[JBoss JIRA] (WFCORE-4962) Add a SecurityMetaData for all deployments
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-4962?page=com.atlassian.jira.plug... ]
Jeff Mesnil updated WFCORE-4962:
--------------------------------
Fix Version/s: 12.0.1.Final
(was: 12.0.0.Final)
> Add a SecurityMetaData for all deployments
> ------------------------------------------
>
> Key: WFCORE-4962
> URL: https://issues.redhat.com/browse/WFCORE-4962
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 12.0.1.Final
>
>
> For all deployments we should associate a new class SecurityMetaData with the deployment, initially the purpose of this will be to hold the ServiceName of any Elytron SecurityDomain if one is being used.
> At a later point additional security policy information can be added as we move away from the ApplicationSecurityDomain resources.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFCORE-4973) NPE due to timeout in LongOutputTestCase
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-4973?page=com.atlassian.jira.plug... ]
Jeff Mesnil updated WFCORE-4973:
--------------------------------
Fix Version/s: 12.0.1.Final
(was: 12.0.0.Final)
> NPE due to timeout in LongOutputTestCase
> ----------------------------------------
>
> Key: WFCORE-4973
> URL: https://issues.redhat.com/browse/WFCORE-4973
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Richard Opalka
> Assignee: Richard Opalka
> Priority: Major
> Fix For: 12.0.1.Final
>
>
> [ERROR] Tests run: 5, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 50.287 s <<< FAILURE! - in org.jboss.as.test.integration.management.cli.LongOutputTestCase
> [ERROR] testDisabledOutputPagingViaXml(org.jboss.as.test.integration.management.cli.LongOutputTestCase) Time elapsed: 11.961 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at org.jboss.as.test.integration.management.cli.LongOutputTestCase.testDisabledOutputPaging(LongOutputTestCase.java:394)
> at org.jboss.as.test.integration.management.cli.LongOutputTestCase.testDisabledOutputPagingViaXml(LongOutputTestCase.java:380)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.wildfly.core.testrunner.WildflyTestRunner.run(WildflyTestRunner.java:157)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
> [ERROR] testDisabledOutputPagingViaArgument(org.jboss.as.test.integration.management.cli.LongOutputTestCase) Time elapsed: 11.849 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at org.jboss.as.test.integration.management.cli.LongOutputTestCase.testDisabledOutputPaging(LongOutputTestCase.java:394)
> at org.jboss.as.test.integration.management.cli.LongOutputTestCase.testDisabledOutputPagingViaArgument(LongOutputTestCase.java:368)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.wildfly.core.testrunner.WildflyTestRunner.run(WildflyTestRunner.java:157)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5397) Data object containing at least one enum fails to be opend in Data model editor
by Anna Dupliak (Jira)
Anna Dupliak created DROOLS-5397:
------------------------------------
Summary: Data object containing at least one enum fails to be opend in Data model editor
Key: DROOLS-5397
URL: https://issues.redhat.com/browse/DROOLS-5397
Project: Drools
Issue Type: Bug
Components: Scenario Simulation and Testing
Reporter: Anna Dupliak
Assignee: Yeser Amer
Attachments: EnumFieldOnlyObject.java, EnumTest.java, model view with enum types.webm
It is possible to manage enum types in scenario simulation to do so in Rule based test scenario it is possible to have data object enum. But including at least one field that implements Enumeration interface breaks the model editor and fails to show fields on the UI See: [^model view with enum types.webm]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JGRP-2480) ObjectMessage: better marshalling
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2480?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2480:
---------------------------
Description:
Currently, {{ObjectMessage}} accepts only objects of type {{SizeStreamable}} and wraps everything else into {{ObjectWrapper}} instances.
This means that primitive types (e.g. "{{7}}" or "{{hello world}}") will be wrapped, too. The disadvantage of {{ObjectWrapper}} is that it performs _eager marshalling_, creating an unwanted byte[] array before the message is actually marshalled. On the receiver side, another byte[] array will be created before the actual unmarshalling starts.
Solution: accept primitive types (e.g. {{int}}, {{Integer}}, {{String}}, {{AsciiString}}, {{byte[]}} etc) directly, without wrapping them into an {{ObjectWrapper}}.
was:
Currently, {{ObjectMessage}} accepts only objects of type {{SizeStreamable}} and wraps everything else into {{ObjectWrapper}} instances.
This means that primitive types (e.g. "{{7}}" or "{{hello world}}") will be wrapped, too. The disadvantage of {{ObjectWrapper}} is that it performs _eager marshalling_, creating an (unwanted byte[] array before the message is actually marshalled. On the receiver side, another byte[] array will be created before the actual unmarshalling starts.
Solution: accept primitive types (e.g. {{int}}, {{Integer}}, {{String}}, {{AsciiString}}, {{byte[]}} etc) directly, without wrapping them into an {{ObjectWrapper}}.
> ObjectMessage: better marshalling
> ---------------------------------
>
> Key: JGRP-2480
> URL: https://issues.redhat.com/browse/JGRP-2480
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0.0.Beta2
>
>
> Currently, {{ObjectMessage}} accepts only objects of type {{SizeStreamable}} and wraps everything else into {{ObjectWrapper}} instances.
> This means that primitive types (e.g. "{{7}}" or "{{hello world}}") will be wrapped, too. The disadvantage of {{ObjectWrapper}} is that it performs _eager marshalling_, creating an unwanted byte[] array before the message is actually marshalled. On the receiver side, another byte[] array will be created before the actual unmarshalling starts.
> Solution: accept primitive types (e.g. {{int}}, {{Integer}}, {{String}}, {{AsciiString}}, {{byte[]}} etc) directly, without wrapping them into an {{ObjectWrapper}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JGRP-2480) ObjectMessage: better marshalling
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2480?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2480:
---------------------------
Description:
Currently, {{ObjectMessage}} accepts only objects of type {{SizeStreamable}} and wraps everything else into {{ObjectWrapper}} instances.
This means that primitive types (e.g. "{{7}}" or "{{hello world}}") will be wrapped, too. The disadvantage of {{ObjectWrapper}} is that it performs _eager marshalling_, creating an (unwanted byte[] array before the message is actually marshalled. On the receiver side, another byte[] array will be created before the actual unmarshalling starts.
Solution: accept primitive types (e.g. {{int}}, {{Integer}}, {{String}}, {{AsciiString}}, {{byte[]}} etc) directly, without wrapping them into an {{ObjectWrapper}}.
was:
Currently, {{ObjectMessage}} accepts only objects of type {{SizeStreamable}} and wraps everything else into {{ObjectWrapper}} instances.
This means that primitive types (e.g. "{{7}}" or "{{hello world}}" will be wrapped, too. The disadvantage of {{ObjectWrapper}} is that it performs _eager marshalling_, creating an (unwanted byte[] array before the message is actually marshalled. On the receiver side, another byte[] array will be created before the actual unmarshalling starts.
Solution: accept primitive types (e.g. {{int}}, {{Integer}}, {{String}}, {{AsciiString}}, {{byte[]}} etc) directly, without wrapping them into an {{ObjectWrapper}}.
> ObjectMessage: better marshalling
> ---------------------------------
>
> Key: JGRP-2480
> URL: https://issues.redhat.com/browse/JGRP-2480
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0.0.Beta2
>
>
> Currently, {{ObjectMessage}} accepts only objects of type {{SizeStreamable}} and wraps everything else into {{ObjectWrapper}} instances.
> This means that primitive types (e.g. "{{7}}" or "{{hello world}}") will be wrapped, too. The disadvantage of {{ObjectWrapper}} is that it performs _eager marshalling_, creating an (unwanted byte[] array before the message is actually marshalled. On the receiver side, another byte[] array will be created before the actual unmarshalling starts.
> Solution: accept primitive types (e.g. {{int}}, {{Integer}}, {{String}}, {{AsciiString}}, {{byte[]}} etc) directly, without wrapping them into an {{ObjectWrapper}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JGRP-2480) ObjectMessage: better marshalling
by Bela Ban (Jira)
Bela Ban created JGRP-2480:
------------------------------
Summary: ObjectMessage: better marshalling
Key: JGRP-2480
URL: https://issues.redhat.com/browse/JGRP-2480
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 5.0.0.Beta2
Currently, {{ObjectMessage}} accepts only objects of type {{SizeStreamable}} and wraps everything else into {{ObjectWrapper}} instances.
This means that primitive types (e.g. "{{7}}" or "{{hello world}}" will be wrapped, too. The disadvantage of {{ObjectWrapper}} is that it performs _eager marshalling_, creating an (unwanted byte[] array before the message is actually marshalled. On the receiver side, another byte[] array will be created before the actual unmarshalling starts.
Solution: accept primitive types (e.g. {{int}}, {{Integer}}, {{String}}, {{AsciiString}}, {{byte[]}} etc) directly, without wrapping them into an {{ObjectWrapper}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ELY-1977) (7.3.z) Update AcmeClientSpi#obtainCertificate so that it obtains the order URL from the response to newOrder
by Ilia Vassilev (Jira)
Ilia Vassilev created ELY-1977:
----------------------------------
Summary: (7.3.z) Update AcmeClientSpi#obtainCertificate so that it obtains the order URL from the response to newOrder
Key: ELY-1977
URL: https://issues.redhat.com/browse/ELY-1977
Project: WildFly Elytron
Issue Type: Task
Reporter: Ilia Vassilev
Assignee: Farah Juma
{{AcmeClientSpi#obtainCertificate}} currently determines the order URL that should be used by taking the {{Location}} header from the response to finalizing the order (the ACME protocol specification has an example response that includes this header). This works when obtaining certificates from Let's Encrypt and Boulder. However, it seems that EJBCA does not include the {{Location}} header in the response to finalizing the order. {{AcmeClientSpi#obtainCertificate}} should instead use the Location header from the response to {{newOrder}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month