[JBoss JIRA] (WFLY-13619) Elytron: org.wildfly.security.auth.server.SecurityIdentity not Serializable
by Andrej Kolontai (Jira)
[ https://issues.redhat.com/browse/WFLY-13619?page=com.atlassian.jira.plugi... ]
Andrej Kolontai updated WFLY-13619:
-----------------------------------
Steps to Reproduce:
The problem is reproducible with just one server by making the session store persistent.
My production setup is rather complex so I've created a tiny project just to show the effect: [https://github.com/andrejkolontai/jaspic-elytron-distributed-demo]
First, get a fresh wildfly distribution (version 20.0.0.Final) and unpack it.
Start it with standalone.sh.
Then, using jboss-cli.sh make the session store persistent:
{noformat}
/subsystem=infinispan/cache-container=web/local-cache=passivation/store=file:add(passivation=false,purge=false)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}[standalone@localhost:9990 /] reload
{noformat}
{{}}
Then create an elytron security domain and connect it to undertow:
{noformat}
[standalone@localhost:9990 /] /subsystem=elytron/security-domain=elytronjaspic:add
{"outcome" => "success"}[standalone@localhost:9990 /] /subsystem=undertow/application-security-domain=elytronjaspic:add(integrated-jaspi=false,security-domain=elytronjaspic)
{"outcome" => "success"}
{noformat}
The demo project has a servlet, a session scoped cdi bean (counts the requests in a session) an a rather trivial authenticator which uses AutoApplySession.
To build it, use the gradle wrapper:
{noformat}
{noformat}
{{./gradlew war}}
The repository has three tags to see the difference between old security subsystem and elytron.
First, the old security subsystem to ses how it's used to work:
{noformat}
git checkout old-security
Previous HEAD position was 6dad6c3 Changed security domain to the elytron one
HEAD is now at 547cff7 First Commmit
./gradlew warBUILD SUCCESSFUL in 1s
2 actionable tasks: 1 executed, 1 up-to-date
cp build/libs/jaspic.war ~/devel/wildfly-20.0.0.Final/standalone/deployments/{noformat}
{{}}
Verify that the authentication mechanism kicks in:
{noformat}
curl -w '\n' -c cookies -b cookies localhost:8080/jaspic/hallo
<html><head><title>Error</title></head><body>Unauthorized</body></html>{noformat}
call with authentication credentials:
{noformat}
curl -w '\n' -c cookies -b cookies -H "secret: shampoo" localhost:8080/jaspic/hallo
Hallo Welt 0{noformat}
verify that the authentication state is stored in the session (call without secret):
{noformat}
curl -w '\n' -c cookies -b cookies localhost:8080/jaspic/hallo
Hallo Welt 1{noformat}
reload/restart wildfly
verify the session has survived the reload:
{noformat}
curl -w '\n' -c cookies -b cookies localhost:8080/jaspic/hallo
Hallo Welt 2{noformat}
Now, switch to elytron by changing the security domain:
{noformat}
git checkout elytron-security{noformat}
build & deploy like above
Now do the same procedure but clear the cookies first:
{noformat}
rm cookies
curl -w '\n' -c cookies -b cookies localhost:8080/jaspic/hallo
<html><head><title>Error</title></head><body>Unauthorized</body></html>
curl -w '\n' -c cookies -b cookies -H "secret: shampoo" localhost:8080/jaspic/hallo
Hallo Welt 0{noformat}
At this point you should see wildfly throwing exceptions. My demo application seems to work. But my production application would stop working. And the sessions are not actually persisted. One more effect in production: when a server is restarted, it takes a very long time for it to come back again because the running server is struggling to serialize the session data which is not possible while the restarting server is waiting for the cached session data to arrive. After a timeout, the affected applications would just go into .failed.
A possible workaround is to make the application non-distributable:
{noformat}
git checkout non-distributable{noformat}
build & deploy again like above. Repeat the test. Everything just works but, of course, the sessions are not persisted and in production there would be no session failover.
I could stay with the old security subsystem (like "jaspitest"). But I really like elytron better and words like "dummy" in a production configuration are kind of scary.
That's not much of an issue. But I liked the feeling that I could just redeploy an application or restart a server during normal work hours instead of waiting until midnight or so.
What is also interesting: it only seems to affect jaspic/jsr375 enabled applications. We have one application using form authentication backed by an ldap realm which doesen't seem to have this problem.
was:
The problem is reproducible with just one server by making the session store persistent.
My production setup is rather complex so I've created a tiny project just to show the effect: [https://github.com/andrejkolontai/jaspic-elytron-distributed-demo]
First, get a fresh wildfly distribution (version 20.0.0.Final) and unpack it.
Start it with standalone.sh.
Then, using jboss-cli.sh make the session store persistent:
{{[standalone@localhost:9990 /] /subsystem=infinispan/cache-container=web/local-cache=passivation/store=file:add(passivation=false,purge=false)}}
{{{}}
{{ "outcome" => "success",}}
{{ "response-headers" => {}}
{{ "operation-requires-reload" => true,}}
{{ "process-state" => "reload-required"}}
{{ }}}
{{}}}{{[standalone@localhost:9990 /] reload}}
Then create an elytron security domain and connect it to undertow:
{{[standalone@localhost:9990 /] /subsystem=elytron/security-domain=elytronjaspic:add}}
{{{"outcome" => "success"}}}{{[standalone@localhost:9990 /] /subsystem=undertow/application-security-domain=elytronjaspic:add(integrated-jaspi=false,security-domain=elytronjaspic)}}
{{{"outcome" => "success"}}}
The demo project has a servlet, a session scoped cdi bean (counts the requests in a session) an a rather trivial authenticator which uses AutoApplySession.
To build it, use the gradle wrapper:
{{./gradlew war}}
The repository has three tags to see the difference between old security subsystem and elytron.
First, the old security subsystem to ses how it's used to work:
{{dahup@rudy:~/git-projects-gradle/trvial-jaspic-webapp1$ git checkout old-security }}
{{Previous HEAD position was 6dad6c3 Changed security domain to the elytron one}}
{{HEAD is now at 547cff7 First Commmit}}
{{dahup@rudy:~/git-projects-gradle/trvial-jaspic-webapp1$ ./gradlew war}}{{BUILD SUCCESSFUL in 1s}}
{{2 actionable tasks: 1 executed, 1 up-to-date}}
{{dahup@rudy:~/git-projects-gradle/trvial-jaspic-webapp1$ cp build/libs/jaspic.war ~/devel/wildfly-20.0.0.Final/standalone/deployments/}}
Verify that the authentication mechanism kicks in:
{{curl -w '\n' -c cookies -b cookies localhost:8080/jaspic/hallo}}
{{<html><head><title>Error</title></head><body>Unauthorized</body></html>}}
call with authentication credentials:
{{curl -w '\n' -c cookies -b cookies -H "secret: shampoo" localhost:8080/jaspic/hallo}}
{{Hallo Welt 0}}
verify that the authentication state is stored in the session (call without secret):
{{curl -w '\n' -c cookies -b cookies localhost:8080/jaspic/hallo}}
{{Hallo Welt 1}}
reload/restart wildfly
verify the session has survived the reload:
curl -w '\n' -c cookies -b cookies localhost:8080/jaspic/hallo
Hallo Welt 2
Now, switch to elytron by changing the security domain:
{{ git checkout elytron-security}}
build & deploy like above
Now do the same procedure but clear the cookies first:
{{dahup@rudy:~$ rm cookies}}
{{dahup@rudy:~$ curl -w '\n' -c cookies -b cookies localhost:8080/jaspic/hallo}}
{{<html><head><title>Error</title></head><body>Unauthorized</body></html>}}
{{dahup@rudy:~$ curl -w '\n' -c cookies -b cookies -H "secret: shampoo" localhost:8080/jaspic/hallo}}
{{Hallo Welt 0}}
At this point you should see wildfly throwing exceptions. My demo application seems to work. But my production application would stop working. And the sessions are not actually persisted. One more effect in production: when a server is restarted, it takes a very long time for it to come back again because the running server is struggling to serialize the session data which is not possible while the restarting server is waiting for the cached session data to arrive. After a timeout, the affected applications would just go into .failed.
A possible workaround is to make the application non-distributable:
{{git checkout non-distributable}}
build & deploy again like above. Repeat the test. Everything just works but, of course, the sessions are not persisted and in production there would be no session failover.
I could stay with the old security subsystem (like "jaspitest"). But I really like elytron better and words like "dummy" in a production configuration are kind of scary.
That's not much of an issue. But I liked the feeling that I could just redeploy an application or restart a server during normal work hours instead of waiting until midnight or so.
What is also interesting: it only seems to affect jaspic/jsr375 enabled applications. We have one application using form authentication backed by an ldap realm which doesen't seem to have this problem.
> Elytron: org.wildfly.security.auth.server.SecurityIdentity not Serializable
> ---------------------------------------------------------------------------
>
> Key: WFLY-13619
> URL: https://issues.redhat.com/browse/WFLY-13619
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 20.0.0.Final
> Reporter: Andrej Kolontai
> Assignee: Darran Lofthouse
> Priority: Minor
>
> Since the old security subsystem has been deprecated for a while I decided to move my applications to elytron which worked just fine up to the point where I tried to migrate an application that is:
> * distributed
> * uses Jaspic in form of a JSR375 HttpAuthenticationMechanism which has {{@AutoApplySession }}
> In the logs I see stacktraces like this:
> {{09:37:22,045 WARN [org.infinispan.PERSISTENCE] (default task-1) ISPN000559: Cannot marshall 'class org.infinispan.marshall.protostream.impl.MarshallableUserObject': java.io.NotSerializableException: org.wildfly.security.auth.server.SecurityIdentity}}
> {{ at org.jboss.marshalling.river@2.0.9.Final//org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:272)}}
> {{ at org.jboss.marshalling.river@2.0.9.Final//org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1141)}}
> {{ at org.jboss.marshalling.river@2.0.9.Final//org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1099)}}
> {{ at org.jboss.marshalling.river@2.0.9.Final//org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:266)}}
> {{ at org.jboss.marshalling@2.0.9.Final//org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:58)}}
> {{ at org.jboss.marshalling@2.0.9.Final//org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:111)}}
> {{.....}}
> {{Caused by: an exception which occurred:}}
> {{ in field org.wildfly.elytron.web.undertow.server.servlet.ServletSecurityContextImpl$IdentityContainer.securityIdentity}}
> {{ in object org.wildfly.elytron.web.undertow.server.servlet.ServletSecurityContextImpl$IdentityContainer@7bf2af9a}}
> {{ in object org.wildfly.elytron.web.undertow.server.servlet.ServletSecurityContextImpl$IdentityContainer@7bf2af9a}}
> {{ in object java.util.concurrent.ConcurrentHashMap@d02a9ca2}}
> {{ in object org.wildfly.clustering.marshalling.jboss.SimpleMarshalledValue@d02a9ca2}}
>
> Looks to me like it's trying to serialize the session to replicate it to the other nodes in the cluster and fails because the user identity, which is part of the session because of AutoApplySession, is not serializable. I have checked the source and it is really not serializable.
>
> I had no problems with the old security subsystem (i.e. jaspitest).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 11 months
[JBoss JIRA] (WFLY-13619) Elytron: org.wildfly.security.auth.server.SecurityIdentity not Serializable
by Andrej Kolontai (Jira)
Andrej Kolontai created WFLY-13619:
--------------------------------------
Summary: Elytron: org.wildfly.security.auth.server.SecurityIdentity not Serializable
Key: WFLY-13619
URL: https://issues.redhat.com/browse/WFLY-13619
Project: WildFly
Issue Type: Bug
Components: Security
Affects Versions: 20.0.0.Final
Reporter: Andrej Kolontai
Assignee: Darran Lofthouse
Since the old security subsystem has been deprecated for a while I decided to move my applications to elytron which worked just fine up to the point where I tried to migrate an application that is:
* distributed
* uses Jaspic in form of a JSR375 HttpAuthenticationMechanism which has {{@AutoApplySession }}
In the logs I see stacktraces like this:
{{09:37:22,045 WARN [org.infinispan.PERSISTENCE] (default task-1) ISPN000559: Cannot marshall 'class org.infinispan.marshall.protostream.impl.MarshallableUserObject': java.io.NotSerializableException: org.wildfly.security.auth.server.SecurityIdentity}}
{{ at org.jboss.marshalling.river@2.0.9.Final//org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:272)}}
{{ at org.jboss.marshalling.river@2.0.9.Final//org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1141)}}
{{ at org.jboss.marshalling.river@2.0.9.Final//org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1099)}}
{{ at org.jboss.marshalling.river@2.0.9.Final//org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:266)}}
{{ at org.jboss.marshalling@2.0.9.Final//org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:58)}}
{{ at org.jboss.marshalling@2.0.9.Final//org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:111)}}
{{.....}}
{{Caused by: an exception which occurred:}}
{{ in field org.wildfly.elytron.web.undertow.server.servlet.ServletSecurityContextImpl$IdentityContainer.securityIdentity}}
{{ in object org.wildfly.elytron.web.undertow.server.servlet.ServletSecurityContextImpl$IdentityContainer@7bf2af9a}}
{{ in object org.wildfly.elytron.web.undertow.server.servlet.ServletSecurityContextImpl$IdentityContainer@7bf2af9a}}
{{ in object java.util.concurrent.ConcurrentHashMap@d02a9ca2}}
{{ in object org.wildfly.clustering.marshalling.jboss.SimpleMarshalledValue@d02a9ca2}}
Looks to me like it's trying to serialize the session to replicate it to the other nodes in the cluster and fails because the user identity, which is part of the session because of AutoApplySession, is not serializable. I have checked the source and it is really not serializable.
I had no problems with the old security subsystem (i.e. jaspitest).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 11 months
[JBoss JIRA] (DROOLS-5455) DMN editor paste enumeration values in text area with one value per line
by Matteo Mortari (Jira)
Matteo Mortari created DROOLS-5455:
--------------------------------------
Summary: DMN editor paste enumeration values in text area with one value per line
Key: DROOLS-5455
URL: https://issues.redhat.com/browse/DROOLS-5455
Project: Drools
Issue Type: Feature Request
Components: DMN Editor
Reporter: Matteo Mortari
Assignee: Guilherme Gomes
This is about AllowedValues for ItemDefinition.
Currently a general Expression text area is available, and user can place some Comma-separated-values in it, which the editor can handle and transform into Enumeration.
This feature request is pitching for something different.
In the Enumeration view, have a text area input modal dialog which would accept one value per line. This way the modeler can copy-paste from Excel (column) in the editor to facilitate the load of the business data dictionary
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 11 months
[JBoss JIRA] (WFCORE-5004) TlsTestCase#testReloadTrustManager fails on IBM Java 8
by Ricardo Martin Camarero (Jira)
[ https://issues.redhat.com/browse/WFCORE-5004?page=com.atlassian.jira.plug... ]
Ricardo Martin Camarero edited comment on WFCORE-5004 at 6/25/20 3:34 AM:
--------------------------------------------------------------------------
[~szaldana] Please check JBEAP-19679, I was also looking into this issue. There are three solutions for this, I prefer the second one, but you can use the {{getName()}} too.
I have realized that the PR is merged, but the same issue happens in {{KeyStoresTestCase.java}} (and it's not fixed because that tests doesn't work because it's affected by mock-server issue too). So I'm adding the new mock-server issue as related to this JIRA.
was (Author: rhn-support-rmartinc):
[~szaldana] Please check JBEAP-19679, I was also looking into this issue. There are three solutions for this, I prefer the second one, but you can use the {{getName()}} too. But there is a second issue with the mock-server right now. I'm adding that the new issue blocks this JIRA.
> TlsTestCase#testReloadTrustManager fails on IBM Java 8
> ------------------------------------------------------
>
> Key: WFCORE-5004
> URL: https://issues.redhat.com/browse/WFCORE-5004
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 13.0.0.Beta1
> Reporter: Ondrej Kotek
> Assignee: Sonia Zaldana
> Priority: Major
> Fix For: 13.0.0.Beta1
>
>
> TlsTestCase#testReloadTrustManager fails on IBM Java 8 at [TlsTestCase.java#L439|https://github.com/wildfly/wildfly-core/blob/master...] reporting the same DN. When I try to compare using canonical names, there is a difference. Using RFC1779 or RFC2253 names is ok.
> {noformat}
> Assert.assertEquals(originalFoundDN.getIssuerX500Principal().getName(X500Principal.CANONICAL), ISSUER_DN.getName(X500Principal.CANONICAL));
> [ERROR] TlsTestCase.testReloadTrustManager:439 expected:<....2.840.113549.1.9.1=[#1613656c7974726f6e4077696c64666c792e6f7267],c=uk,st=elytron,cn=...> but was:<....2.840.113549.1.9.1=[elytron@wildfly.org],c=uk,st=elytron,cn=...>
> {noformat}
> Is it just a test issue, or can there be an impact on functionality? In case it's just a test issue, can we assert equality of names? I.e.
> {noformat}
> Assert.assertEquals(originalFoundDN.getIssuerX500Principal().getName(), ISSUER_DN.getName());
> {noformat}
> The same for [TlsTestCase.java#L465|https://github.com/wildfly/wildfly-core/blob/master...] then.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 11 months
[JBoss JIRA] (WFCORE-5004) TlsTestCase#testReloadTrustManager fails on IBM Java 8
by Ricardo Martin Camarero (Jira)
[ https://issues.redhat.com/browse/WFCORE-5004?page=com.atlassian.jira.plug... ]
Ricardo Martin Camarero commented on WFCORE-5004:
-------------------------------------------------
[~szaldana] Please check JBEAP-19679, I was also looking into this issue. There are three solutions for this, I prefer the second one, but you can use the {{getName()}} too. But there is a second issue with the mock-server right now. I'm adding that the new issue blocks this JIRA.
> TlsTestCase#testReloadTrustManager fails on IBM Java 8
> ------------------------------------------------------
>
> Key: WFCORE-5004
> URL: https://issues.redhat.com/browse/WFCORE-5004
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 13.0.0.Beta1
> Reporter: Ondrej Kotek
> Assignee: Sonia Zaldana
> Priority: Major
> Fix For: 13.0.0.Beta1
>
>
> TlsTestCase#testReloadTrustManager fails on IBM Java 8 at [TlsTestCase.java#L439|https://github.com/wildfly/wildfly-core/blob/master...] reporting the same DN. When I try to compare using canonical names, there is a difference. Using RFC1779 or RFC2253 names is ok.
> {noformat}
> Assert.assertEquals(originalFoundDN.getIssuerX500Principal().getName(X500Principal.CANONICAL), ISSUER_DN.getName(X500Principal.CANONICAL));
> [ERROR] TlsTestCase.testReloadTrustManager:439 expected:<....2.840.113549.1.9.1=[#1613656c7974726f6e4077696c64666c792e6f7267],c=uk,st=elytron,cn=...> but was:<....2.840.113549.1.9.1=[elytron@wildfly.org],c=uk,st=elytron,cn=...>
> {noformat}
> Is it just a test issue, or can there be an impact on functionality? In case it's just a test issue, can we assert equality of names? I.e.
> {noformat}
> Assert.assertEquals(originalFoundDN.getIssuerX500Principal().getName(), ISSUER_DN.getName());
> {noformat}
> The same for [TlsTestCase.java#L465|https://github.com/wildfly/wildfly-core/blob/master...] then.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 11 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)
Ricardo Martin Camarero created WFCORE-5023:
-----------------------------------------------
Summary: 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
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)
3 years, 11 months
[JBoss JIRA] (DROOLS-3125) [DMN Designer][Edge] Cancel data type edit operation throws an error
by Tomas David (Jira)
[ https://issues.redhat.com/browse/DROOLS-3125?page=com.atlassian.jira.plug... ]
Tomas David closed DROOLS-3125.
-------------------------------
Resolution: Won't Do
Closing this as there is currently no plan to support Edge browser.
> [DMN Designer][Edge] Cancel data type edit operation throws an error
> --------------------------------------------------------------------
>
> Key: DROOLS-3125
> URL: https://issues.redhat.com/browse/DROOLS-3125
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Environment: Windows, Edge
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools, edge
> Attachments: Screenshot from 2018-10-12 10-42-53.png
>
>
> If user tries to cancel data type edit operation, the unexpected error dialog appears and contains this error message:
> *Uncaught exception: Exception caught: (Error) : Could not complete the operation due to error 800a025e. Caused by: (Error) : Could not complete the operation due to error 800a025e.*
> Occurs just on Microsoft Edge
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 11 months
[JBoss JIRA] (DROOLS-5454) Please bring back the IDE-based 'Guided Rule Editor'
by Rick Wagner (Jira)
Rick Wagner created DROOLS-5454:
-----------------------------------
Summary: 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: Kris Verlaenen
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)
3 years, 11 months