5 Replies Latest reply on Aug 7, 2008 9:26 PM by Scott Stark

    Ejb3Deployment.resolveMessageDestination

    Emanuel Muckenhuber Master

      Following up on the current failures of the ejb30/mdb/dest tests..

      The cause for those failures is that the messageDestinationResolver in the ejb3 module does not resolve the correct names for message-destination-refs.

      "scott.stark@jboss.org" wrote:

      We really should not be calling the Ejb3Deployment.resolveMessageDestination any longer as this should have already been resolved by the MappedDeploymentEndpointResolver. Improvement on resolving message-destination-refs was the change I made yesterday.


      That said - overriding the resolveMessageDestination in Ejb3JBoss5Deployment and using the correct information from MappedReferenceDeployer makes those tests pass (*)

      Basically there are only two places left where that is used:
      * org.jboss.injection.ResourceHandler
      * org.jboss.ejb3.Ejb3Deployment

      Furthermore ClientENCInjectionContainer is still refering to the messageDestinationResolver, but not using it anymore.


      (*) There are still two remaining failures due to this: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168503#4168503

        • 1. Re: Ejb3Deployment.resolveMessageDestination
          Scott Stark Master

          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
            Carlo de Wolf Master

            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
              Scott Stark Master

              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
                Carlo de Wolf Master

                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
                  Scott Stark Master

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