[JBoss JIRA] (WFCORE-5023) A few tests don't work using IBM JDK because of mock-server 5.9.0
by Ricardo Martin Camarero (Jira)
[ https://issues.redhat.com/browse/WFCORE-5023?page=com.atlassian.jira.plug... ]
Ricardo Martin Camarero edited comment on WFCORE-5023 at 6/26/20 6:33 AM:
--------------------------------------------------------------------------
The mockserver seems to work this way:
* Version 5.8.1 seems to use bouncycastle for the SSL configuration.
* 5.9.0 and 5.10.0 seems to use internal openjdk for everything (and makes IBM jdk fail).
* In the future it seems that bouncycastle is going to be optional and it can be configured to be used instead of the internal openjdk (this [commit|https://github.com/mock-server/mockserver/commit/34e792f47c23bf0e9...], but it's still WIP).
For the moment the downgrade is needed and we'll upgrade it when the new version is ready and able to switch between both SSL implementations. Let's see if the downgrade does not affect any other test.
EDIT: The need for BC or internal opendk is for certificate/key-pair generation (DER encoding, certificates and so on and so forth), not for TLS/SSL communication.
was (Author: rhn-support-rmartinc):
The mockserver seems to work this way:
* Version 5.8.1 seems to use bouncycastle for all SSL configuration.
* 5.9.0 and 5.10.0 seems to use internal openjdk for everything (and makes IBM jdk fail).
* In the future it seems that bouncycastle is going to be optional and it can be configured to be used instead of the internal openjdk (this [commit|https://github.com/mock-server/mockserver/commit/34e792f47c23bf0e9...], but it's still WIP).
For the moment the downgrade is needed and we'll upgrade it when the new version is ready and able to switch between both SSL implementations. Let's see if the downgrade does not affect any other test.
> A few tests don't work using IBM JDK because of mock-server 5.9.0
> -----------------------------------------------------------------
>
> Key: WFCORE-5023
> URL: https://issues.redhat.com/browse/WFCORE-5023
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 13.0.0.Beta1
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Major
>
> After JIRA WFCORE-4850 the mock-server 5.9.0 does not work with IBM JDK which makes a few tests fail with the following error:
> {code:bash}
> cd ./testsuite/standalone/
> export JAVA_HOME=/home/rmartinc/apps/ibm-java-x86_64-80/
> mvn clean test -Dtest=org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase
> ...
> [INFO] -------------------------------------------------------
> [INFO] T E S T S
> [INFO] -------------------------------------------------------
> [INFO] Running org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.005 s <<< FAILURE! - in org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase
> [ERROR] org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase Time elapsed: 0.003 s <<< ERROR!
> java.lang.NoClassDefFoundError: sun.security.x509.GeneralNameInterface
> at org.mockserver.socket.tls.jdk.JDKKeyAndCertificateFactory.<init>(JDKKeyAndCertificateFactory.java:36)
> at org.mockserver.socket.tls.NettySslContextFactory.<init>(NettySslContextFactory.java:37)
> at org.mockserver.client.MockServerClient.<init>(MockServerClient.java:57)
> at org.mockserver.integration.ClientAndServer.<init>(ClientAndServer.java:19)
> at org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase.setup(SecurityCommandsTestCase.java:358)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> 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.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 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)
> Caused by: java.lang.ClassNotFoundException: sun.security.x509.GeneralNameInterface
> at java.net.URLClassLoader.findClass(URLClassLoader.java:610)
> at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:944)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:889)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:872)
> ... 36 more
> {code}
> The tests that don't work are the following three classes:
> * CertificateAuthoritiesTestCase.java (elytron)
> * KeyStoresTestCase.java (elytron)
> * SecurityCommandsTestCase.java (testsuite/standalone)
> This is explained in the mock-server [issue 750|https://github.com/mock-server/mockserver/issues/750]. For the moment the only solution is doing a downgrade to 5.8.1. Although it is expected to be fixed soon in the mock-server (maybe in the next version 5.10.1 or 5.11.0).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (DROOLS-5457) XLS Decision table: File indexed before content is saved
by Toni Rikkola (Jira)
Toni Rikkola created DROOLS-5457:
------------------------------------
Summary: XLS Decision table: File indexed before content is saved
Key: DROOLS-5457
URL: https://issues.redhat.com/browse/DROOLS-5457
Project: Drools
Issue Type: Bug
Components: XLS Decision Table Editor
Reporter: Toni Rikkola
Assignee: Toni Rikkola
The upload first creates an empty file and then streams the content into the file. These is a gap where indexing can start before content is in place.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFCORE-5023) A few tests don't work using IBM JDK because of mock-server 5.9.0
by Ricardo Martin Camarero (Jira)
[ https://issues.redhat.com/browse/WFCORE-5023?page=com.atlassian.jira.plug... ]
Ricardo Martin Camarero commented on WFCORE-5023:
-------------------------------------------------
The mockserver seems to work this way:
* Version 5.8.1 seems to use bouncycastle for all SSL configuration.
* 5.9.0 and 5.10.0 seems to use internal openjdk for everything (and makes IBM jdk fail).
* In the future it seems that bouncycastle is going to be optional and it can be configured to be used instead of the internal openjdk (this [commit|https://github.com/mock-server/mockserver/commit/34e792f47c23bf0e9...], but it's still WIP).
For the moment the downgrade is needed and we'll upgrade it when the new version is ready and able to switch between both SSL implementations. Let's see if the downgrade does not affect any other test.
> A few tests don't work using IBM JDK because of mock-server 5.9.0
> -----------------------------------------------------------------
>
> Key: WFCORE-5023
> URL: https://issues.redhat.com/browse/WFCORE-5023
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 13.0.0.Beta1
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Major
>
> After JIRA WFCORE-4850 the mock-server 5.9.0 does not work with IBM JDK which makes a few tests fail with the following error:
> {code:bash}
> cd ./testsuite/standalone/
> export JAVA_HOME=/home/rmartinc/apps/ibm-java-x86_64-80/
> mvn clean test -Dtest=org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase
> ...
> [INFO] -------------------------------------------------------
> [INFO] T E S T S
> [INFO] -------------------------------------------------------
> [INFO] Running org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.005 s <<< FAILURE! - in org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase
> [ERROR] org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase Time elapsed: 0.003 s <<< ERROR!
> java.lang.NoClassDefFoundError: sun.security.x509.GeneralNameInterface
> at org.mockserver.socket.tls.jdk.JDKKeyAndCertificateFactory.<init>(JDKKeyAndCertificateFactory.java:36)
> at org.mockserver.socket.tls.NettySslContextFactory.<init>(NettySslContextFactory.java:37)
> at org.mockserver.client.MockServerClient.<init>(MockServerClient.java:57)
> at org.mockserver.integration.ClientAndServer.<init>(ClientAndServer.java:19)
> at org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase.setup(SecurityCommandsTestCase.java:358)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> 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.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 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)
> Caused by: java.lang.ClassNotFoundException: sun.security.x509.GeneralNameInterface
> at java.net.URLClassLoader.findClass(URLClassLoader.java:610)
> at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:944)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:889)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:872)
> ... 36 more
> {code}
> The tests that don't work are the following three classes:
> * CertificateAuthoritiesTestCase.java (elytron)
> * KeyStoresTestCase.java (elytron)
> * SecurityCommandsTestCase.java (testsuite/standalone)
> This is explained in the mock-server [issue 750|https://github.com/mock-server/mockserver/issues/750]. For the moment the only solution is doing a downgrade to 5.8.1. Although it is expected to be fixed soon in the mock-server (maybe in the next version 5.10.1 or 5.11.0).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (DROOLS-5454) Please bring back the IDE-based 'Guided Rule Editor'
by Igor Dayen (Jira)
[ https://issues.redhat.com/browse/DROOLS-5454?page=com.atlassian.jira.plug... ]
Igor Dayen commented on DROOLS-5454:
------------------------------------
Having Drools Guided Editor Eclipse plugin with features on par with web tool will be well appreciated by Drools developers community.
Will significantly simplify deployment and speed up adoption of tooling. Thank you, Igor
> Please bring back the IDE-based 'Guided Rule Editor'
> ----------------------------------------------------
>
> Key: DROOLS-5454
> URL: https://issues.redhat.com/browse/DROOLS-5454
> Project: Drools
> Issue Type: Feature Request
> Components: eclipse plugin
> Affects Versions: 7.39.0.Final
> Reporter: Rick Wagner
> Assignee: Edson Tirelli
> Priority: Major
>
> JBoss Rules users have had access to an Eclipse/DevStudio plugin called the "Guided Rules Editor". It has been removed or replaced by non-IDE solutions. This is disappointing to some users who have business processes, training, etc. based around the plugin version.
>
> Please bring back the Guided Rule Editor.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFCORE-5022) The /subsystem=elytron/policy=* can be simplified a lot further
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-5022?page=com.atlassian.jira.plug... ]
Darran Lofthouse updated WFCORE-5022:
-------------------------------------
Description:
At the moment this resource is quite verbose but the tasks it performs are very simple.
{code}
[standalone@localhost:9990 /] /subsystem=elytron/policy=*:read-resource-description
{
"outcome" => "success",
"result" => [{
"address" => [
("subsystem" => "elytron"),
("policy" => "*")
],
"outcome" => "success",
"result" => {
"description" => "A definition that sets up a policy provider.",
"max-occurs" => 1,
"capabilities" => [{
"name" => "org.wildfly.security.policy",
"dynamic" => false
}],
"access-constraints" => {
"sensitive" => {"elytron-security" => {"type" => "elytron"}},
"application" => {"elytron-security" => {"type" => "elytron"}}
},
"attributes" => {
"custom-policy" => {
"type" => OBJECT,
"description" => "A custom policy provider definition.",
"expressions-allowed" => false,
"required" => true,
"nillable" => true,
"alternatives" => ["jacc-policy"],
"value-type" => {
"class-name" => {
"type" => STRING,
"description" => "The name of a java.security.Policy implementation referencing a policy provider.",
"expressions-allowed" => false,
"required" => true,
"nillable" => false,
"min-length" => 1L,
"max-length" => 2147483647L
},
"module" => {
"type" => STRING,
"description" => "The name of the module to load the provider from.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
}
},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
},
"default-policy" => {
"type" => STRING,
"description" => "Not used.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L,
"deprecated" => {
"since" => "1.2.0",
"reason" => "The 'default-policy' attribute is ignored, as a policy resource should be configured with only one policy."
},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
},
"jacc-policy" => {
"type" => OBJECT,
"description" => "A policy provider definition that sets up JACC and related services.",
"expressions-allowed" => false,
"required" => true,
"nillable" => true,
"alternatives" => ["custom-policy"],
"value-type" => {
"policy" => {
"type" => STRING,
"description" => "The name of a java.security.Policy implementation referencing a policy provider.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"default" => "org.wildfly.security.authz.jacc.JaccDelegatingPolicy",
"min-length" => 1L,
"max-length" => 2147483647L
},
"configuration-factory" => {
"type" => STRING,
"description" => "The name of a javax.security.jacc.PolicyConfigurationFactory implementation referencing a policy configuration factory provider.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"default" => "org.wildfly.security.authz.jacc.ElytronPolicyConfigurationFactory",
"min-length" => 1L,
"max-length" => 2147483647L
},
"module" => {
"type" => STRING,
"description" => "The name of the module to load the provider from.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
}
},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
}
},
"operations" => undefined,
"notifications" => undefined,
"children" => {}
}
}]
}
{code}
Firstly it only makes sense to have a single policy defined, the outcome of this resource is JVM wide registration so multiple definitions would lead to undefined behaviour.
Secondly this provides two primary functions.
1. Instantation of https://docs.oracle.com/javase/8/docs/api/java/security/Policy.html and registration via a call to https://docs.oracle.com/javase/8/docs/api/java/security/Policy.html#setPo...
This first point needs a class name for the policy as well as a module.
2. Registration of the JVM wide https://jakarta.ee/specifications/platform/8/apidocs/javax/security/jacc/... again needing a classname and module.
This is also not working correctly but the immediate bug is being addressed under WFCORE-5020
The JACC APIs don't actually provide a nice way to register this so maybe this is something we should also propose via the spec, but this piece is effectively a class name and module name.
We have ended up with custom and jacc variants as alternatives. Really both variants are optional but if the resource is defined at least one must be set.
It may make sense for JACC to move to it's own subsystem for a couple of reasons.
The JVM wide policy will likely need to be possible in both subsystems but use a capability to ensure it is defined in only one. We probably should move it's registration into the boot operations so registration is complete before DUPs begin.
The PolicyConfigurationFactory would then be in a JACC subsystem only. Again handling during a boot operation may be preferable otherwise we see issues like WFLY-13615 but failing that ensuring the deployment depend upon the registration happening may be sufficient.
Additionally the resource has some hard coded class names for the Policy and PolicyConfigurationFactory, we probably should not have these as class names and instead default to them if not defined - this means we still need a way to optionally activate their registration if JACC is required on the server.
was:
At the moment this resource is quite verbose but the tasks it performs are very simple.
{code}
[standalone@localhost:9990 /] /subsystem=elytron/policy=*:read-resource-description
{
"outcome" => "success",
"result" => [{
"address" => [
("subsystem" => "elytron"),
("policy" => "*")
],
"outcome" => "success",
"result" => {
"description" => "A definition that sets up a policy provider.",
"max-occurs" => 1,
"capabilities" => [{
"name" => "org.wildfly.security.policy",
"dynamic" => false
}],
"access-constraints" => {
"sensitive" => {"elytron-security" => {"type" => "elytron"}},
"application" => {"elytron-security" => {"type" => "elytron"}}
},
"attributes" => {
"custom-policy" => {
"type" => OBJECT,
"description" => "A custom policy provider definition.",
"expressions-allowed" => false,
"required" => true,
"nillable" => true,
"alternatives" => ["jacc-policy"],
"value-type" => {
"class-name" => {
"type" => STRING,
"description" => "The name of a java.security.Policy implementation referencing a policy provider.",
"expressions-allowed" => false,
"required" => true,
"nillable" => false,
"min-length" => 1L,
"max-length" => 2147483647L
},
"module" => {
"type" => STRING,
"description" => "The name of the module to load the provider from.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
}
},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
},
"default-policy" => {
"type" => STRING,
"description" => "Not used.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L,
"deprecated" => {
"since" => "1.2.0",
"reason" => "The 'default-policy' attribute is ignored, as a policy resource should be configured with only one policy."
},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
},
"jacc-policy" => {
"type" => OBJECT,
"description" => "A policy provider definition that sets up JACC and related services.",
"expressions-allowed" => false,
"required" => true,
"nillable" => true,
"alternatives" => ["custom-policy"],
"value-type" => {
"policy" => {
"type" => STRING,
"description" => "The name of a java.security.Policy implementation referencing a policy provider.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"default" => "org.wildfly.security.authz.jacc.JaccDelegatingPolicy",
"min-length" => 1L,
"max-length" => 2147483647L
},
"configuration-factory" => {
"type" => STRING,
"description" => "The name of a javax.security.jacc.PolicyConfigurationFactory implementation referencing a policy configuration factory provider.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"default" => "org.wildfly.security.authz.jacc.ElytronPolicyConfigurationFactory",
"min-length" => 1L,
"max-length" => 2147483647L
},
"module" => {
"type" => STRING,
"description" => "The name of the module to load the provider from.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
}
},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
}
},
"operations" => undefined,
"notifications" => undefined,
"children" => {}
}
}]
}
{code}
Firstly it only makes sense to have a single policy defined, the outcome of this resource is JVM wide registration so multiple definitions would lead to undefined behaviour.
Secondly this provides two primary functions.
1. Instantation of https://docs.oracle.com/javase/8/docs/api/java/security/Policy.html and registration via a call to https://docs.oracle.com/javase/8/docs/api/java/security/Policy.html#setPo...
This first point needs a class name for the policy as well as a module.
2. Registration of the JVM wide https://jakarta.ee/specifications/platform/8/apidocs/javax/security/jacc/... again needing a classname and module.
This is also not working correctly but the immediate bug is being addressed under WFCORE-5020
The JACC APIs don't actually provide a nice way to register this so maybe this is something we should also propose via the spec, but this piece is effectively a class name and module name.
We have ended up with custom and jacc variants as alternatives. Really both variants are optional but if the resource is defined at least one must be set.
It may make sense for JACC to move to it's own subsystem for a couple of reasons.
The JVM wide policy will likely need to be possible in both subsystems but use a capability to ensure it is defined in only one. We probably should move it's registration into the boot operations so registration is complete before DUPs begin.
The PolicyConfigurationFactory would then be in a JACC subsystem only. Again handling during a boot operation may be preferable otherwise we see issues like WFLY-13615 but failing that ensuring the deployment depend upon the registration happening may be sufficient.
> The /subsystem=elytron/policy=* can be simplified a lot further
> ---------------------------------------------------------------
>
> Key: WFCORE-5022
> URL: https://issues.redhat.com/browse/WFCORE-5022
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Security
> Affects Versions: 12.0.1.Final
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 13.0.0.Beta1
>
>
> At the moment this resource is quite verbose but the tasks it performs are very simple.
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/policy=*:read-resource-description
> {
> "outcome" => "success",
> "result" => [{
> "address" => [
> ("subsystem" => "elytron"),
> ("policy" => "*")
> ],
> "outcome" => "success",
> "result" => {
> "description" => "A definition that sets up a policy provider.",
> "max-occurs" => 1,
> "capabilities" => [{
> "name" => "org.wildfly.security.policy",
> "dynamic" => false
> }],
> "access-constraints" => {
> "sensitive" => {"elytron-security" => {"type" => "elytron"}},
> "application" => {"elytron-security" => {"type" => "elytron"}}
> },
> "attributes" => {
> "custom-policy" => {
> "type" => OBJECT,
> "description" => "A custom policy provider definition.",
> "expressions-allowed" => false,
> "required" => true,
> "nillable" => true,
> "alternatives" => ["jacc-policy"],
> "value-type" => {
> "class-name" => {
> "type" => STRING,
> "description" => "The name of a java.security.Policy implementation referencing a policy provider.",
> "expressions-allowed" => false,
> "required" => true,
> "nillable" => false,
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "module" => {
> "type" => STRING,
> "description" => "The name of the module to load the provider from.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> }
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> "default-policy" => {
> "type" => STRING,
> "description" => "Not used.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "deprecated" => {
> "since" => "1.2.0",
> "reason" => "The 'default-policy' attribute is ignored, as a policy resource should be configured with only one policy."
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> "jacc-policy" => {
> "type" => OBJECT,
> "description" => "A policy provider definition that sets up JACC and related services.",
> "expressions-allowed" => false,
> "required" => true,
> "nillable" => true,
> "alternatives" => ["custom-policy"],
> "value-type" => {
> "policy" => {
> "type" => STRING,
> "description" => "The name of a java.security.Policy implementation referencing a policy provider.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "default" => "org.wildfly.security.authz.jacc.JaccDelegatingPolicy",
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "configuration-factory" => {
> "type" => STRING,
> "description" => "The name of a javax.security.jacc.PolicyConfigurationFactory implementation referencing a policy configuration factory provider.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "default" => "org.wildfly.security.authz.jacc.ElytronPolicyConfigurationFactory",
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "module" => {
> "type" => STRING,
> "description" => "The name of the module to load the provider from.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> }
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> }
> },
> "operations" => undefined,
> "notifications" => undefined,
> "children" => {}
> }
> }]
> }
> {code}
> Firstly it only makes sense to have a single policy defined, the outcome of this resource is JVM wide registration so multiple definitions would lead to undefined behaviour.
> Secondly this provides two primary functions.
> 1. Instantation of https://docs.oracle.com/javase/8/docs/api/java/security/Policy.html and registration via a call to https://docs.oracle.com/javase/8/docs/api/java/security/Policy.html#setPo...
> This first point needs a class name for the policy as well as a module.
> 2. Registration of the JVM wide https://jakarta.ee/specifications/platform/8/apidocs/javax/security/jacc/... again needing a classname and module.
> This is also not working correctly but the immediate bug is being addressed under WFCORE-5020
> The JACC APIs don't actually provide a nice way to register this so maybe this is something we should also propose via the spec, but this piece is effectively a class name and module name.
> We have ended up with custom and jacc variants as alternatives. Really both variants are optional but if the resource is defined at least one must be set.
> It may make sense for JACC to move to it's own subsystem for a couple of reasons.
> The JVM wide policy will likely need to be possible in both subsystems but use a capability to ensure it is defined in only one. We probably should move it's registration into the boot operations so registration is complete before DUPs begin.
> The PolicyConfigurationFactory would then be in a JACC subsystem only. Again handling during a boot operation may be preferable otherwise we see issues like WFLY-13615 but failing that ensuring the deployment depend upon the registration happening may be sufficient.
> Additionally the resource has some hard coded class names for the Policy and PolicyConfigurationFactory, we probably should not have these as class names and instead default to them if not defined - this means we still need a way to optionally activate their registration if JACC is required on the server.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (JBJCA-1409) Publish JDBC local rar with all dependencies
by Thiago Henrique Hüpner (Jira)
Thiago Henrique Hüpner created JBJCA-1409:
---------------------------------------------
Summary: Publish JDBC local rar with all dependencies
Key: JBJCA-1409
URL: https://issues.redhat.com/browse/JBJCA-1409
Project: IronJacamar
Issue Type: Feature Request
Components: JDBC
Reporter: Thiago Henrique Hüpner
Currently, there is the JDBC local artifact here. [https://mvnrepository.com/artifact/org.jboss.ironjacamar/jdbc-local/1.4.2...]
However, it only includes ironjacamar-local.jar. It is not usable outside a container providing both jboss-logging and ironjacamar-core-api.
I want to use the Iron Jacamar JDBC resource adapter in the Open Liberty application server, but I would have to include both jars manually. If there is a way to pack all dependencies inside the _RAR_ file, it would be more reusable, or at least, easier.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (DROOLS-5454) Please bring back the IDE-based 'Guided Rule Editor'
by Kris Verlaenen (Jira)
[ https://issues.redhat.com/browse/DROOLS-5454?page=com.atlassian.jira.plug... ]
Kris Verlaenen reassigned DROOLS-5454:
--------------------------------------
Assignee: Edson Tirelli (was: Kris Verlaenen)
> Please bring back the IDE-based 'Guided Rule Editor'
> ----------------------------------------------------
>
> Key: DROOLS-5454
> URL: https://issues.redhat.com/browse/DROOLS-5454
> Project: Drools
> Issue Type: Feature Request
> Components: eclipse plugin
> Affects Versions: 7.39.0.Final
> Reporter: Rick Wagner
> Assignee: Edson Tirelli
> Priority: Major
>
> JBoss Rules users have had access to an Eclipse/DevStudio plugin called the "Guided Rules Editor". It has been removed or replaced by non-IDE solutions. This is disappointing to some users who have business processes, training, etc. based around the plugin version.
>
> Please bring back the Guided Rule Editor.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months