[JBoss JIRA] (WFCORE-1561) read-resource responds with incorrect address when going through host controller
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1561?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1561:
------------------------------------------
Actually I doubt very much that code is the problem. The 'seen' variable is not used in constructing the returned PathAddress, it's just used for checking for the key appearing in multiple elements of the path, where /host=x/server=y/subsystem=foo/host=bar is a special case where that is legal.
> read-resource responds with incorrect address when going through host controller
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1561
> URL: https://issues.jboss.org/browse/WFCORE-1561
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.Final
> Reporter: John Mazzitelli
> Assignee: Brian Stansberry
>
> I have a typical small domain setup: one master host controller (aka domain controller) and one slave host controller with "server-one" and "server-two" servers.
> I need to discover things running in those two servers (server-one and server-two). As part of the discovery, I invoke read-resource operations via the management interface - for example, to discover all the datasources in server-one:
> /host=slave/server=server-one/subsystem=datasources/data-source=*/:read-resource(include-runtime=true)
> For each returned datasource, I need to know that datasource's full address. The problem is, I do not get the full address. Instead, the CLI returns the following partial address:
> {
> "outcome" => "success",
> "result" => [{
> "address" => [
> ("subsystem" => "datasources"),
> ("data-source" => "ExampleDS")
> ],
> "outcome" => "success",
> "result" => {
> "allocation-retry" => undefined,
> ...and the rest of the properties for the ExampleDS datasource...
> }
> }
> }]
> }
> The address should be the full address of:
> "address" => [
> ("host" => "slave"),
> ("server" => "server-one"),
> ("subsystem" => "datasources"),
> ("data-source" => "ExampleDS")
> ],
> NOTE! This problem occurs both when I connect to the domain controller and when I connect to the slave host controller - it doesn't matter, the CLI returns the same erroneous address if connected to either one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1561) read-resource responds with incorrect address when going through host controller
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1561?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1561:
------------------------------------------
[~mazz] Did debugging lead you to that code as the reason for the problem?
> read-resource responds with incorrect address when going through host controller
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1561
> URL: https://issues.jboss.org/browse/WFCORE-1561
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.Final
> Reporter: John Mazzitelli
> Assignee: Brian Stansberry
>
> I have a typical small domain setup: one master host controller (aka domain controller) and one slave host controller with "server-one" and "server-two" servers.
> I need to discover things running in those two servers (server-one and server-two). As part of the discovery, I invoke read-resource operations via the management interface - for example, to discover all the datasources in server-one:
> /host=slave/server=server-one/subsystem=datasources/data-source=*/:read-resource(include-runtime=true)
> For each returned datasource, I need to know that datasource's full address. The problem is, I do not get the full address. Instead, the CLI returns the following partial address:
> {
> "outcome" => "success",
> "result" => [{
> "address" => [
> ("subsystem" => "datasources"),
> ("data-source" => "ExampleDS")
> ],
> "outcome" => "success",
> "result" => {
> "allocation-retry" => undefined,
> ...and the rest of the properties for the ExampleDS datasource...
> }
> }
> }]
> }
> The address should be the full address of:
> "address" => [
> ("host" => "slave"),
> ("server" => "server-one"),
> ("subsystem" => "datasources"),
> ("data-source" => "ExampleDS")
> ],
> NOTE! This problem occurs both when I connect to the domain controller and when I connect to the slave host controller - it doesn't matter, the CLI returns the same erroneous address if connected to either one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1561) read-resource responds with incorrect address when going through host controller
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1561?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-6628 to WFCORE-1561:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1561 (was: WFLY-6628)
Component/s: Domain Management
(was: Domain Management)
Affects Version/s: 2.1.0.Final
(was: 10.0.0.Final)
> read-resource responds with incorrect address when going through host controller
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1561
> URL: https://issues.jboss.org/browse/WFCORE-1561
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.1.0.Final
> Reporter: John Mazzitelli
> Assignee: Brian Stansberry
>
> I have a typical small domain setup: one master host controller (aka domain controller) and one slave host controller with "server-one" and "server-two" servers.
> I need to discover things running in those two servers (server-one and server-two). As part of the discovery, I invoke read-resource operations via the management interface - for example, to discover all the datasources in server-one:
> /host=slave/server=server-one/subsystem=datasources/data-source=*/:read-resource(include-runtime=true)
> For each returned datasource, I need to know that datasource's full address. The problem is, I do not get the full address. Instead, the CLI returns the following partial address:
> {
> "outcome" => "success",
> "result" => [{
> "address" => [
> ("subsystem" => "datasources"),
> ("data-source" => "ExampleDS")
> ],
> "outcome" => "success",
> "result" => {
> "allocation-retry" => undefined,
> ...and the rest of the properties for the ExampleDS datasource...
> }
> }
> }]
> }
> The address should be the full address of:
> "address" => [
> ("host" => "slave"),
> ("server" => "server-one"),
> ("subsystem" => "datasources"),
> ("data-source" => "ExampleDS")
> ],
> NOTE! This problem occurs both when I connect to the domain controller and when I connect to the slave host controller - it doesn't matter, the CLI returns the same erroneous address if connected to either one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6628) read-resource responds with incorrect address when going through host controller
by John Mazzitelli (JIRA)
[ https://issues.jboss.org/browse/WFLY-6628?page=com.atlassian.jira.plugin.... ]
John Mazzitelli commented on WFLY-6628:
---------------------------------------
Uh, it appears this is done on purpose, but I don't know why, and it doesn't seem right. In both: org.jboss.as.controller.PathAddress.pathAddress(ModelNode) and org.jboss.as.controller.PathAddress.pathAddress(List<PathElement>) I see code like:
if (index == 1 && name.equals(SERVER) && seen.contains(HOST)) {
seen.clear();
}
But it seems to me that if I'm issuing a read-resource on an address such as "/host=slave/server=server-one/subsystem=datasources/data-source=*" then the response returning simply "/subsystem=datasources/data-source=ExampleDS" is wrong because that address is no longer fully qualified - outside of knowing the actual request that was made, you don't know what data-source this really is - was it host=slave? host=another? Was it server-one or server-two?
It seems to me this should return the full address as was queried, not a partial address. That is what my code is expecting anyway.
> read-resource responds with incorrect address when going through host controller
> --------------------------------------------------------------------------------
>
> Key: WFLY-6628
> URL: https://issues.jboss.org/browse/WFLY-6628
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 10.0.0.Final
> Reporter: John Mazzitelli
> Assignee: Brian Stansberry
>
> I have a typical small domain setup: one master host controller (aka domain controller) and one slave host controller with "server-one" and "server-two" servers.
> I need to discover things running in those two servers (server-one and server-two). As part of the discovery, I invoke read-resource operations via the management interface - for example, to discover all the datasources in server-one:
> /host=slave/server=server-one/subsystem=datasources/data-source=*/:read-resource(include-runtime=true)
> For each returned datasource, I need to know that datasource's full address. The problem is, I do not get the full address. Instead, the CLI returns the following partial address:
> {
> "outcome" => "success",
> "result" => [{
> "address" => [
> ("subsystem" => "datasources"),
> ("data-source" => "ExampleDS")
> ],
> "outcome" => "success",
> "result" => {
> "allocation-retry" => undefined,
> ...and the rest of the properties for the ExampleDS datasource...
> }
> }
> }]
> }
> The address should be the full address of:
> "address" => [
> ("host" => "slave"),
> ("server" => "server-one"),
> ("subsystem" => "datasources"),
> ("data-source" => "ExampleDS")
> ],
> NOTE! This problem occurs both when I connect to the domain controller and when I connect to the slave host controller - it doesn't matter, the CLI returns the same erroneous address if connected to either one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6561) EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFLY-6561?page=com.atlassian.jira.plugin.... ]
Carlo de Wolf updated WFLY-6561:
--------------------------------
Labels: downstream_dependency (was: )
> EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-6561
> URL: https://issues.jboss.org/browse/WFLY-6561
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Kevin Chen
> Assignee: Stuart Douglas
> Labels: downstream_dependency
>
> On Wildfly10, we are experiencing intermittent problems where on server startup, an @Timeout annotated method can be executed hundreds of times in a second (log below). Going through the references to the @Timeout methods and the @Scheduled methods, all scheduled methods are set to be non-persistent (ex: timerConfig.setPersistent(false), persistent=false) so we don't know how this could occur. It is not consistent and our only solution has been to kill the Wildfly10 server process and restart.
> 13:47:27,824 WARN [org.jboss.as.ejb3] (EJB default - 6) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 96) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 97) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 37) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6528) Server is unable to invoke @Timeout method after 10 methods are called on Asynchronous bean on IBM JDK
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFLY-6528?page=com.atlassian.jira.plugin.... ]
Carlo de Wolf updated WFLY-6528:
--------------------------------
Priority: Critical (was: Major)
> Server is unable to invoke @Timeout method after 10 methods are called on Asynchronous bean on IBM JDK
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6528
> URL: https://issues.jboss.org/browse/WFLY-6528
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: downstream_dependency
>
> *Description of problem:*
> Server is unable to invoke @Timeout method after 10 methods are called on Asynchronous bean
> Test:
> {code:java}
> for (int i = 0; i < 10; i++) {
> AsyncBean bean = lookup(AsyncBean.class);
> bean.asyncMethod();
> }
> InitialContext iniCtx = new InitialContext();
> TimeoutBean bean = (TimeoutBean) iniCtx.lookup("java:module/" + TimeoutBean.class.getSimpleName());
> bean.createTimer();
> {code}
> Asynchronous bean:
> {code:java}
> @Stateless
> @Asynchronous
> @LocalBean
> public class AsyncBean{
> public void asyncMethod() {
> System.out.println("asynch bean execution");
> }
> }
> {code}
> Timeout bean:
> {code:java}
> @Stateless
> public class TimeoutBean {
> @Resource
> private TimerService timerService;
> public void createTimer() {
> timerService.createTimer(100, null);
> }
> @Timeout
> private void timeout(Timer timer) {
> System.out.println("in timeout method");
> }
> }
> {code}
> *How reproducible:*
> Always on IBM JDK
> *Steps to Reproduce: (use attached reproducer)*
> # get fresh EAP
> # mvn test -Djboss.home=$\{EAP_HOME\}
> *Actual results:*
> {noformat}
> 12:26:57,462 ERROR [org.jboss.as.ejb3] (EJB default - 9) WFLYEJB0164: Exception running timer task for timer [id=03aa7a93-ee6f-483e-bf6b-caff56a13fc0 timedObjectId=test.test.TimeoutBean auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@f1cd0789 initialExpiration=Mon Apr 11 12:26:57 CEST 2016 intervalDuration(in milli sec)=0 nextExpiration=null timerState=IN_TIMEOUT info=null] on EJB test.test.TimeoutBean: java.lang.RuntimeException: javax.xml.stream.FactoryConfigurationError: Provider __redirected.__XMLOutputFactory not found
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:614)
> at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:148)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1214)
> at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.xml.stream.FactoryConfigurationError: Provider __redirected.__XMLOutputFactory not found
> at javax.xml.stream.XMLOutputFactory.newFactory(Unknown Source)
> at javax.xml.stream.XMLOutputFactory.newInstance(Unknown Source)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.writeFile(FileTimerPersistence.java:497)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.persistTimer(FileTimerPersistence.java:225)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.persistTimer(FileTimerPersistence.java:193)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:609)
> ... 7 more
> Caused by: java.lang.ClassNotFoundException: __redirected.__XMLOutputFactory
> at java.lang.Class.forNameImpl(Native Method)
> at java.lang.Class.forName(Class.java:273)
> at javax.xml.stream.FactoryFinder.newInstance(Unknown Source)
> at javax.xml.stream.FactoryFinder.find(Unknown Source)
> at javax.xml.stream.FactoryFinder.find(Unknown Source)
> ... 13 more
> {noformat}
> *Expected results:*
> No exception on output
> *Additional info:*
> Number of EJB call depends on max-threads attribute of EJB3 subsystem. It can be configured by this CLI command:
> {noformat}
> /subsystem=ejb3/thread-pool=default:write-attribute(name=max-threads,value=10)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6528) Server is unable to invoke @Timeout method after 10 methods are called on Asynchronous bean on IBM JDK
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFLY-6528?page=com.atlassian.jira.plugin.... ]
Carlo de Wolf updated WFLY-6528:
--------------------------------
Labels: downstream_dependency (was: )
> Server is unable to invoke @Timeout method after 10 methods are called on Asynchronous bean on IBM JDK
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6528
> URL: https://issues.jboss.org/browse/WFLY-6528
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Labels: downstream_dependency
>
> *Description of problem:*
> Server is unable to invoke @Timeout method after 10 methods are called on Asynchronous bean
> Test:
> {code:java}
> for (int i = 0; i < 10; i++) {
> AsyncBean bean = lookup(AsyncBean.class);
> bean.asyncMethod();
> }
> InitialContext iniCtx = new InitialContext();
> TimeoutBean bean = (TimeoutBean) iniCtx.lookup("java:module/" + TimeoutBean.class.getSimpleName());
> bean.createTimer();
> {code}
> Asynchronous bean:
> {code:java}
> @Stateless
> @Asynchronous
> @LocalBean
> public class AsyncBean{
> public void asyncMethod() {
> System.out.println("asynch bean execution");
> }
> }
> {code}
> Timeout bean:
> {code:java}
> @Stateless
> public class TimeoutBean {
> @Resource
> private TimerService timerService;
> public void createTimer() {
> timerService.createTimer(100, null);
> }
> @Timeout
> private void timeout(Timer timer) {
> System.out.println("in timeout method");
> }
> }
> {code}
> *How reproducible:*
> Always on IBM JDK
> *Steps to Reproduce: (use attached reproducer)*
> # get fresh EAP
> # mvn test -Djboss.home=$\{EAP_HOME\}
> *Actual results:*
> {noformat}
> 12:26:57,462 ERROR [org.jboss.as.ejb3] (EJB default - 9) WFLYEJB0164: Exception running timer task for timer [id=03aa7a93-ee6f-483e-bf6b-caff56a13fc0 timedObjectId=test.test.TimeoutBean auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@f1cd0789 initialExpiration=Mon Apr 11 12:26:57 CEST 2016 intervalDuration(in milli sec)=0 nextExpiration=null timerState=IN_TIMEOUT info=null] on EJB test.test.TimeoutBean: java.lang.RuntimeException: javax.xml.stream.FactoryConfigurationError: Provider __redirected.__XMLOutputFactory not found
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:614)
> at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:148)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1214)
> at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.xml.stream.FactoryConfigurationError: Provider __redirected.__XMLOutputFactory not found
> at javax.xml.stream.XMLOutputFactory.newFactory(Unknown Source)
> at javax.xml.stream.XMLOutputFactory.newInstance(Unknown Source)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.writeFile(FileTimerPersistence.java:497)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.persistTimer(FileTimerPersistence.java:225)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.persistTimer(FileTimerPersistence.java:193)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:609)
> ... 7 more
> Caused by: java.lang.ClassNotFoundException: __redirected.__XMLOutputFactory
> at java.lang.Class.forNameImpl(Native Method)
> at java.lang.Class.forName(Class.java:273)
> at javax.xml.stream.FactoryFinder.newInstance(Unknown Source)
> at javax.xml.stream.FactoryFinder.find(Unknown Source)
> at javax.xml.stream.FactoryFinder.find(Unknown Source)
> ... 13 more
> {noformat}
> *Expected results:*
> No exception on output
> *Additional info:*
> Number of EJB call depends on max-threads attribute of EJB3 subsystem. It can be configured by this CLI command:
> {noformat}
> /subsystem=ejb3/thread-pool=default:write-attribute(name=max-threads,value=10)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6372) Flagging of invalid login credential for datasource is inconsistent.
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFLY-6372?page=com.atlassian.jira.plugin.... ]
Carlo de Wolf updated WFLY-6372:
--------------------------------
Labels: downstream_dependency (was: )
> Flagging of invalid login credential for datasource is inconsistent.
> --------------------------------------------------------------------
>
> Key: WFLY-6372
> URL: https://issues.jboss.org/browse/WFLY-6372
> Project: WildFly
> Issue Type: Bug
> Reporter: Bartosz Baranowski
> Assignee: Lin Gao
> Labels: downstream_dependency
>
> There are multiple parts to this
> (1) If the security-domain is defined for a datasource and the password is invalid, an error is reported in the console which is expected
> <datasource jndi-name="java:/DefaultDS2" pool-name="DefaultDS2" enabled="true" use-java-context="true">
> <connection-url>jdbc:oracle:thin:@hostname:1521:ora1</connection-url>
> <driver>oracle</driver>
> <security>
> <security-domain>encryptedPassword2</security-domain>
> </security>
> </datasource>
> (2) If the 'password' for the datasource is invalid no error is reported in the console log at startup e.g
> <datasource jndi-name="java:/DefaultDS2" pool-name="DefaultDS2" enabled="true" use-java-context="true">
> <connection-url>jdbc:oracle:thin:@hostname:1521:ora1</connection-url>
> <driver>oracle</driver>
> <security>
> <user-name>user</user-name>
> <password>passwd</password>
> </security>
> </datasource>
> 3. Whether or not you use a security-domain for a datasource, an invalid 'username' doesn't get flagged in the console.
> Actual results:
> Expected results:
> Invalid username and password should be flagged as login errors in the console log.
> It shouldn't make a difference whether or not you use security-credentials
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6372) Flagging of invalid login credential for datasource is inconsistent.
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFLY-6372?page=com.atlassian.jira.plugin.... ]
Carlo de Wolf updated WFLY-6372:
--------------------------------
Priority: Critical (was: Major)
> Flagging of invalid login credential for datasource is inconsistent.
> --------------------------------------------------------------------
>
> Key: WFLY-6372
> URL: https://issues.jboss.org/browse/WFLY-6372
> Project: WildFly
> Issue Type: Bug
> Reporter: Bartosz Baranowski
> Assignee: Lin Gao
> Priority: Critical
> Labels: downstream_dependency
>
> There are multiple parts to this
> (1) If the security-domain is defined for a datasource and the password is invalid, an error is reported in the console which is expected
> <datasource jndi-name="java:/DefaultDS2" pool-name="DefaultDS2" enabled="true" use-java-context="true">
> <connection-url>jdbc:oracle:thin:@hostname:1521:ora1</connection-url>
> <driver>oracle</driver>
> <security>
> <security-domain>encryptedPassword2</security-domain>
> </security>
> </datasource>
> (2) If the 'password' for the datasource is invalid no error is reported in the console log at startup e.g
> <datasource jndi-name="java:/DefaultDS2" pool-name="DefaultDS2" enabled="true" use-java-context="true">
> <connection-url>jdbc:oracle:thin:@hostname:1521:ora1</connection-url>
> <driver>oracle</driver>
> <security>
> <user-name>user</user-name>
> <password>passwd</password>
> </security>
> </datasource>
> 3. Whether or not you use a security-domain for a datasource, an invalid 'username' doesn't get flagged in the console.
> Actual results:
> Expected results:
> Invalid username and password should be flagged as login errors in the console log.
> It shouldn't make a difference whether or not you use security-credentials
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months