Spurious ":" in @Resource annotation 'name' value results in invalid binding but no deployment error ---------------------------------------------------------------------------------------------------- Key: WFLY-3623 URL: https://issues.jboss.org/browse/WFLY-3623 Project: WildFly Issue Type: Bug Components: EE Affects Versions: JBoss AS7 7.2.0.Final, 8.0.0.Final, 8.1.0.Final Reporter: Brian Stansberry Assignee: Bartosz Baranowski Attachments: 01134324.jar, dumpServices.txt See attached jar for a reproducer. Just deploy it. The jar includes it's own source. An @Resource annotation with a spurious ":" in the name attribute value results in an incorrect binding but no deployment failure: {code} @Resources({ @Resource( // name="java:jboss/ResourceTestEJB", // ==> this works fine name="java:jboss:/ResourceTestEJB", // ==> this will not bind the JNDI correctly, and there is no error on deploying EJB type=com.test.ResourceEJB.class, lookup="java:global/01134324/ResourceEJBImpl") }) {code} There is no error reported in the log. Using jndi-view op in the CLI, I see: {code} [standalone@localhost:9990 subsystem=naming] :jndi-view { "outcome" => "success", "result" => { "java: contexts" => { ..... "java:jboss" => { .... "java:jboss:" => {"class-name" => "javax.naming.Context"}, } } .... } {code} Any time the jndi-view op is run, the following is logged in the server.log: {code} 10:52:02,985 ERROR [org.jboss.as.naming] (management-handler-thread - 5) WFLYNAM0013: Failed to obtain jndi view value for entry java:jboss:.: javax.naming.NameNotFoundException: jboss: -- service jboss.naming.context.java.jboss.jboss: at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT] at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT] at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT] at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:132) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT] at org.jboss.as.naming.management.JndiViewOperation.access$000(JndiViewOperation.java:47) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT] at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:72) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:603) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:481) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1060) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:296) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:165) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:204) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:133) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:154) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_45] at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_45] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:150) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:297) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:536) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final] {code} If a proper binding can't be done per the annotation value, there should be an exception thrown triggering deployment rollback. I'll attach an MSC service dump in case it's useful.