These are the steps I've taken to try to reproduce this issue:
1. Enable remote debugging by updating standalone.conf, and set the server to wait for a connection.
2. Set a breakpoint in org.jboss.as.connector.subsystems.datasources.DataSourceConfigService.start(startContext)
3. Set a breakpoint in org.jboss.aerogear.netty.extension.NettyService.start(startContext)
4. Start the server
Upon startup we can see the following log statement which is called from the Netty subsystem:
10:01:34,283 INFO [org.jboss.aerogear.netty.extension.ServerAdd] (ServerService Thread Pool -- 51) Adding dependency to [service jboss.data-source-config.SimplePushDS]
The debugger should have stopped one or more threads, depending on the number of datasources configured. In my case I have four.
Stepping through these one at a time will produce the following logs:
10:07:39,557 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
10:07:41,501 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) JBAS010400: Bound data source [java:jboss/datasources/PushEEDS]
10:07:43,852 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) JBAS010400: Bound data source [java:jboss/datasources/MysqlDS]
10:07:45,680 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) JBAS010400: Bound data source [java:jboss/datasources/SimplePushDS]
If we now resume/continue the next break point that will be hit is org.jboss.aerogear.netty.extension.NettyService.start(startContext).
While writing this and going over the code this looks incorrect. The service we should be depending on is the service binding this to the jndi context. The other service dependencies are probably getting satisfied so the Netty service can go ahead, but the actual datasources might not yet have been bound into jndi causing the failure reported.
If we use the jndi name instead of the datasource name in the configuration and then add a dependency to that BinderService it might work:
final BindInfo bindinfo = ContextNames.bindInfoFor(datasourceNode.asString());
logger.info("Adding dependency to [" + bindinfo.getAbsoluteJndiName() + "]");
sb.addDependencies(bindinfo.getBinderServiceName());
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
These are the steps I've taken to try to reproduce this issue:
1. Enable remote debugging by updating standalone.conf, and set the server to wait for a connection.
2. Set a breakpoint in org.jboss.as.connector.subsystems.datasources.DataSourceConfigService.start(startContext)
3. Set a breakpoint in org.jboss.aerogear.netty.extension.NettyService.start(startContext)
4. Start the server
Upon startup we can see the following log statement which is called from the Netty subsystem:
The debugger should have stopped one or more threads, depending on the number of datasources configured. In my case I have four.
Stepping through these one at a time will produce the following logs:
If we now resume/continue the next break point that will be hit is org.jboss.aerogear.netty.extension.NettyService.start(startContext).
While writing this and going over the code this looks incorrect. The service we should be depending on is the service binding this to the jndi context. The other service dependencies are probably getting satisfied so the Netty service can go ahead, but the actual datasources might not yet have been bound into jndi causing the failure reported.
If we use the jndi name instead of the datasource name in the configuration and then add a dependency to that BinderService it might work: