3 Replies Latest reply on Nov 13, 2006 3:14 PM by starksm64

    Current behavior of DeploymentUnit.getAttachment

    starksm64

      Currently the only types of deployments that look to their parents for attachments are components. Subdeployments in ears do not see the ear attachments because they are not component deployment types. At this point I don't see a reason to differentiate between components and subdeployments in terms of searching the deployment structure from child to parent for attachments. What was the reason for not allowing subdeployments to see parent attachments?

        • 1. Re: Current behavior of DeploymentUnit.getAttachment
          starksm64

          For now I just added a helper class that provides the desired child to parent search logic:

          package org.jboss.deployers.plugins.deployers.helpers;
          
          import org.jboss.deployers.spi.deployer.DeploymentUnit;
          import org.jboss.deployers.spi.structure.DeploymentContext;
          
          /**
           * Search a DeploymentUnit structure from child to parent for a matching
           * attachment.
           *
           * @author Scott.Stark@jboss.org
           * @version $Revision:$
           */
          public class AttachmentLocator
          {
           static public Object search(DeploymentUnit unit, String name)
           {
          ...
           }
          
           static public <T> T search(DeploymentUnit unit, String name, Class<T> expectedType)
           {
          ...
           }
          
           static public <T> T search(DeploymentUnit unit, Class<T> type)
           {
          ...
           }
          }
          



          • 2. Re: Current behavior of DeploymentUnit.getAttachment

            The problem is one of leakage when the order of processing attachments
            is not defined.

            e.g. More explicitly, imagine an ear that contains an ear
            where the inner ear doesn't have an application.xml
            it would see the application.xml of the containing ear.

            This is why I described the current behaviour as a hack.
            It only works because the component deployers are at the end
            and they only process the specific component attachments/metadata
            So there is no deployer that will look at a component and reprocess the parent's
            metadata.

            • 3. Re: Current behavior of DeploymentUnit.getAttachment
              starksm64

              Right, but we need to have a distinction between resource visibility and hierarchical metadata. Until we get aligned on metadata being a more properly defined aspect of the vdf we kind of have a free for all in terms of who is doing what in the processing of deployments.