December 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4675) Wrong help message in wsconsume.bat

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4675?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4675. ---------------------------- > Wrong help message in wsconsume.bat > ----------------------------------- > > Key: WFLY-4675 > URL: https://issues.jboss.org/browse/WFLY-4675 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 10.0.0.Alpha1 > Reporter: Marek Kopecký > Assignee: Marek Kopecký > Priority: Minor > Fix For: 10.0.0.Alpha5 > > > Description of problem: > Help message in wsconsume.bat contains wrong "usage" section. > How reproducible: > Always on Windows > Steps to Reproduce: > 1. wsconsume.bat -h > Actual results: > ... > usage: org.jboss.ws.tools.cmd.WSConsume [options] <wsdl-url> > ... > Expected results on Windows: > ... > usage: wsconsume.bat [options] <wsdl-url> > ... > Additional info: > On linux: > ./wsconsume.sh -h > ... > usage: wsconsume.sh [options] <wsdl-url> > ... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3642) Make length of session id configurable

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-3642?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-3642. ---------------------------- > Make length of session id configurable > -------------------------------------- > > Key: WFLY-3642 > URL: https://issues.jboss.org/browse/WFLY-3642 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 8.1.0.Final, 8.2.0.Final > Environment: any > Reporter: Jan Dittberner > Assignee: Stuart Douglas > Priority: Minor > Fix For: 10.0.0.Beta2 > > > At the moment the session ids generated by WildFly/Undertow are of a fixed length of 18 characters. The used [SecureRandomSessionIdGenerator|https://github.com/undertow-io/undertow/bl...] allows for setting a custom length but this capability is not used in WildFly yet. > It would be nice to have this capability in the [web subsystem configuration|https://docs.jboss.org/author/display/WFLY8/Undertow+(web)+...]. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3769) Implement graceful shutdown for batch tasks

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-3769?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-3769. ---------------------------- > Implement graceful shutdown for batch tasks > ------------------------------------------- > > Key: WFLY-3769 > URL: https://issues.jboss.org/browse/WFLY-3769 > Project: WildFly > Issue Type: Sub-task > Components: Batch > Reporter: Stuart Douglas > Assignee: James Perkins > Fix For: 10.0.0.Alpha4 > > > This should make sure that all batch jobs have completed before the container shuts down, and not allow new jobs to start while the container is suspended. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4598) Remove class name string from RTS subsystem

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4598?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4598. ---------------------------- > Remove class name string from RTS subsystem > ------------------------------------------- > > Key: WFLY-4598 > URL: https://issues.jboss.org/browse/WFLY-4598 > Project: WildFly > Issue Type: Task > Components: Transactions > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 10.0.0.Alpha1 > > > Replace hard coded class name string with Class.getName() -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4198) NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4198?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4198. ---------------------------- > 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: Bartosz Baranowski > Fix For: 10.0.0.Alpha6 > > Attachments: patch.diff > > > 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 :(. > {noformat} > 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) > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4623) Upgrade WildFly Arquillian from 1.0.0.Alpha5 to 1.0.0.CR1

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4623?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4623. ---------------------------- > Upgrade WildFly Arquillian from 1.0.0.Alpha5 to 1.0.0.CR1 > --------------------------------------------------------- > > Key: WFLY-4623 > URL: https://issues.jboss.org/browse/WFLY-4623 > Project: WildFly > Issue Type: Component Upgrade > Components: Test Suite > Reporter: James Perkins > Assignee: James Perkins > Fix For: 9.0.0.CR2, 10.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4729) shared-session-config_1_0.xsd description of <cache-name> is wrong

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4729?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4729. ---------------------------- > shared-session-config_1_0.xsd description of <cache-name> is wrong > ------------------------------------------------------------------ > > Key: WFLY-4729 > URL: https://issues.jboss.org/browse/WFLY-4729 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Alpha2 > Reporter: Ladislav Thon > Assignee: Stuart Douglas > Fix For: 9.0.0.CR2, 10.0.0.Alpha3 > > > As described in JBMETA-387, the {{<cache-name>}} documentation in the XSD refers to AS6 syntax. As of AS7, cache container and cache are delimited by a ".", not a "/". -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4644) enabling access-log for virtual server is not effective before server reload but CLI does not require that

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4644?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4644. ---------------------------- > enabling access-log for virtual server is not effective before server reload but CLI does not require that > ---------------------------------------------------------------------------------------------------------- > > Key: WFLY-4644 > URL: https://issues.jboss.org/browse/WFLY-4644 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.0.CR1 > Reporter: Jan Stourac > Assignee: Stuart Douglas > Fix For: 10.0.0.Alpha3 > > > When access-log is enabled for virtual host via CLI it does not want to perform server reload. But until server reload is executed logging is not enabled. When server reload is performed then logging works OK. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4589) java.lang.IllegalStateException: PBOX000048: Failed to obtain ApplicationPolicy for domain other

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4589?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4589. ---------------------------- > java.lang.IllegalStateException: PBOX000048: Failed to obtain ApplicationPolicy for domain other > ------------------------------------------------------------------------------------------------ > > Key: WFLY-4589 > URL: https://issues.jboss.org/browse/WFLY-4589 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.0.CR1 > Environment: java version "1.8.0_25" > Java(TM) SE Runtime Environment (build 1.8.0_25-b17) > Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) > cheffamille:wildfly-9.0.0.CR1 jfarcand$ > Reporter: Jeanfrancois Arcand > Assignee: Stuart Douglas > Priority: Minor > Fix For: 10.0.0.Beta1 > > > Deploy atmosphere-chat.war (download it from Maven). Deploy, use WebSockets, then shutdown Wildfly 9.0.0.CR1 > 08:47:41,792 ERROR [io.undertow.websockets.jsr.request] (default task-17) UT026006: Exception running web socket method: java.lang.IllegalStateException: PBOX000048: Failed to obtain ApplicationPolicy for domain other > at org.jboss.security.plugins.mapping.JBossMappingManager.getMappingContext(JBossMappingManager.java:67) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.setup(SecurityContextThreadSetupAction.java:110) > at io.undertow.servlet.core.CompositeThreadSetupAction.setup(CompositeThreadSetupAction.java:42) > at io.undertow.websockets.jsr.ServerWebSocketContainer.invokeEndpointMethod(ServerWebSocketContainer.java:416) > at io.undertow.websockets.jsr.ServerWebSocketContainer$3.run(ServerWebSocketContainer.java:403) > at io.undertow.websockets.jsr.OrderedExecutor$ExecutorTask.run(OrderedExecutor.java:67) > 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:745) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5188) DistributedWorkManager needs to handle unknown fork responses.

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-5188?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-5188. ---------------------------- > DistributedWorkManager needs to handle unknown fork responses. > -------------------------------------------------------------- > > Key: WFLY-5188 > URL: https://issues.jboss.org/browse/WFLY-5188 > Project: WildFly > Issue Type: Bug > Components: Clustering, JCA > Affects Versions: 10.0.0.Beta2 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 10.0.0.CR1 > > > The JGroupsTransport employed by the DistributedWorkManager uses synchronous multicasting via the RpcDispatcher. Since the JCA default configuration was modified to use fork channels, we need to ensure that it handles an exception case specific for fork channels, i.e. the case where a message is received by a node on which no such DWM exists. > As I see it, there are 2 ways we can fix this: > # Configure the RpcDispatcher with a custom response marshaller capable of recognizing unknown fork responses > # Implement a transport that leverages CommandDispatcher, which already handles this exception case. > #1 is the easiest. The only hiccup is that the RpcDispatcher field in JGroupsTransport is private, which requires reflection to access from a subclass. > #2 is probably the ideal long term solution. The DistributedWorkManager already employs a command pattern, so using CommandDispatcher is a natural fit. Using the CommandDispatcher will also simplifies marshalling/unmarshalling of the transport parameters. Additionally, using the public clustering API allows us to remove the direct dependency on org.jgroups module from the connector subsystems. The only hiccup here is that in order to optimize the marshalling of the command objects, requires the use of the marshalling API introduced as part of WFLY-5091, which, at the time of this writing, has not yet been merged into WF master. > Given the above, I suggest a 2 phase solution, where we implement #1 for now, and #2 when the missing pieces are in place. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2017