[JBoss JIRA] (WFLY-9140) Elytron API doesn't work in JSPs
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9140?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-9140:
---------------------------------
Assignee: Tomaz Cerar (was: Stuart Douglas)
> Elytron API doesn't work in JSPs
> --------------------------------
>
> Key: WFLY-9140
> URL: https://issues.jboss.org/browse/WFLY-9140
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Reporter: Josef Cacek
> Assignee: Tomaz Cerar
> Priority: Blocker
>
> Elytron dependencies seems to be missing on Jasper classpath, so usage of Elytron API in JSPs can lead to ClassNotFound issues.
> I have following JSP:
> {code:jsp}
> <%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" session="false"%>
> <%
> final java.util.concurrent.Callable<String> callable = () -> {
> return "test";
> };
> System.out.println(org.wildfly.security.auth.client.AuthenticationContext.captureCurrent().runCallable(callable));
> %>
> {code}
> But its deployment fails due to CNF during compilation. The Jasper is missing Contextual class from wildfly-common.
> {noformat}
> 13:44:56,380 ERROR [io.undertow.request] (default task-7) UT005023: Exception handling request to /authenticator/: org.apache.jasper.JasperException: JBWEB004062: Unable to compile class for JSP:
> JBWEB004060: An error occurred at line: 8 in the jsp file: /index.jsp
> The type org.wildfly.common.context.Contextual cannot be resolved. It is indirectly referenced from required .class files
> 5: return "test";
> 6: };
> 7:
> 8: System.out.println(org.wildfly.security.auth.client.AuthenticationContext.captureCurrent().runCallable(callable));
> 9: %>
> 10:
> JBWEB004060: An error occurred at line: 8 in the jsp file: /index.jsp
> The method runCallable(Callable<String>) is undefined for the type AuthenticationContext
> 5: return "test";
> 6: };
> 7:
> 8: System.out.println(org.wildfly.security.auth.client.AuthenticationContext.captureCurrent().runCallable(callable));
> 9: %>
> 10:
> Stacktrace:
> at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:95)
> at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:198)
> at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:449)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:359)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
> at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.lambda$handleRequest$1(ElytronRunAsHandler.java:68)
> at org.wildfly.security.auth.server.FlexibleIdentityAssociation.runAsFunctionEx(FlexibleIdentityAssociation.java:101)
> at org.wildfly.security.auth.server.Scoped.runAsFunctionEx(Scoped.java:150)
> at org.wildfly.security.auth.server.Scoped.runAs(Scoped.java:62)
> at org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.handleRequest(ElytronRunAsHandler.java:67)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This is a similar problem (in modules dependencies) as we already have reported for Maven dependencies in JBEAP-10893.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (JGRP-2140) Replace Table with RingBuffer in UNICAST3 and NAKACK2
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2140?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2140:
--------------------------------
Blocking - as mentioned above - is a showstopper, so RingBuffer cannot be used in its current implementation.
However, perhaps RingBuffer can be augmented to grow when its capacity has been exceeded? To prevent RingBuffers with large capacities, they could also be compacted every now and then...
Such a feature should be configurable: {{off}} means we have a bounded RingBuffer with adders blocking when the capacity has been reached, and {{on}} would enable the automatic resizing of the buffer size.
> Replace Table with RingBuffer in UNICAST3 and NAKACK2
> -----------------------------------------------------
>
> Key: JGRP-2140
> URL: https://issues.jboss.org/browse/JGRP-2140
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.x
>
>
> Table does allocate memory on resizing or compaction; whereas RingBuffer doesn't. Replacing Table with RingBuffer might bring memory allocation rates even further down.
> However, using RingBuffer as message store means that the capacity is fixed; when the RingBuffer is full, sender threads would have to block as messages cannot be dropped.
> However, blocking is something that should be done in a flow control protocol, such as {{UFC}} or {{MFC}}, and some applications might choose completely non-blocking flow control, e.g. {{UFC_NB}} or {{MFC_NB}}, and blocking in {{UNICAST3}} or {{NAKACK2}} would move part of the blocking/non-blocking aspect away from the flow control protocols.
> Measure the impact on performance. Table is a critical class used by NAKACK2 and UNICAST3, and is battle tested. Do this only if the benefits trump the risk.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (JGRP-2140) Replace Table with RingBuffer in UNICAST3 and NAKACK2
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2140?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2140:
---------------------------
Description:
Table does allocate memory on resizing or compaction; whereas RingBuffer doesn't. Replacing Table with RingBuffer might bring memory allocation rates even further down.
However, using RingBuffer as message store means that the capacity is fixed; when the RingBuffer is full, sender threads would have to block as messages cannot be dropped.
However, blocking is something that should be done in a flow control protocol, such as {{UFC}} or {{MFC}}, and some applications might choose completely non-blocking flow control, e.g. {{UFC_NB}} or {{MFC_NB}}, and blocking in {{UNICAST3}} or {{NAKACK2}} would move part of the blocking/non-blocking aspect away from the flow control protocols.
Measure the impact on performance. Table is a critical class used by NAKACK2 and UNICAST3, and is battle tested. Do this only if the benefits trump the risk.
was:
Table does allocate memory on resizing or compaction; whereas RingBuffer doesn't. Replacing Table with RingBuffer might bring memory allocation rates even further down.
However, using RingBuffer as message store means that the capacity is fixed; when the RingBuffer is full, sender threads would have to block as messages cannot be dropped. Blocking is actually something that should be done in a flow control protocol, such as {{UFC}} or {{MFC}}, and some applications might choose completely non-blocking flow control, e.g. {{UFC_NB}} or {{MFC_NB}}, and blocking in {{UNICAST3}} or {{NAKACK2}} would move part of the blocking/non-blocking aspect away from the flow control protocols.
Measure the impact on performance. Table is a critical class used by NAKACK2 and UNICAST3, and is battle tested. Do this only if the benefits trump the risk.
> Replace Table with RingBuffer in UNICAST3 and NAKACK2
> -----------------------------------------------------
>
> Key: JGRP-2140
> URL: https://issues.jboss.org/browse/JGRP-2140
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.x
>
>
> Table does allocate memory on resizing or compaction; whereas RingBuffer doesn't. Replacing Table with RingBuffer might bring memory allocation rates even further down.
> However, using RingBuffer as message store means that the capacity is fixed; when the RingBuffer is full, sender threads would have to block as messages cannot be dropped.
> However, blocking is something that should be done in a flow control protocol, such as {{UFC}} or {{MFC}}, and some applications might choose completely non-blocking flow control, e.g. {{UFC_NB}} or {{MFC_NB}}, and blocking in {{UNICAST3}} or {{NAKACK2}} would move part of the blocking/non-blocking aspect away from the flow control protocols.
> Measure the impact on performance. Table is a critical class used by NAKACK2 and UNICAST3, and is battle tested. Do this only if the benefits trump the risk.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (JGRP-2140) Replace Table with RingBuffer in UNICAST3 and NAKACK2
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2140?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2140:
---------------------------
Description:
Table does allocate memory on resizing or compaction; whereas RingBuffer doesn't. Replacing Table with RingBuffer might bring memory allocation rates even further down.
However, using RingBuffer as message store means that the capacity is fixed; when the RingBuffer is full, sender threads would have to block as messages cannot be dropped. Blocking is actually something that should be done in a flow control protocol, such as {{UFC}} or {{MFC}}, and some applications might choose completely non-blocking flow control, e.g. {{UFC_NB}} or {{MFC_NB}}, and blocking in {{UNICAST3}} or {{NAKACK2}} would move part of the blocking/non-blocking aspect away from the flow control protocols.
Measure the impact on performance. Table is a critical class used by NAKACK2 and UNICAST3, and is battle tested. Do this only if the benefits trump the risk.
was:
Table does allocate memory on resizing or compaction; whereas RingBuffer doesn't. Replacing Table with RingBuffer might bring memory allocation rates even further down.
However, using RingBuffer as message store means that the capacity is fixed; when the RingBuffer is full, messages would get dropped. This should not be a big issue as they will get retransmitted anyway, and flow control should actually kick in to throttle senders (this is done now, to prevent Table from growing out of bounds).
Measure the impact on performance. Table is a critical class used by NAKACK2 and UNICAST3, and is battle tested. Do this only if the benefits trump the risk.
> Replace Table with RingBuffer in UNICAST3 and NAKACK2
> -----------------------------------------------------
>
> Key: JGRP-2140
> URL: https://issues.jboss.org/browse/JGRP-2140
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.x
>
>
> Table does allocate memory on resizing or compaction; whereas RingBuffer doesn't. Replacing Table with RingBuffer might bring memory allocation rates even further down.
> However, using RingBuffer as message store means that the capacity is fixed; when the RingBuffer is full, sender threads would have to block as messages cannot be dropped. Blocking is actually something that should be done in a flow control protocol, such as {{UFC}} or {{MFC}}, and some applications might choose completely non-blocking flow control, e.g. {{UFC_NB}} or {{MFC_NB}}, and blocking in {{UNICAST3}} or {{NAKACK2}} would move part of the blocking/non-blocking aspect away from the flow control protocols.
> Measure the impact on performance. Table is a critical class used by NAKACK2 and UNICAST3, and is battle tested. Do this only if the benefits trump the risk.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (DROOLS-1680) Maven plugin for unmanaged KIE Server deployments
by Maciej Swiderski (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1680?page=com.atlassian.jira.plugi... ]
Maciej Swiderski reassigned DROOLS-1680:
----------------------------------------
Assignee: Maciej Swiderski (was: Edson Tirelli)
> Maven plugin for unmanaged KIE Server deployments
> -------------------------------------------------
>
> Key: DROOLS-1680
> URL: https://issues.jboss.org/browse/DROOLS-1680
> Project: Drools
> Issue Type: Feature Request
> Components: kie server
> Affects Versions: 7.1.0.Final
> Reporter: Michael Reynolds
> Assignee: Maciej Swiderski
> Priority: Minor
>
> It would be nice to be able to manage KIE Server deployments to unmanaged KIE servers via a Maven plugin. At the moment you need to rely on bash scripts and/or ant tasks to use the REST API.
> It would be very helpful for when deployments are required to be done via a CI/CD pipeline in Jenkins etc...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFLY-9142) Smoke failover test for modcluster subsystem
by Matus Madzin (JIRA)
Matus Madzin created WFLY-9142:
----------------------------------
Summary: Smoke failover test for modcluster subsystem
Key: WFLY-9142
URL: https://issues.jboss.org/browse/WFLY-9142
Project: WildFly
Issue Type: Enhancement
Components: mod_cluster, Test Suite, Web (Undertow)
Affects Versions: 11.0.0.Alpha1
Reporter: Matus Madzin
Assignee: Matus Madzin
Priority: Critical
Add smoke fail over test for modcluser subsystem and undertow which is not covered at the moment in AS TS. Basic test scenario which shows that modcluster works which should be a part of this testsuite.
One balancer + two workers and check whether request is redirected to the second node when the original node stops responding.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months