February 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1412) WILDFLY 10 : TAB-Completion in CLI doesn't work under Cygwin

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1412?page=com.atlassian.jira.plugi... ] Tomaz Cerar moved WFLY-6289 to WFCORE-1412: ------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-1412 (was: WFLY-6289) Component/s: CLI (was: CLI) Affects Version/s: 2.0.10.Final (was: 10.0.0.Final) > WILDFLY 10 : TAB-Completion in CLI doesn't work under Cygwin > ------------------------------------------------------------ > > Key: WFCORE-1412 > URL: https://issues.jboss.org/browse/WFCORE-1412 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.0.10.Final > Environment: Win7 x64, java 1.8.0_66 x64 > Reporter: Heiko Rath > Assignee: Jason Greene > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1412) WILDFLY 10 : TAB-Completion in CLI doesn't work under Cygwin

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1412?page=com.atlassian.jira.plugi... ] Tomaz Cerar reassigned WFCORE-1412: ----------------------------------- Assignee: Alexey Loubyansky (was: Jason Greene) > WILDFLY 10 : TAB-Completion in CLI doesn't work under Cygwin > ------------------------------------------------------------ > > Key: WFCORE-1412 > URL: https://issues.jboss.org/browse/WFCORE-1412 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.0.10.Final > Environment: Win7 x64, java 1.8.0_66 x64 > Reporter: Heiko Rath > Assignee: Alexey Loubyansky > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6289) WILDFLY 10 : TAB-Completion in CLI doesn't work under Cygwin

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6289?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-6289: ------------------------------ Component/s: CLI > WILDFLY 10 : TAB-Completion in CLI doesn't work under Cygwin > ------------------------------------------------------------ > > Key: WFLY-6289 > URL: https://issues.jboss.org/browse/WFLY-6289 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 10.0.0.Final > Environment: Win7 x64, java 1.8.0_66 x64 > Reporter: Heiko Rath > Assignee: Jason Greene > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6289) WILDFLY 10 : TAB-Completion in CLI doesn't work under Cygwin

by Heiko Rath (JIRA)

Heiko Rath created WFLY-6289: -------------------------------- Summary: WILDFLY 10 : TAB-Completion in CLI doesn't work under Cygwin Key: WFLY-6289 URL: https://issues.jboss.org/browse/WFLY-6289 Project: WildFly Issue Type: Bug Affects Versions: 10.0.0.Final Environment: Win7 x64, java 1.8.0_66 x64 Reporter: Heiko Rath Assignee: Jason Greene -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6288) java.lang.IllegalStateException: AMQ119116: Netty Acceptor unavailable

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-6288?page=com.atlassian.jira.plugin.... ] Jeff Mesnil moved JBEAP-3596 to WFLY-6288: ------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6288 (was: JBEAP-3596) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: JMS) (was: ActiveMQ) Target Release: (was: 7.0.0.GA) Affects Version/s: 10.0.0.Final (was: 7.0.0.ER6) Affects Testing: (was: Regression) > java.lang.IllegalStateException: AMQ119116: Netty Acceptor unavailable > ---------------------------------------------------------------------- > > Key: WFLY-6288 > URL: https://issues.jboss.org/browse/WFLY-6288 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Jeff Mesnil > Assignee: Andy Taylor > Priority: Critical > > There is regression against ER5 in failover tests during failback. > During failback backup server logs lots of errors like: > {code} > 17:57:37,163 ERROR [org.xnio.listener] (default I/O-7) XNIO001007: A channel event listener threw an exception: java.lang.IllegalStateException: AMQ119116: Netty Acceptor unavailable > at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor.transfer(NettyAcceptor.java:426) > at org.wildfly.extension.messaging.activemq.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:159) > at org.wildfly.extension.messaging.activemq.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:147) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1] > at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:149) > at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:362) > at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:228) > at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1226) > at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1503) > at io.undertow.server.Connectors.terminateResponse(Connectors.java:99) > at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197) > at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195) > at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:178) > at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:122) > at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1] > at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119) > at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1652) > at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1630) > at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:152) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:233) > at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:131) > at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:145) > at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92) > at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1] > at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1] > at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1] > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1] > at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:121) [xnio-nio-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1] > at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580) [xnio-nio-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1] > at org.xnio.nio.WorkerThread.run(WorkerThread.java:464) [xnio-nio-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1] > {code} > This issue might be related to fix for JBEAP-1527. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6288) java.lang.IllegalStateException: AMQ119116: Netty Acceptor unavailable

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-6288?page=com.atlassian.jira.plugin.... ] Jeff Mesnil reassigned WFLY-6288: --------------------------------- Assignee: Jeff Mesnil (was: Andy Taylor) > java.lang.IllegalStateException: AMQ119116: Netty Acceptor unavailable > ---------------------------------------------------------------------- > > Key: WFLY-6288 > URL: https://issues.jboss.org/browse/WFLY-6288 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Critical > > There is regression against ER5 in failover tests during failback. > During failback backup server logs lots of errors like: > {code} > 17:57:37,163 ERROR [org.xnio.listener] (default I/O-7) XNIO001007: A channel event listener threw an exception: java.lang.IllegalStateException: AMQ119116: Netty Acceptor unavailable > at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor.transfer(NettyAcceptor.java:426) > at org.wildfly.extension.messaging.activemq.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:159) > at org.wildfly.extension.messaging.activemq.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:147) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1] > at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:149) > at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:362) > at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:228) > at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1226) > at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1503) > at io.undertow.server.Connectors.terminateResponse(Connectors.java:99) > at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197) > at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195) > at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:178) > at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:122) > at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1] > at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119) > at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1652) > at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1630) > at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:152) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:233) > at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:131) > at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:145) > at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92) > at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1] > at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1] > at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1] > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1] > at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:121) [xnio-nio-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1] > at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580) [xnio-nio-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1] > at org.xnio.nio.WorkerThread.run(WorkerThread.java:464) [xnio-nio-3.3.4.Final-redhat-1.jar:3.3.4.Final-redhat-1] > {code} > This issue might be related to fix for JBEAP-1527. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-124) Add marker support

by Robert Knotek (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-124?page=com.atlassian.jira.plugin... ] Robert Knotek commented on LOGMGR-124: -------------------------------------- But JBoss Logging is not only JUL. JBoss Logging also supports for example SLF4J. And SLF4J API already supports Markers. What I am saying is that JBoss implementation of SLF4J API extends MarkerIgnoringBase. MarkerIgnoringBase is abstract class that simply throws Marker info from all calls. You are right in fact that JUL does not have Markers in API. But you don't use pure JUL. You extends JUL in ExtLogRecord, so what can be done is to add Marker into ExtLogRecord and propagate it there from APIs which already supports Markers (SLF4J). From APIs without Marker support just null can be propagated. > Add marker support > ------------------ > > Key: LOGMGR-124 > URL: https://issues.jboss.org/browse/LOGMGR-124 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Affects Versions: 2.0.2.Final > Reporter: Rob Heine > Priority: Optional > > The logging engine currently (talking about the one included in WF-9) does not support Markers (like in implementations like "logback" and/or "log4j2"). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6210) Example ec2/gossip/azure server profiles do not have any modifications from the standard HA profiles (missing proper discovery protocols)

by Ladislav Thon (JIRA)

[ https://issues.jboss.org/browse/WFLY-6210?page=com.atlassian.jira.plugin.... ] Ladislav Thon updated WFLY-6210: -------------------------------- Comment: was deleted (was: A comment with security level 'Red Hat Employee' was removed.) > Example ec2/gossip/azure server profiles do not have any modifications from the standard HA profiles (missing proper discovery protocols) > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6210 > URL: https://issues.jboss.org/browse/WFLY-6210 > Project: WildFly > Issue Type: Bug > Components: Build System > Affects Versions: 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > Fix For: 10.1.0.Final > > > {noformat} > [rhusar@syrah wildfly-10.1.0.Final-SNAPSHOT]$ diff -s standalone/configuration/standalone_xml_history/standalone-ha.initial.xml docs/examples/configs/standalone-ec2-ha.xml > Files standalone/configuration/standalone_xml_history/standalone-ha.initial.xml and docs/examples/configs/standalone-ec2-ha.xml are identical > {noformat} > {noformat} > [rhusar@syrah wildfly-10.1.0.Final-SNAPSHOT]$ diff -s standalone/configuration/standalone_xml_history/standalone-ha.initial.xml docs/examples/configs/standalone-gossip-ha.xml > Files standalone/configuration/standalone_xml_history/standalone-ha.initial.xml and docs/examples/configs/standalone-gossip-ha.xml are identical > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6287) CXFHandlerResolverImpl not threadsafe

by Bjørn Hilstad (JIRA)

Bjørn Hilstad created WFLY-6287: ----------------------------------- Summary: CXFHandlerResolverImpl not threadsafe Key: WFLY-6287 URL: https://issues.jboss.org/browse/WFLY-6287 Project: WildFly Issue Type: Bug Components: Web Services Affects Versions: 9.0.1.Final Reporter: Bjørn Hilstad Assignee: Alessio Soldano When the concurrency of handler-chain parsing increases , the following error shows up in the logs: Caused by: org.xml.sax.SAXException: FWK005 parse may not be called while parsing. at org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:260) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:298) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) at org.jboss.wsf.stack.cxf.client.serviceref.CXFHandlerResolverImpl.createHandlerChain(CXFHandlerResolverImpl.java:161) ... 132 more One case where I have seen this is when an EJB/MDB uses @WebServiceRef and @HandlerChain to get a reference to a webservice. When multiple instances of the EJB/MDB are created at the same time to handle a lot of messages this happens. It is the @HandlerChain that triggers the xml parsing and gives the error. The Xerces DocumentBuilder is not threadsafe and thus requires code to synchronize it correctly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1312) connection-url is required when dataSourceClass is provided

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1312?page=com.atlassian.jira.plugin... ] Lin Gao updated JBJCA-1312: --------------------------- Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/470 > connection-url is required when dataSourceClass is provided > ----------------------------------------------------------- > > Key: JBJCA-1312 > URL: https://issues.jboss.org/browse/JBJCA-1312 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: WildFly/IronJacamar 1.3.2.Final > Reporter: Lin Gao > Assignee: Lin Gao > > Method: {{LocalManagedConnectionFactory.createConnectionFactory}} requires connectionURL when dataSourceClass is specified. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2016