[JBoss JIRA] (WFLY-4204) Add predicate support for response-header filter
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4204?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-4204:
-----------------------------------
as you can see in stack trace predicate put into account (see PredicateHandler in stacktrace) and problem is with your regular expression which fails the matcher.
> Add predicate support for response-header filter
> ------------------------------------------------
>
> Key: WFLY-4204
> URL: https://issues.jboss.org/browse/WFLY-4204
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Dino Tsoumakis
> Assignee: Stuart Douglas
> Priority: Minor
>
> gzip filter has predicate support. response-header filter seems to ignore predicates.
> It would be great to add predicate support to the response-header filter in the same way as it is working for gzip filter. Thus it would be possible to set response-header values dependent on other header values. This is interesting for setting a correct "Vary:" header value.
> If using the predicate
> {code}
> predicate="regex[pattern='(?:application/javascript|text/css|text/html)(;.*)?', value=%{o,Content-Type}, full-match=true]"
> {code}
> for filter-ref of a response-header filter request result in a 500 error producing the following stack trace in the log:
> {code}
> ^[[0m^[[31m17:05:15,286 ERROR [io.undertow.request] (default I/O-1) Blocking request failed HttpServerExchange{ GET /}: java.lang.NullPointerException
> at java.util.regex.Matcher.getTextLength(Matcher.java:1283) [rt.jar:1.8.0_25]
> at java.util.regex.Matcher.reset(Matcher.java:309) [rt.jar:1.8.0_25]
> at java.util.regex.Matcher.<init>(Matcher.java:229) [rt.jar:1.8.0_25]
> at java.util.regex.Pattern.matcher(Pattern.java:1093) [rt.jar:1.8.0_25]
> at io.undertow.predicate.RegularExpressionPredicate.resolve(RegularExpressionPredicate.java:41)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:24)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:66)
> at io.undertow.server.handlers.RequestLimit.handleRequest(RequestLimit.java:103)
> at io.undertow.server.handlers.RequestLimitingHandler.handleRequest(RequestLimitingHandler.java:81)
> at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:57)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:43)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:156)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:91)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:45)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (WFLY-4204) Add predicate support for response-header filter
by Dino Tsoumakis (JIRA)
[ https://issues.jboss.org/browse/WFLY-4204?page=com.atlassian.jira.plugin.... ]
Dino Tsoumakis updated WFLY-4204:
---------------------------------
Description:
gzip filter has predicate support. response-header filter seems to ignore predicates.
It would be great to add predicate support to the response-header filter in the same way as it is working for gzip filter. Thus it would be possible to set response-header values dependent on other header values. This is interesting for setting a correct "Vary:" header value.
If using the predicate
{code}
predicate="regex[pattern='(?:application/javascript|text/css|text/html)(;.*)?', value=%{o,Content-Type}, full-match=true]"
{code}
for filter-ref of a response-header filter request result in a 500 error producing the following stack trace in the log:
{code}
^[[0m^[[31m17:05:15,286 ERROR [io.undertow.request] (default I/O-1) Blocking request failed HttpServerExchange{ GET /}: java.lang.NullPointerException
at java.util.regex.Matcher.getTextLength(Matcher.java:1283) [rt.jar:1.8.0_25]
at java.util.regex.Matcher.reset(Matcher.java:309) [rt.jar:1.8.0_25]
at java.util.regex.Matcher.<init>(Matcher.java:229) [rt.jar:1.8.0_25]
at java.util.regex.Pattern.matcher(Pattern.java:1093) [rt.jar:1.8.0_25]
at io.undertow.predicate.RegularExpressionPredicate.resolve(RegularExpressionPredicate.java:41)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:24)
at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:66)
at io.undertow.server.handlers.RequestLimit.handleRequest(RequestLimit.java:103)
at io.undertow.server.handlers.RequestLimitingHandler.handleRequest(RequestLimitingHandler.java:81)
at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:57)
at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:43)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:156)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:91)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:45)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
{code}
was:
gzip filter has predicate support. response-header filter seems to ignore predicates.
It would be great to add predicate support to the response-header filter in the same way as it is working for gzip filter. Thus it would be possible to set response-header values dependent on other header values. This is interesting for setting a correct "Vary:" header value.
If using predicate for filter-ref of a response-header filter request result in a 500 error producing the following stack trace in the log:
{code}
^[[0m^[[31m17:05:15,286 ERROR [io.undertow.request] (default I/O-1) Blocking request failed HttpServerExchange{ GET /}: java.lang.NullPointerException
at java.util.regex.Matcher.getTextLength(Matcher.java:1283) [rt.jar:1.8.0_25]
at java.util.regex.Matcher.reset(Matcher.java:309) [rt.jar:1.8.0_25]
at java.util.regex.Matcher.<init>(Matcher.java:229) [rt.jar:1.8.0_25]
at java.util.regex.Pattern.matcher(Pattern.java:1093) [rt.jar:1.8.0_25]
at io.undertow.predicate.RegularExpressionPredicate.resolve(RegularExpressionPredicate.java:41)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:24)
at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:66)
at io.undertow.server.handlers.RequestLimit.handleRequest(RequestLimit.java:103)
at io.undertow.server.handlers.RequestLimitingHandler.handleRequest(RequestLimitingHandler.java:81)
at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:57)
at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:43)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:156)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:91)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:45)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
{code}
> Add predicate support for response-header filter
> ------------------------------------------------
>
> Key: WFLY-4204
> URL: https://issues.jboss.org/browse/WFLY-4204
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Dino Tsoumakis
> Assignee: Stuart Douglas
> Priority: Minor
>
> gzip filter has predicate support. response-header filter seems to ignore predicates.
> It would be great to add predicate support to the response-header filter in the same way as it is working for gzip filter. Thus it would be possible to set response-header values dependent on other header values. This is interesting for setting a correct "Vary:" header value.
> If using the predicate
> {code}
> predicate="regex[pattern='(?:application/javascript|text/css|text/html)(;.*)?', value=%{o,Content-Type}, full-match=true]"
> {code}
> for filter-ref of a response-header filter request result in a 500 error producing the following stack trace in the log:
> {code}
> ^[[0m^[[31m17:05:15,286 ERROR [io.undertow.request] (default I/O-1) Blocking request failed HttpServerExchange{ GET /}: java.lang.NullPointerException
> at java.util.regex.Matcher.getTextLength(Matcher.java:1283) [rt.jar:1.8.0_25]
> at java.util.regex.Matcher.reset(Matcher.java:309) [rt.jar:1.8.0_25]
> at java.util.regex.Matcher.<init>(Matcher.java:229) [rt.jar:1.8.0_25]
> at java.util.regex.Pattern.matcher(Pattern.java:1093) [rt.jar:1.8.0_25]
> at io.undertow.predicate.RegularExpressionPredicate.resolve(RegularExpressionPredicate.java:41)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:24)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:66)
> at io.undertow.server.handlers.RequestLimit.handleRequest(RequestLimit.java:103)
> at io.undertow.server.handlers.RequestLimitingHandler.handleRequest(RequestLimitingHandler.java:81)
> at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:57)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:43)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:156)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:91)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:45)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (WFLY-4204) Add predicate support for response-header filter
by Dino Tsoumakis (JIRA)
[ https://issues.jboss.org/browse/WFLY-4204?page=com.atlassian.jira.plugin.... ]
Dino Tsoumakis updated WFLY-4204:
---------------------------------
Description:
gzip filter has predicate support. response-header filter seems to ignore predicates.
It would be great to add predicate support to the response-header filter in the same way as it is working for gzip filter. Thus it would be possible to set response-header values dependent on other header values. This is interesting for setting a correct "Vary:" header value.
If using predicate for filter-ref of a response-header filter request result in a 500 error producing the following stack trace in the log:
{code}
^[[0m^[[31m17:05:15,286 ERROR [io.undertow.request] (default I/O-1) Blocking request failed HttpServerExchange{ GET /}: java.lang.NullPointerException
at java.util.regex.Matcher.getTextLength(Matcher.java:1283) [rt.jar:1.8.0_25]
at java.util.regex.Matcher.reset(Matcher.java:309) [rt.jar:1.8.0_25]
at java.util.regex.Matcher.<init>(Matcher.java:229) [rt.jar:1.8.0_25]
at java.util.regex.Pattern.matcher(Pattern.java:1093) [rt.jar:1.8.0_25]
at io.undertow.predicate.RegularExpressionPredicate.resolve(RegularExpressionPredicate.java:41)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:24)
at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:66)
at io.undertow.server.handlers.RequestLimit.handleRequest(RequestLimit.java:103)
at io.undertow.server.handlers.RequestLimitingHandler.handleRequest(RequestLimitingHandler.java:81)
at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:57)
at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:43)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:156)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:91)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:45)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
{code}
was:
gzip filter has predicate support. response-header filter seems to ignore predicates.
It would be great to add predicate support to the response-header filter in the same way as it is working for gzip filter. Thus it would be possible to set response-header values dependent on other header values. This is interesting for setting a correct "Vary:" header value.
> Add predicate support for response-header filter
> ------------------------------------------------
>
> Key: WFLY-4204
> URL: https://issues.jboss.org/browse/WFLY-4204
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Dino Tsoumakis
> Assignee: Stuart Douglas
> Priority: Minor
>
> gzip filter has predicate support. response-header filter seems to ignore predicates.
> It would be great to add predicate support to the response-header filter in the same way as it is working for gzip filter. Thus it would be possible to set response-header values dependent on other header values. This is interesting for setting a correct "Vary:" header value.
> If using predicate for filter-ref of a response-header filter request result in a 500 error producing the following stack trace in the log:
> {code}
> ^[[0m^[[31m17:05:15,286 ERROR [io.undertow.request] (default I/O-1) Blocking request failed HttpServerExchange{ GET /}: java.lang.NullPointerException
> at java.util.regex.Matcher.getTextLength(Matcher.java:1283) [rt.jar:1.8.0_25]
> at java.util.regex.Matcher.reset(Matcher.java:309) [rt.jar:1.8.0_25]
> at java.util.regex.Matcher.<init>(Matcher.java:229) [rt.jar:1.8.0_25]
> at java.util.regex.Pattern.matcher(Pattern.java:1093) [rt.jar:1.8.0_25]
> at io.undertow.predicate.RegularExpressionPredicate.resolve(RegularExpressionPredicate.java:41)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:24)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:66)
> at io.undertow.server.handlers.RequestLimit.handleRequest(RequestLimit.java:103)
> at io.undertow.server.handlers.RequestLimitingHandler.handleRequest(RequestLimitingHandler.java:81)
> at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:57)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:43)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:156)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:91)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:45)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (WFLY-4204) Add predicate support for response-header filter
by Dino Tsoumakis (JIRA)
Dino Tsoumakis created WFLY-4204:
------------------------------------
Summary: Add predicate support for response-header filter
Key: WFLY-4204
URL: https://issues.jboss.org/browse/WFLY-4204
Project: WildFly
Issue Type: Feature Request
Components: Web (Undertow)
Affects Versions: 8.2.0.Final
Reporter: Dino Tsoumakis
Assignee: Stuart Douglas
Priority: Minor
gzip filter has predicate support. response-header filter seems to ignore predicates.
It would be great to add predicate support to the response-header filter in the same way as it is working for gzip filter. Thus it would be possible to set response-header values dependent on other header values. This is interesting for setting a correct "Vary:" header value.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (WFLY-4198) NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB
by Sergiy Barlabanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-4198?page=com.atlassian.jira.plugin.... ]
Sergiy Barlabanov commented on WFLY-4198:
-----------------------------------------
Yes, we are setting some variables into MDC in the thread, when our code is executed. But the exception above comes from the Wildfly code executed in the thread pool used for async EJB execution before our code is called. And LogDiagnosticContextRecoveryInterceptor is called before any application code is executed so there is no chance to put anything into MDC before LogDiagnosticContextRecoveryInterceptor is called.
> NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-4198
> URL: https://issues.jboss.org/browse/WFLY-4198
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.2.0.Final
> Reporter: Sergiy Barlabanov
> Assignee: David Lloyd
>
> When trying to call an asynchronous EJB in a Web application using slf4j (1.7.5+) & logback(1.0.13+) for logging the following NullPointerException occurs (see below).
> The problem is in the line 67 of LogDiagnosticContextRecoveryInterceptor class, when it tries to access MDC map, which is null. According to SLF4J API the copy of MDC map may be null: see the javadoc of org.slf4j.MDC#getCopyOfContextMap.
> So LogDiagnosticContextRecoveryInterceptor or org.jboss.logging.Slf4jLoggerProvider have to check the map for null.
> Currently there is no workaround for that :(.
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$2.runInvocation(AsyncFutureInterceptorFactory.java:97)
> at org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (REMJMX-92) Fix HTTPS Protocol
by Philippe Marschall (JIRA)
Philippe Marschall created REMJMX-92:
----------------------------------------
Summary: Fix HTTPS Protocol
Key: REMJMX-92
URL: https://issues.jboss.org/browse/REMJMX-92
Project: Remoting JMX
Issue Type: Patch
Components: Connection
Affects Versions: 2.0.1.CR1
Reporter: Philippe Marschall
Assignee: Darran Lofthouse
The HTTPS protocol (https-remoting-jmx) is currently not working because of a broken protocol check.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (WFLY-3723) setting the local to english in CLI commands on non-english systems does not produce english output
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3723?page=com.atlassian.jira.plugin.... ]
Romain Pelisse commented on WFLY-3723:
--------------------------------------
Ok, I've found out the root cause. The issue is that when one ask for en_US, it does find any bundled resources with this prefix - because this is considered the default (hence no appropriate extension):
$ find . -name "LocalDescriptions*" | grep org.jboss.as.pojo.LocalDescriptions
./pojo/src/main/resources/org/jboss/as/pojo/LocalDescriptions_de.properties
./pojo/src/main/resources/org/jboss/as/pojo/LocalDescriptions_fr.properties
./pojo/src/main/resources/org/jboss/as/pojo/LocalDescriptions.properties ==> This one contains 'en_US' but not the extension
....
However, as default is French (or German), when ask specifically for en_US, no bundle is found, and the JDK falls back to the default Locale (FR or DE), not English.
IMHO, the best way to fix that would be to modify the build to copy './pojo/src/main/resources/org/jboss/as/pojo/LocalDescriptions.properties' into ./pojo/src/main/resources/org/jboss/as/pojo/LocalDescriptions.properties_en'. There would be duplication, but only in the generated artefact, and it does sound less cumbersome than having to modify Wildfly code to handle this 'edge cases'.
Or maybe someone has a better idea ?
> setting the local to english in CLI commands on non-english systems does not produce english output
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-3723
> URL: https://issues.jboss.org/browse/WFLY-3723
> Project: WildFly
> Issue Type: Bug
> Components: Localization
> Affects Versions: 8.1.0.Final
> Environment: Tested on MacOS running in German
> Reporter: Tom Fonteyne
> Assignee: Romain Pelisse
> Priority: Minor
>
> A German (or french etc...) system must be used to reproduce.
> It is likely this is not limited to MacOS, but I do not have a non-english Linux system available
> An out of the box install of wildfly/EAP:
> Without configuration, the log file is in German as expected.
> Using these CLI comands:
> :read-operation-description(name=stop-servers,locale=de_DE) -> german
> :read-operation-description(name=stop-servers,locale=en_US) -> german
> :read-operation-description(name=stop-servers,locale=fr_FR) -> french
> So we cannot get the CLI to produce english output
> when configuring JAVA_OPTS in domain.conf with:
> JAVA_OPTS="$JAVA_OPTS -Duser.language=en -Duser.country=DE -Duser.encoding=utf-8
> The log is now in English -> works as expected; and:
> :read-operation-description(name=stop-servers,locale=de_DE) -> german
> :read-operation-description(name=stop-servers,locale=en_US) -> english
> So it seems we have a bug where the locale set to start the domain takes precedence over the locale set in the CLI command (but only when English is asked)
> I presume this is because English is the default locale.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (WFLY-4198) NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-4198?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on WFLY-4198:
------------------------------------
I haven't looked at this, but since you note that this is blocking your application usage without any workaround, have you tried explicitly setting something into the MDC using whatever logging framework you are using? Or is there no chance you can do this because this happens on an async EJB invocation thread even before it gets to the point where you can set something?
> NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-4198
> URL: https://issues.jboss.org/browse/WFLY-4198
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.2.0.Final
> Reporter: Sergiy Barlabanov
> Assignee: David Lloyd
>
> When trying to call an asynchronous EJB in a Web application using slf4j (1.7.5+) & logback(1.0.13+) for logging the following NullPointerException occurs (see below).
> The problem is in the line 67 of LogDiagnosticContextRecoveryInterceptor class, when it tries to access MDC map, which is null. According to SLF4J API the copy of MDC map may be null: see the javadoc of org.slf4j.MDC#getCopyOfContextMap.
> So LogDiagnosticContextRecoveryInterceptor or org.jboss.logging.Slf4jLoggerProvider have to check the map for null.
> Currently there is no workaround for that :(.
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$2.runInvocation(AsyncFutureInterceptorFactory.java:97)
> at org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (WFLY-4198) NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-4198?page=com.atlassian.jira.plugin.... ]
jaikiran pai updated WFLY-4198:
-------------------------------
Issue Type: Bug (was: Feature Request)
> NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-4198
> URL: https://issues.jboss.org/browse/WFLY-4198
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.2.0.Final
> Reporter: Sergiy Barlabanov
> Assignee: David Lloyd
>
> When trying to call an asynchronous EJB in a Web application using slf4j (1.7.5+) & logback(1.0.13+) for logging the following NullPointerException occurs (see below).
> The problem is in the line 67 of LogDiagnosticContextRecoveryInterceptor class, when it tries to access MDC map, which is null. According to SLF4J API the copy of MDC map may be null: see the javadoc of org.slf4j.MDC#getCopyOfContextMap.
> So LogDiagnosticContextRecoveryInterceptor or org.jboss.logging.Slf4jLoggerProvider have to check the map for null.
> Currently there is no workaround for that :(.
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$2.runInvocation(AsyncFutureInterceptorFactory.java:97)
> at org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months