The org.jboss.injection.ResourceHandler should just be looking at the mappedName/jndiName/resolvesJndiName and throwing an exception if its not set. This is the change I made in the client container version and then fixed the message-destination-ref link resolution in the MappedReferenceMetaDataResolverDeployer.

The org.jboss.injection.ResourceHandler is not looking to the resolvedJnidName curently. Should be something like:

 private static void loadXmlMessageDestinationRefs(InjectionContainer container, Collection<MessageDestinationReferenceMetaData> refs)
 {
 for (MessageDestinationReferenceMetaData envRef : refs)
 {
 String encName = "env/" + envRef.getMessageDestinationRefName();
 if (container.getEncInjectors().containsKey(encName)) continue;
 String jndiName = envRef.getMappedName();
 if (jndiName == null || jndiName.equals(""))
 {
 // Look for a resolved-jndi-name
 jndiName = envRef.getResolvedJndiName();
 if (jndiName == null)
 {
 throw new RuntimeException("message-destination has no jndi-name/resolved-jndi-name " + envRef);
 }
 }
...

I'm not too thrilled with this solution. It pollutes both EJB3 and metadata. I would rather see MessageDestinationResolver refactored in the same style as PersistenceUnitDependencyResolver.

interfaces MessageDestinationResolver {
 String resolveMessageDestination(DeploymentUnit unit, String link);
}

I'm saying the MessageDestinationResolver should just be dropped as the message ref should have had its resolvedJndiName set, same as for ejb refs. We have already removed the ejb resolver from the ejb3 deployment.

As it is right now it should be dropped.

But resolvedJndiName has nothing to do with raw metadata. That's one of the reasons that I made the naming policy decorator prototype for beans. The same should be done for references (some day).

The mapped resolver deployer is becoming a big beast. It should delegate out the actual resolving function of the references and then setup the decorated metadata.

EJB3 within AS will then get references (and beans) which will always have a jndiName / mappedName, with the old fallback code refactored onto the same resolvers mapped resolver deployer is using.

Ok, don't disagree but this is a post tck cleanup effort.