-
1. Re: Ejb3Deployment.resolveMessageDestination
starksm64 Aug 4, 2008 3:42 PM (in response to emuckenhuber)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); } } ...
-
2. Re: Ejb3Deployment.resolveMessageDestination
wolfc Aug 7, 2008 1:04 PM (in response to emuckenhuber)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); }
With the default impl returning the resolved jndi name. -
3. Re: Ejb3Deployment.resolveMessageDestination
starksm64 Aug 7, 2008 1:21 PM (in response to emuckenhuber)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.
-
4. Re: Ejb3Deployment.resolveMessageDestination
wolfc Aug 7, 2008 4:47 PM (in response to emuckenhuber)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. -
5. Re: Ejb3Deployment.resolveMessageDestination
starksm64 Aug 7, 2008 9:26 PM (in response to emuckenhuber)Ok, don't disagree but this is a post tck cleanup effort.