[jboss-jira] [JBoss JIRA] (WFLY-924) All classes that implement AsyncListener are treated as components causing JBAS011006

[ https://issues.jboss.org/browse/WFLY-924?page=com.atlassian.jira.plugin.s... ] jaikiran pai edited comment on WFLY-924 at 6/27/13 5:40 AM: ------------------------------------------------------------ The servlet spec states (3.0 spec, section 15.5, table 15-1) that AsyncListener(s) are eligible for EE resource injection and other annotation based services. So they are expected to be treated as container managed components. Unlike most other container managed components, implementations of AsyncListener interface can be dynamically registered by the user application, through the use of AsyncContext.createListener(className) API. Such created listeners are expected to be processed by the container for EE resource injection and other such services. This effectively means that the container has to have knowledge of such "possible" AsyncListener candidates which will might be registered by the user applications, so that the container can setup necessary dependencies for those potential AsyncListener(s). The AS7/WildFly container scans the application classpath for the presence of such AsyncListener(s) so that it can do the necessary dependency setup. Of course, the server can't be sure that all/any of these AsyncListener(s) will be registered by the user application, later on. So it considers such AsyncListener(s) as optional components so that failing to construct them will *not* fail the deployment, but instead will log a message that such a optional component construction has failed (notice the log message, it does use the words "Not installing optional component...."). The log message rightly contains the explanation as to why this optional component failed. If users don't care about such optional components and want to hide this message then perhaps a better way to deal with this is to disable logging for that specific message. I don't know if JBoss logging allows it, but perhaps the logging can be configured to set log messages with id JBAS011006 to be turned off. If that isn't possible/desired, then an enhancement would be to log the failure of optional components (i.e. the JBAS011006 message) to be at DEBUG level. I would prefer dealing with this at the logging configuration instead of at the code level. was (Author: jaikiran): The servlet spec states (3.0 spec, section 15.5, table 15-1) that AsyncListener(s) are eligible for EE resource injection and other annotation based services. So they are expected to be treated as container managed components. Unlike most other container managed components, implementations of AsyncListener interface can be dynamically registered by the user application, through the use of AsyncContext.createListener(className) API. Such created listeners are expected to be processed by the container for EE resource injection and other such services. This effectively means that the container has to have knowledge of such "possible" AsyncListener candidates which will might be registered by the user applications, so that the container can setup necessary dependencies for those potential AsyncListener(s). The AS7/WildFly container scans the application classpath for the presence of such AsyncListener(s) so that it can do the necessary dependency setup. Of course, the server can't be sure that all/any of these AsyncListener(s) will be registered by the user application, later on. So it considers such AsyncListener(s) as optional components so that failing to construct them will *not* fail the deployment, but instead will log a message that such a optional component construction has failed (notice the log message, it does use the words "Not installing optional component...."). The log message rightly contains the explanation as to why this optional component failed. If users don't care about such optional components and want to hide this message then perhaps a better way to deal with this is to disable logging for that specific message. (I don't know if JBoss logging allows it, but perhaps the logging can be configured to set log messages with id JBAS011006 to be turned off). If that isn't possible/desired, then an enhancement would be to log the failure of optional components (i.e. the JBAS011006 message) to be at DEBUG level. I would prefer dealing with this at the logging configuration instead of at the code level. -- 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