[JBoss JIRA] (WFLY-12776) JBoss_Keycloak_"404 - Not Found"
by Naga Vijayapuram (Jira)
[ https://issues.jboss.org/browse/WFLY-12776?page=com.atlassian.jira.plugin... ]
Naga Vijayapuram commented on WFLY-12776:
-----------------------------------------
Resolved by making the module name in web.xml match the webapp name ...
<module-name>hello</module-name>
> JBoss_Keycloak_"404 - Not Found"
> --------------------------------
>
> Key: WFLY-12776
> URL: https://issues.jboss.org/browse/WFLY-12776
> Project: WildFly
> Issue Type: Bug
> Reporter: Naga Vijayapuram
> Assignee: Brian Stansberry
> Priority: Major
> Attachments: hello.war, kc.json
>
>
> ==============
> Environment -
> ==============
> . OS -
> $ sw_vers
> ProductName: Mac OS X
> ProductVersion: 10.14.5
> BuildVersion: 18F132
> . JBoss EAP 7.1
> . Keycloak 7.0.1
> ==============
> Issue -
> ==============
> Getting "404 - Not Found" for a simple hello.war (with KEYCLOAK as the auth-method in its web.xml) when accessing http://localhost:8080/hello
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (DROOLS-4449) Visual design enhancements: Scenario/DMN error overlays
by Brian Dellascio (Jira)
[ https://issues.jboss.org/browse/DROOLS-4449?page=com.atlassian.jira.plugi... ]
Brian Dellascio commented on DROOLS-4449:
-----------------------------------------
Hi [~tirelli], I was under the assumption they all were, but the last two were the newest additions to the stack. I also realized this morning that I hadn't uploaded the updates to the first mockup. I've done that and it's up-to-date now. Apologies for the confusion.
CC [~uxdlc]
> Visual design enhancements: Scenario/DMN error overlays
> -------------------------------------------------------
>
> Key: DROOLS-4449
> URL: https://issues.jboss.org/browse/DROOLS-4449
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor, Scenario Simulation and Testing
> Reporter: Elizabeth Clayton
> Assignee: Brian Dellascio
> Priority: Major
> Labels: ScenarioSimulation, Stunner, UX, UXTeam, drools-tools
> Attachments: ban-solid.svg, check-circle-regular.svg, check-circle-solid.svg, exclamation-circle-regular.svg, exclamation-circle-solid.svg
>
>
> Scenario and DMN editors share design solutions for displaying errors in graphs (models) and grids (scenario test, dmn boxed expressions.) Support design consistency where applicable, while also documenting unique solutions per context.
> Verification conditions:
> - Review interaction design wireframes and click-thrus to offer recommendations for a consistent presentation for error overlays for the two editors (Scenario and DMN)
> - Wireframes posted at: https://issues.jboss.org/browse/DROOLS-4257 and https://issues.jboss.org/browse/DROOLS-3953.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (DROOLS-4771) Fix validation for background/wrong dmn scesim files
by Gabriele Cardosi (Jira)
Gabriele Cardosi created DROOLS-4771:
----------------------------------------
Summary: Fix validation for background/wrong dmn scesim files
Key: DROOLS-4771
URL: https://issues.jboss.org/browse/DROOLS-4771
Project: Drools
Issue Type: Bug
Reporter: Gabriele Cardosi
Assignee: Gabriele Cardosi
Validation should be enabled also for background data.
Beside that, when importing a scesim file related to a missing dmn, the validation on import should fail (currently is does not)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (WFLY-12798) Using Smallrye HealthChecks in RequestScoped Beans
by Florian Sailer (Jira)
Florian Sailer created WFLY-12798:
-------------------------------------
Summary: Using Smallrye HealthChecks in RequestScoped Beans
Key: WFLY-12798
URL: https://issues.jboss.org/browse/WFLY-12798
Project: WildFly
Issue Type: Bug
Components: MP Health
Affects Versions: 18.0.0.Final
Reporter: Florian Sailer
Assignee: Jeff Mesnil
2019-11-15 15:26:11,717 ERROR [org.wildfly.extension.microprofile.health.smallrye] (management I/O-1) Error processing Health Checks: org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:647)
at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:164)
at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:131)
at at.arz.bpe.boundary.PingCheck$Proxy$_$$_WeldClientProxy.call(Unknown Source)
at org.wildfly.extension.microprofile.health.HealthReporter.jsonObject(HealthReporter.java:120)
at org.wildfly.extension.microprofile.health.HealthReporter.fillCheck(HealthReporter.java:107)
at org.wildfly.extension.microprofile.health.HealthReporter.processChecks(HealthReporter.java:96)
at org.wildfly.extension.microprofile.health.HealthReporter.getHealth(HealthReporter.java:79)
at org.wildfly.extension.microprofile.health.HealthReporter.getHealth(HealthReporter.java:60)
at org.wildfly.extension.microprofile.health.HealthContextService$HealthCheckHandler.handleRequest(HealthContextService.java:100)
at org.jboss.as.domain.http.server.security.RealmReadinessHandler.handleRequest(RealmReadinessHandler.java:51)
at org.jboss.as.domain.http.server.security.ServerErrorReadinessHandler.handleRequest(ServerErrorReadinessHandler.java:35)
at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:91)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:211)
at io.undertow.server.handlers.cache.CacheHandler.handleRequest(CacheHandler.java:92)
at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
at org.jboss.as.domain.http.server.ManagementHttpRequestHandler.handleRequest(ManagementHttpRequestHandler.java:57)
at org.jboss.as.domain.http.server.cors.CorsHttpHandler.handleRequest(CorsHttpHandler.java:75)
at org.jboss.as.domain.http.server.ManagementHttpServer$UpgradeFixHandler.handleRequest(ManagementHttpServer.java:666)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:162)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:100)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:57)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:132)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
MP-Health Spec doesnt enforce a scope and it worked with wildfly 17.0.0.1-Final.
https://github.com/eclipse/microprofile-health/issues/109
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (WFWIP-160) Fix throughput and response time differences between TLS 1.2 and TLS 1.3
by Farah Juma (Jira)
[ https://issues.jboss.org/browse/WFWIP-160?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFWIP-160:
----------------------------------
[~jstourac] +1, support for TLS 1.3 in {{wildfly-openssl}} should be a separate issue.
> Fix throughput and response time differences between TLS 1.2 and TLS 1.3
> ------------------------------------------------------------------------
>
> Key: WFWIP-160
> URL: https://issues.jboss.org/browse/WFWIP-160
> Project: WildFly WIP
> Issue Type: Task
> Components: Web (Undertow)
> Reporter: Farah Juma
> Assignee: Richard Opalka
> Priority: Blocker
> Attachments: jstourac-report.zip, results-tlsv12.zip, results-tlsv13.zip
>
>
> Performance with TLS 1.3 on WildFly appears to be worse than with TLS 1.2. In particular, throughput is much lower (roughly three times lower) and response time is much higher (roughly three times higher), which is not supposed to be the case. The underlying issue seems to be in Undertow or XNIO, that is the code that actually gets invoked during the TLS handshake process. Looking at CPU time, there is significantly more time being spent in [io.undertow.protocols.ssl.SslConduit$5.run()|https://github.com/undertow-...] with TLS 1.3 than with TLS 1.2.
> Steps to reproduce (taken from EAP7-1022):
> 1. Build WildFly using the following feature branches or download a QE build of WildFly [here|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/undertow-...]:
> https://github.com/fjuma/wildfly-elytron/tree/ELY-1706
> https://github.com/fjuma/wildfly-core/tree/WFCORE-4172 (Update the Elytron version in the pom.xml file to use the version built in the previous step)
> https://github.com/fjuma/wildfly/tree/WFCORE-4172 (Update the Core version in the pom.xml file to use the version built in the previous step)
> 2. Download and unzip JMeter from https://jmeter.apache.org/download_jmeter.cgi
> 3. Download attached test plan [TLSv1.3.jmx|https://issues.jboss.org/secure/attachment/12449098/12449098_...]
> 4. Configure and start server with TLSv1.3 and JDK 11:
> {code}
> connect
> /subsystem=elytron/key-store=tls13:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
> /subsystem=elytron/key-store=tls13:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
> /subsystem=elytron/key-store=tls13:store()
> /subsystem=elytron/key-manager=tls13:add(key-store=tls13,credential-reference={clear-text=secret})
> /subsystem=elytron/server-ssl-context=tls13:add(key-manager=tls13,protocols=["TLSv1.3"])
> batch
> /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
> /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=tls13)
> run-batch
> reload
> {code}
> 5. Start jmeter with JDK 11 and downloaded test plan
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv13.log -o results-tlsv13
> {code}
> 6. Set server to use TLSv1.2
> {code}
> /subsystem=elytron/server-ssl-context=tls13:write-attribute(name=protocols,value=["TLSv1.2"])
> reload
> {code}
> 7. Repeat same for TLSv1.2
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv12.log -o results-tlsv12
> {code}
> 8. Compare results (there will be an index.html file in the results-tlsv12 and results-tlsv13 directories)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (DROOLS-3677) [DMN Designer] Change tabs order
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3677?page=com.atlassian.jira.plugi... ]
Michael Anstis reassigned DROOLS-3677:
--------------------------------------
Sprint: 2019 Week 47-49 (from Nov 18)
Assignee: Michael Anstis (was: Guilherme Gomes)
> [DMN Designer] Change tabs order
> --------------------------------
>
> Key: DROOLS-3677
> URL: https://issues.jboss.org/browse/DROOLS-3677
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Guilherme Gomes
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
>
> Currently the tabs in the DMN editor are being shown like this:
> *Model | Overview | Data Types | Included Models*
> And the expected result is:
> *Model | Data Types | Included Models | Overview*
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months
[JBoss JIRA] (WFWIP-160) Fix throughput and response time differences between TLS 1.2 and TLS 1.3
by Jan Stourac (Jira)
[ https://issues.jboss.org/browse/WFWIP-160?page=com.atlassian.jira.plugin.... ]
Jan Stourac commented on WFWIP-160:
-----------------------------------
{quote}
Out of curiosity, I'm gonna perform similar check also for wildfly-openssl security provider and post my findings here too.
{quote}
Actually, I am unable to configure the {{openssl}} provider with TLSv1.3 protocol as I get NoSuchAlgorithmException in the server.log:
{code}
15:04:06,137 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.security.ssl-context.tls13: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.tls13: java.security.NoSuchAlgorithmException: ELY04001: No algorithm found matching TLS/SSL protocol selection criteria
at org.wildfly.extension.elytron.SSLDefinitions$6.lambda$getValueSupplier$1(SSLDefinitions.java:1202)
at org.wildfly.extension.elytron.SSLDefinitions$6$$Lambda$496.000000000D370DC0.get(Unknown Source)
at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.base/java.lang.Thread.run(Thread.java:831)
Caused by: java.security.NoSuchAlgorithmException: ELY04001: No algorithm found matching TLS/SSL protocol selection criteria
at org.wildfly.security.ssl.SSLUtils.throwIt(SSLUtils.java:166)
at org.wildfly.security.ssl.SSLUtils$$Lambda$607.000000000A5A3540.create(Unknown Source)
at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:339)
at org.wildfly.security.ssl.SSLContextBuilder$$Lambda$602.000000000A581CA0.create(Unknown Source)
at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:53)
at org.wildfly.extension.elytron.SSLDefinitions$6.lambda$getValueSupplier$1(SSLDefinitions.java:1200)
... 10 more
{code}
This helped me to realize that EAP7-1022 RFE is meant to be for JSSE only, see [comment here|https://issues.jboss.org/browse/EAP7-1022?focusedCommentId=13708349&...]. Truth is that TLSv1.3 protocol has been implemented into 'wildfly-openssl' library in the meantime, so from technical point of view, this should be possible to make it work... although, that should be a separate issue, though.
> Fix throughput and response time differences between TLS 1.2 and TLS 1.3
> ------------------------------------------------------------------------
>
> Key: WFWIP-160
> URL: https://issues.jboss.org/browse/WFWIP-160
> Project: WildFly WIP
> Issue Type: Task
> Components: Web (Undertow)
> Reporter: Farah Juma
> Assignee: Richard Opalka
> Priority: Blocker
> Attachments: jstourac-report.zip, results-tlsv12.zip, results-tlsv13.zip
>
>
> Performance with TLS 1.3 on WildFly appears to be worse than with TLS 1.2. In particular, throughput is much lower (roughly three times lower) and response time is much higher (roughly three times higher), which is not supposed to be the case. The underlying issue seems to be in Undertow or XNIO, that is the code that actually gets invoked during the TLS handshake process. Looking at CPU time, there is significantly more time being spent in [io.undertow.protocols.ssl.SslConduit$5.run()|https://github.com/undertow-...] with TLS 1.3 than with TLS 1.2.
> Steps to reproduce (taken from EAP7-1022):
> 1. Build WildFly using the following feature branches or download a QE build of WildFly [here|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/undertow-...]:
> https://github.com/fjuma/wildfly-elytron/tree/ELY-1706
> https://github.com/fjuma/wildfly-core/tree/WFCORE-4172 (Update the Elytron version in the pom.xml file to use the version built in the previous step)
> https://github.com/fjuma/wildfly/tree/WFCORE-4172 (Update the Core version in the pom.xml file to use the version built in the previous step)
> 2. Download and unzip JMeter from https://jmeter.apache.org/download_jmeter.cgi
> 3. Download attached test plan [TLSv1.3.jmx|https://issues.jboss.org/secure/attachment/12449098/12449098_...]
> 4. Configure and start server with TLSv1.3 and JDK 11:
> {code}
> connect
> /subsystem=elytron/key-store=tls13:add(path=keystore.jks,relative-to=jboss.server.config.dir,credential-reference={clear-text=secret},type=JKS)
> /subsystem=elytron/key-store=tls13:generate-key-pair(alias=localhost,algorithm=RSA,key-size=1024,validity=365,credential-reference={clear-text=secret},distinguished-name="CN=localhost")
> /subsystem=elytron/key-store=tls13:store()
> /subsystem=elytron/key-manager=tls13:add(key-store=tls13,credential-reference={clear-text=secret})
> /subsystem=elytron/server-ssl-context=tls13:add(key-manager=tls13,protocols=["TLSv1.3"])
> batch
> /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
> /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=tls13)
> run-batch
> reload
> {code}
> 5. Start jmeter with JDK 11 and downloaded test plan
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv13.log -o results-tlsv13
> {code}
> 6. Set server to use TLSv1.2
> {code}
> /subsystem=elytron/server-ssl-context=tls13:write-attribute(name=protocols,value=["TLSv1.2"])
> reload
> {code}
> 7. Repeat same for TLSv1.2
> {code}
> export JAVA_HOME=/path/to/java/openjdk-11.0.2; bin/jmeter -n -t TLSv1.3.jmx -e -l tlsv12.log -o results-tlsv12
> {code}
> 8. Compare results (there will be an index.html file in the results-tlsv12 and results-tlsv13 directories)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 8 months