[JBoss JIRA] (DROOLS-3731) DMN UX - More info overlaid on models.
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3731?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton updated DROOLS-3731:
--------------------------------------
Attachment: (was: graph-test-click.png)
> DMN UX - More info overlaid on models.
> --------------------------------------
>
> Key: DROOLS-3731
> URL: https://issues.jboss.org/browse/DROOLS-3731
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: Test-errorB.png, download (1).png, download.png
>
>
> As a practitioner, there are situations where I need to show additional information about a model... for instance: test coverage report: I need to draw a model and color code the nodes to show which nodes were executed by tests, or which rows on a DT were a match. Or when I execute a single test, what was the actual value of a given node or expression.
> Note: Maybe in read-only mode with an "overlay" on top of the model the additional metadata information. See process instance diagram design examples.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-3997) [DMN Designer] Included Model Name marshalling issues depending on imported model name
by Daniel José dos Santos (Jira)
[ https://issues.jboss.org/browse/DROOLS-3997?page=com.atlassian.jira.plugi... ]
Daniel José dos Santos commented on DROOLS-3997:
------------------------------------------------
[~tirelli] I think I've found the issue. Just making some tests before update the PR.
> [DMN Designer] Included Model Name marshalling issues depending on imported model name
> --------------------------------------------------------------------------------------
>
> Key: DROOLS-3997
> URL: https://issues.jboss.org/browse/DROOLS-3997
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.22.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2019-05-10 08-20-54.png, Screenshot from 2019-05-10 08-28-42.png, connect-imported-error.log, connect-imported-node.webm, routes-v2.log, routes-v2.zip, routes.zip
>
>
> There is issue in marshalling, if the included model name contains *whitespace* character. In such case xml editor is opened instead of the dmn editor. See the attached picture and steps to reproduce for more details.
> Issue spotted during review of DROOLS-3720 and DROOLS-3721. However it is probably not related.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFCORE-4132) LogManager stops any logging output after changing "encoding" attribute to file-handler
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-4132?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-4132:
----------------------------------
Fix Version/s: 7.0.0.Alpha4
> LogManager stops any logging output after changing "encoding" attribute to file-handler
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-4132
> URL: https://issues.jboss.org/browse/WFCORE-4132
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Masafumi Miura
> Assignee: James Perkins
> Priority: Major
> Fix For: 7.0.0.Alpha4
>
>
> When setting "encoding" attribute on the file handler (file-handler, periodic-rotating-file-handler, size-rotating-file-handler, and periodic-size-rotating-file-handler) in CLI, LogManager throw the following error message in the console log and stops any logging output to the file-handler.
> Note that the stack trace below "org.jboss.logmanager.Logger.logRaw(Logger.java:850)" can differ. It looks like this error just happens on the first logging output after the configuration change.
> Even after executing ":reload" the instance via CLI, no log message are output to the file-handler. The instance needs to restart to output the file-handler.
> {code}
> LogManager error of type FLUSH_FAILURE: Error on flush
> java.io.IOException: Stream Closed
> at java.io.FileOutputStream.writeBytes(Native Method)
> at java.io.FileOutputStream.write(FileOutputStream.java:326)
> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at java.io.BufferedWriter.flush(BufferedWriter.java:254)
> at org.jboss.logmanager.handlers.WriterHandler.safeFlush(WriterHandler.java:170)
> at org.jboss.logmanager.handlers.WriterHandler.flush(WriterHandler.java:139)
> at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:105)
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:67)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:77)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:333)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> at org.jboss.logmanager.Logger.log(Logger.java:802)
> at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> at org.jboss.logging.Logger.logf(Logger.java:2398)
> at org.jboss.as.mail.extension.MailLogger_$logger.unboundMailSession(MailLogger_$logger.java:42)
> at org.jboss.as.mail.extension.MailSessionAdd$1.handleEvent(MailSessionAdd.java:150)
> at org.jboss.msc.service.ServiceControllerImpl$LifecycleListenerTask.execute(ServiceControllerImpl.java:1857)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFCORE-4132) LogManager stops any logging output after changing "encoding" attribute to file-handler
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-4132?page=com.atlassian.jira.plugi... ]
James Perkins resolved WFCORE-4132.
-----------------------------------
Resolution: Done
> LogManager stops any logging output after changing "encoding" attribute to file-handler
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-4132
> URL: https://issues.jboss.org/browse/WFCORE-4132
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Masafumi Miura
> Assignee: James Perkins
> Priority: Major
> Fix For: 7.0.0.Alpha4
>
>
> When setting "encoding" attribute on the file handler (file-handler, periodic-rotating-file-handler, size-rotating-file-handler, and periodic-size-rotating-file-handler) in CLI, LogManager throw the following error message in the console log and stops any logging output to the file-handler.
> Note that the stack trace below "org.jboss.logmanager.Logger.logRaw(Logger.java:850)" can differ. It looks like this error just happens on the first logging output after the configuration change.
> Even after executing ":reload" the instance via CLI, no log message are output to the file-handler. The instance needs to restart to output the file-handler.
> {code}
> LogManager error of type FLUSH_FAILURE: Error on flush
> java.io.IOException: Stream Closed
> at java.io.FileOutputStream.writeBytes(Native Method)
> at java.io.FileOutputStream.write(FileOutputStream.java:326)
> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at java.io.BufferedWriter.flush(BufferedWriter.java:254)
> at org.jboss.logmanager.handlers.WriterHandler.safeFlush(WriterHandler.java:170)
> at org.jboss.logmanager.handlers.WriterHandler.flush(WriterHandler.java:139)
> at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:105)
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:67)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:77)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:333)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> at org.jboss.logmanager.Logger.log(Logger.java:802)
> at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> at org.jboss.logging.Logger.logf(Logger.java:2398)
> at org.jboss.as.mail.extension.MailLogger_$logger.unboundMailSession(MailLogger_$logger.java:42)
> at org.jboss.as.mail.extension.MailSessionAdd$1.handleEvent(MailSessionAdd.java:150)
> at org.jboss.msc.service.ServiceControllerImpl$LifecycleListenerTask.execute(ServiceControllerImpl.java:1857)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-3997) [DMN Designer] Included Model Name marshalling issues depending on imported model name
by Daniel José dos Santos (Jira)
[ https://issues.jboss.org/browse/DROOLS-3997?page=com.atlassian.jira.plugi... ]
Daniel José dos Santos commented on DROOLS-3997:
------------------------------------------------
I'm checking.
> [DMN Designer] Included Model Name marshalling issues depending on imported model name
> --------------------------------------------------------------------------------------
>
> Key: DROOLS-3997
> URL: https://issues.jboss.org/browse/DROOLS-3997
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.22.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2019-05-10 08-20-54.png, Screenshot from 2019-05-10 08-28-42.png, connect-imported-error.log, connect-imported-node.webm, routes-v2.log, routes-v2.zip, routes.zip
>
>
> There is issue in marshalling, if the included model name contains *whitespace* character. In such case xml editor is opened instead of the dmn editor. See the attached picture and steps to reproduce for more details.
> Issue spotted during review of DROOLS-3720 and DROOLS-3721. However it is probably not related.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-7395) Allow to provide deployment dependency to JNDI resource
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-7395?page=com.atlassian.jira.plugin.... ]
Radoslav Husar reassigned WFLY-7395:
------------------------------------
Assignee: Brian Stansberry (was: Jason Greene)
> Allow to provide deployment dependency to JNDI resource
> -------------------------------------------------------
>
> Key: WFLY-7395
> URL: https://issues.jboss.org/browse/WFLY-7395
> Project: WildFly
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 10.1.0.Final
> Reporter: Miroslav Novak
> Assignee: Brian Stansberry
> Priority: Major
> Labels: user_experience
>
> For JBoss AS 6 there was ejb annotation @org.jboss.annotation.ejb.Depends which allowed to set dependency to JNDI resource. Currently there seems to be no replacement in Wildfly 10.x
> For example if EJB contains dependency to queue registered in JNDI:
> {code}
> @Resource(mappedName = "java:/jms/queue/OutQueue")
> private Queue outQueue;
> {code}
> then it would not get deployed when OutQueue is not present. Purpose of this feature request is to add possibility to provide such dependency in the way as @org.jboss.annotation.ejb.Depends did.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11007) Using OpenShift generated certificates and client auth cause TLS errors
by Hiroyuki Wada (Jira)
[ https://issues.jboss.org/browse/WFLY-11007?page=com.atlassian.jira.plugin... ]
Hiroyuki Wada edited comment on WFLY-11007 at 5/23/19 12:30 PM:
----------------------------------------------------------------
Hi!
I'm also encountering this same issue with Keycloak 6.0.1 on Docker without OpenShift. Also I use letsencrypt for the server certificate (Client side is self-signed certificate).
In my case, I encountered this error when I used Google Chrome 75.0.3770.52 (beta) or curl 7.58.0 from my PC. MS IE or Edge were OK. Also, curl 7.61.1 from the keycloak server was OK. So it might depend on the client-side?
When I switched the loglevel to DEBUG, WildFly wrote following log. I hope that it will be a hint for investigating the cause.
{noformat}
keycloak_1 | 16:09:13,386 DEBUG [io.undertow.request] (default I/O-2) UT005013: An IOException occurred: javax.net.ssl.SSLException: Received fatal alert: record_overflow
keycloak_1 | at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
keycloak_1 | at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1647)
keycloak_1 | at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1615)
keycloak_1 | at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1781)
keycloak_1 | at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1070)
keycloak_1 | at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:896)
keycloak_1 | at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:766)
keycloak_1 | at io.undertow.protocols.ssl.ALPNHackSSLEngine.unwrap(ALPNHackSSLEngine.java:265)
keycloak_1 | at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
keycloak_1 | at io.undertow.server.protocol.http.ALPNLimitingSSLEngine.unwrap(ALPNLimitingSSLEngine.java:75)
keycloak_1 | at io.undertow.protocols.ssl.SslConduit.doUnwrap(SslConduit.java:757)
keycloak_1 | at io.undertow.protocols.ssl.SslConduit.doHandshake(SslConduit.java:648)
keycloak_1 | at io.undertow.protocols.ssl.SslConduit.access$900(SslConduit.java:63)
keycloak_1 | at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1136)
keycloak_1 | at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
keycloak_1 | at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
{noformat}
was (Author: wadahiro):
Hi!
I'm also encountering this same issue with Keycloak 6.0.1 on Docker without OpenShift. Also I use letsencrypt for the server certificate (Client side is self-signed certificate).
In my case, I encountered this error when I used Google Chrome 75.0.3770.52 (beta) or curl 7.58.0 from my PC. MS IE or Edge were OK. Also, curl 7.61.1 from the keycloak server was OK. So it might depends on the client-side?
When I switched the loglevel to DEBUG, WildFly wrote following log. I hope that it will be a hint for investigating the cause.
{noformat}
keycloak_1 | 16:09:13,386 DEBUG [io.undertow.request] (default I/O-2) UT005013: An IOException occurred: javax.net.ssl.SSLException: Received fatal alert: record_overflow
keycloak_1 | at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
keycloak_1 | at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1647)
keycloak_1 | at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1615)
keycloak_1 | at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1781)
keycloak_1 | at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1070)
keycloak_1 | at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:896)
keycloak_1 | at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:766)
keycloak_1 | at io.undertow.protocols.ssl.ALPNHackSSLEngine.unwrap(ALPNHackSSLEngine.java:265)
keycloak_1 | at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
keycloak_1 | at io.undertow.server.protocol.http.ALPNLimitingSSLEngine.unwrap(ALPNLimitingSSLEngine.java:75)
keycloak_1 | at io.undertow.protocols.ssl.SslConduit.doUnwrap(SslConduit.java:757)
keycloak_1 | at io.undertow.protocols.ssl.SslConduit.doHandshake(SslConduit.java:648)
keycloak_1 | at io.undertow.protocols.ssl.SslConduit.access$900(SslConduit.java:63)
keycloak_1 | at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1136)
keycloak_1 | at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
keycloak_1 | at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
{noformat}
> Using OpenShift generated certificates and client auth cause TLS errors
> -----------------------------------------------------------------------
>
> Key: WFLY-11007
> URL: https://issues.jboss.org/browse/WFLY-11007
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 13.0.0.Final
> Reporter: Sebastian Laskawiec
> Assignee: Stuart Douglas
> Priority: Major
>
> h2. Summary
> It seems that when using OpenShift generated certificates and client auth (with {{want-client-auth="true"}}) the TLS handshake fails with {{RECV TLSv1.2 ALERT: fatal, record_overflow}} message.
> h2. Explanation
> I'm using {{oc cluster up}} and deploying Keycloak (WF 13 based) on OpenShift local cluster using the (1) template. The service in the the template uses OpenShift generated certificates ({{"service.alpha.openshift.io/serving-cert-secret-name": "keycloak-x509-https-secret"}}). Both files are mounted in the Keycloak pod and translated into keystore and truststore (see the configuration after the transformation (2)). Once the pod is up and running, I'm issuing a {{curl}} command as shown in (3). {{curl}} fails saying that {{* error:1408F092:SSL routines:ssl3_get_record:data length too long}}. The server logs with TLS Handshake debugging turned on might be found here (4). As shown in the link, the server has written {{16384}} bytes.
> I also did a test with manually created certificates (5). The result might be found here (6). As shown in the link, we've written {{16050}} bytes instead of {{16384}} and the handshake was successful.
> h2. Possible solution
> Perhaps we should cut the list CAs transmitted by the server when asking for client auth when it exceeds certain number of bytes. It would be helpful to write a warn message too.
> Links:
> - (1) Keycloak OCP Template https://gist.github.com/slaskawi/57ed810a7109a02a9d884b61ce2e7f13
> - (2) Transformed configuration https://gist.github.com/slaskawi/92aead6c519b867621129b640b4a3c88
> - (3) curl command https://gist.github.com/slaskawi/3bc32b8e96c2499cb7b48c3c5cb28616
> - (4) https://gist.github.com/slaskawi/b6477fe3cd65890c879cfe6f95359450#file-lo...
> - (5) Keycloak and OpenShift integration demo https://github.com/keycloak/openshift-integration/blob/master/install-key...
> - (6) https://gist.github.com/slaskawi/7fd87e1f2e6c4faf657d9e8289ed3392#file-lo...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11007) Using OpenShift generated certificates and client auth cause TLS errors
by Hiroyuki Wada (Jira)
[ https://issues.jboss.org/browse/WFLY-11007?page=com.atlassian.jira.plugin... ]
Hiroyuki Wada commented on WFLY-11007:
--------------------------------------
Hi!
I'm also encountering this same issue with Keycloak 6.0.1 on Docker without OpenShift. Also I use letsencrypt for the server certificate (Client side is self-signed certificate).
In my case, I encountered this error when I used Google Chrome 75.0.3770.52 (beta) or curl 7.58.0 from my PC. MS IE or Edge were OK. Also, curl 7.61.1 from the keycloak server was OK. So it might depends on the client-side?
When I switched the loglevel to DEBUG, WildFly wrote following log. I hope that it will be a hint for investigating the cause.
{noformat}
keycloak_1 | 16:09:13,386 DEBUG [io.undertow.request] (default I/O-2) UT005013: An IOException occurred: javax.net.ssl.SSLException: Received fatal alert: record_overflow
keycloak_1 | at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
keycloak_1 | at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1647)
keycloak_1 | at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1615)
keycloak_1 | at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1781)
keycloak_1 | at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1070)
keycloak_1 | at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:896)
keycloak_1 | at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:766)
keycloak_1 | at io.undertow.protocols.ssl.ALPNHackSSLEngine.unwrap(ALPNHackSSLEngine.java:265)
keycloak_1 | at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
keycloak_1 | at io.undertow.server.protocol.http.ALPNLimitingSSLEngine.unwrap(ALPNLimitingSSLEngine.java:75)
keycloak_1 | at io.undertow.protocols.ssl.SslConduit.doUnwrap(SslConduit.java:757)
keycloak_1 | at io.undertow.protocols.ssl.SslConduit.doHandshake(SslConduit.java:648)
keycloak_1 | at io.undertow.protocols.ssl.SslConduit.access$900(SslConduit.java:63)
keycloak_1 | at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1136)
keycloak_1 | at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
keycloak_1 | at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
{noformat}
> Using OpenShift generated certificates and client auth cause TLS errors
> -----------------------------------------------------------------------
>
> Key: WFLY-11007
> URL: https://issues.jboss.org/browse/WFLY-11007
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 13.0.0.Final
> Reporter: Sebastian Laskawiec
> Assignee: Stuart Douglas
> Priority: Major
>
> h2. Summary
> It seems that when using OpenShift generated certificates and client auth (with {{want-client-auth="true"}}) the TLS handshake fails with {{RECV TLSv1.2 ALERT: fatal, record_overflow}} message.
> h2. Explanation
> I'm using {{oc cluster up}} and deploying Keycloak (WF 13 based) on OpenShift local cluster using the (1) template. The service in the the template uses OpenShift generated certificates ({{"service.alpha.openshift.io/serving-cert-secret-name": "keycloak-x509-https-secret"}}). Both files are mounted in the Keycloak pod and translated into keystore and truststore (see the configuration after the transformation (2)). Once the pod is up and running, I'm issuing a {{curl}} command as shown in (3). {{curl}} fails saying that {{* error:1408F092:SSL routines:ssl3_get_record:data length too long}}. The server logs with TLS Handshake debugging turned on might be found here (4). As shown in the link, the server has written {{16384}} bytes.
> I also did a test with manually created certificates (5). The result might be found here (6). As shown in the link, we've written {{16050}} bytes instead of {{16384}} and the handshake was successful.
> h2. Possible solution
> Perhaps we should cut the list CAs transmitted by the server when asking for client auth when it exceeds certain number of bytes. It would be helpful to write a warn message too.
> Links:
> - (1) Keycloak OCP Template https://gist.github.com/slaskawi/57ed810a7109a02a9d884b61ce2e7f13
> - (2) Transformed configuration https://gist.github.com/slaskawi/92aead6c519b867621129b640b4a3c88
> - (3) curl command https://gist.github.com/slaskawi/3bc32b8e96c2499cb7b48c3c5cb28616
> - (4) https://gist.github.com/slaskawi/b6477fe3cd65890c879cfe6f95359450#file-lo...
> - (5) Keycloak and OpenShift integration demo https://github.com/keycloak/openshift-integration/blob/master/install-key...
> - (6) https://gist.github.com/slaskawi/7fd87e1f2e6c4faf657d9e8289ed3392#file-lo...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-1072) Generate warning or error when Ruletemplate files specified in kmodule.xml does not exist
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-1072?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1072.
---------------------------------
Resolution: Done
Fixed by https://github.com/kiegroup/drools/commit/524fb4cd1dc153ca1decedf186d2ea2...
> Generate warning or error when Ruletemplate files specified in kmodule.xml does not exist
> -----------------------------------------------------------------------------------------
>
> Key: DROOLS-1072
> URL: https://issues.jboss.org/browse/DROOLS-1072
> Project: Drools
> Issue Type: Enhancement
> Components: decision tables
> Affects Versions: 6.4.0.Beta2
> Reporter: Alex Vincent
> Assignee: Mario Fusco
> Priority: Major
>
> When you specify a ruletemplate for a given kbase in the kmodule.xml, it does not generate a warning or an error if the template or dtable does not exist.
> For instance the following kmodule.xml:
> <?xml version="1.0" encoding="UTF-8"?>
> <kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule">
> <kbase name="KBase1" packages="process, rules, decisiontables, ruletemplates">
> <ruleTemplate dtable="decisiontables/dt_duplicate_facts.xls"
> template="ruletemplates/tpl_duplicate_facts.drt"
> row="2" col="2"/>
> <ruleTemplate dtable="doesnotexist/dt_duplicate_facts.xls"
> template="doesnotexist/tpl_duplicate_facts.drt"
> row="2" col="2"/>
> <ksession name="KSession1"/>
> </kbase>
> </kmodule>
> This does not generate an error or warning even with trace log level. The user should be notified that these files don't exist (doesnotexist/dt_duplicate_facts.xls and doesnotexist/tpl_duplicate_facts.drt).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months