[JBoss JIRA] (WFLY-6157) Connection URL ignored for SQL Server datasource
by Rich DiCroce (JIRA)
[ https://issues.jboss.org/browse/WFLY-6157?page=com.atlassian.jira.plugin.... ]
Rich DiCroce commented on WFLY-6157:
------------------------------------
Created WFLY-6200
> Connection URL ignored for SQL Server datasource
> ------------------------------------------------
>
> Key: WFLY-6157
> URL: https://issues.jboss.org/browse/WFLY-6157
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Jason Greene
>
> The connection-url for a datasource is being ignored (or more likely, getting lost somewhere) when using WildFly with the Microsoft SQL Server JDBC driver. No matter what I specify as the connection-url (even something obviously invalid like "foobar"), the driver always ends up using the defaults that are baked into it.
> The same driver worked fine on WildFly 10 CR2 (and many earlier versions), so some change between then and 10 Final has caused a regression.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6157) Connection URL ignored for SQL Server datasource
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-6157?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet commented on WFLY-6157:
-----------------------------------------
Could you please create a new issue for this bug ?
> Connection URL ignored for SQL Server datasource
> ------------------------------------------------
>
> Key: WFLY-6157
> URL: https://issues.jboss.org/browse/WFLY-6157
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Jason Greene
>
> The connection-url for a datasource is being ignored (or more likely, getting lost somewhere) when using WildFly with the Microsoft SQL Server JDBC driver. No matter what I specify as the connection-url (even something obviously invalid like "foobar"), the driver always ends up using the defaults that are baked into it.
> The same driver worked fine on WildFly 10 CR2 (and many earlier versions), so some change between then and 10 Final has caused a regression.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6157) Connection URL ignored for SQL Server datasource
by Rich DiCroce (JIRA)
[ https://issues.jboss.org/browse/WFLY-6157?page=com.atlassian.jira.plugin.... ]
Rich DiCroce commented on WFLY-6157:
------------------------------------
In that case, connection-url should not be mandatory. Currently, if connection-url is not present, WildFly reports a configuration error and refuses to start.
> Connection URL ignored for SQL Server datasource
> ------------------------------------------------
>
> Key: WFLY-6157
> URL: https://issues.jboss.org/browse/WFLY-6157
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Jason Greene
>
> The connection-url for a datasource is being ignored (or more likely, getting lost somewhere) when using WildFly with the Microsoft SQL Server JDBC driver. No matter what I specify as the connection-url (even something obviously invalid like "foobar"), the driver always ends up using the defaults that are baked into it.
> The same driver worked fine on WildFly 10 CR2 (and many earlier versions), so some change between then and 10 Final has caused a regression.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6199) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6199?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil moved JBEAP-3392 to WFLY-6199:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6199 (was: JBEAP-3392)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
(was: JMS)
Target Release: (was: 7.0.0.GA)
Affects Version/s: (was: 7.0.0.ER5)
> XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-6199
> URL: https://issues.jboss.org/browse/WFLY-6199
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> We hit NPE during failback in HA scenario with replicated journal in dedicated HA topology. Http connectors are used.
> Test scenario:
> Start 1st EAP 7 server with Artemis configured as live
> Start 2nd EAP 7 server with Artemis configured as backup
> Send 2000 messages to in InQueue to live
> Start 3rd EAP 7 server with RA configured to connecto to live and deploy MDB which receives messages from InQueue and sends a new message to OutQueue
> When MDB is processing messages then kill live server -> MDB failovers to backup
> After MDB processed all messages receive all messages from OutQueue
> NPE occurs when live is killed on backup server:
> {code}
> 02:48:36,503 ERROR [org.xnio.listener] (default I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at org.wildfly.extension.messaging.activemq.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:154)
> at org.wildfly.extension.messaging.activemq.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:146)
> 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 message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6199) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6199?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-6199:
------------------------------
Affects Version/s: 10.0.0.Final
> XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-6199
> URL: https://issues.jboss.org/browse/WFLY-6199
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> We hit NPE during failback in HA scenario with replicated journal in dedicated HA topology. Http connectors are used.
> Test scenario:
> Start 1st EAP 7 server with Artemis configured as live
> Start 2nd EAP 7 server with Artemis configured as backup
> Send 2000 messages to in InQueue to live
> Start 3rd EAP 7 server with RA configured to connecto to live and deploy MDB which receives messages from InQueue and sends a new message to OutQueue
> When MDB is processing messages then kill live server -> MDB failovers to backup
> After MDB processed all messages receive all messages from OutQueue
> NPE occurs when live is killed on backup server:
> {code}
> 02:48:36,503 ERROR [org.xnio.listener] (default I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> at org.wildfly.extension.messaging.activemq.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:154)
> at org.wildfly.extension.messaging.activemq.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:146)
> 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 message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6157) Connection URL ignored for SQL Server datasource
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-6157?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet closed WFLY-6157.
-----------------------------------
Resolution: Rejected
Not a bug
> Connection URL ignored for SQL Server datasource
> ------------------------------------------------
>
> Key: WFLY-6157
> URL: https://issues.jboss.org/browse/WFLY-6157
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Jason Greene
>
> The connection-url for a datasource is being ignored (or more likely, getting lost somewhere) when using WildFly with the Microsoft SQL Server JDBC driver. No matter what I specify as the connection-url (even something obviously invalid like "foobar"), the driver always ends up using the defaults that are baked into it.
> The same driver worked fine on WildFly 10 CR2 (and many earlier versions), so some change between then and 10 Final has caused a regression.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6198) When a datasource has no connection-properties and its driver has defined datasource-class is defined and no connections-properties a warning should be issued
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-6198?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet updated WFLY-6198:
------------------------------------
Description:
If a datasource-class is defined then it takes precedence to create the datasource and as such it can only use connection-properties.
Since there is not a single connection-url property for all drivers, you have to use connection-properties if you are defining the datasource-class.
> When a datasource has no connection-properties and its driver has defined datasource-class is defined and no connections-properties a warning should be issued
> --------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6198
> URL: https://issues.jboss.org/browse/WFLY-6198
> Project: WildFly
> Issue Type: Enhancement
> Components: JCA
> Affects Versions: 10.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: Jesper Pedersen
>
> If a datasource-class is defined then it takes precedence to create the datasource and as such it can only use connection-properties.
> Since there is not a single connection-url property for all drivers, you have to use connection-properties if you are defining the datasource-class.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6198) When a datasource has no connection-properties and its driver has defined datasource-class is defined and no connections-properties a warning should be issued
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-6198?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet updated WFLY-6198:
------------------------------------
Description:
If a datasource-class is defined then it takes precedence to create the datasource and as such it can only use connection-properties.
Since there is not a single connection-url property for all drivers, you have to use connection-properties if you are defining the datasource-class.
A warning when the datasource-class is defined but no connection-properties are present should be issued.
was:
If a datasource-class is defined then it takes precedence to create the datasource and as such it can only use connection-properties.
Since there is not a single connection-url property for all drivers, you have to use connection-properties if you are defining the datasource-class.
> When a datasource has no connection-properties and its driver has defined datasource-class is defined and no connections-properties a warning should be issued
> --------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6198
> URL: https://issues.jboss.org/browse/WFLY-6198
> Project: WildFly
> Issue Type: Enhancement
> Components: JCA
> Affects Versions: 10.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: Jesper Pedersen
>
> If a datasource-class is defined then it takes precedence to create the datasource and as such it can only use connection-properties.
> Since there is not a single connection-url property for all drivers, you have to use connection-properties if you are defining the datasource-class.
> A warning when the datasource-class is defined but no connection-properties are present should be issued.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months