2 Replies Latest reply on Oct 5, 2006 9:54 AM by Bill Burke

    all files that make up a deployment unit

    Bill Burke Master

      I ran into a problem where I only want to scan for .class files in the DeploymentUnit but skip .class files in subdeployments. The current VirtualFile/Visitor code could not handle this situation so I had to extend VisitorAttributes with a isRecurseArchive() option and modify the AbstractVFSContext accordingly.

      Then, in my EJB Deployer I do:

      unit.getDeploymentContext().getRoot().visit(FilterOnClassFileAndNoRecurseArchives);

      I don't know or not if this goes against your abstract notion of things. I'm thinking maybe that DeploymentUnit should have some new methods:

      VirtualFile getResource(String name);
      List getResources();
      List getResources(VirtualFileFilter);

      We had this discussion before, but ClassPath just won't cut it as a deployer may or may not want to distinguish between a ClassPath manifest when scanning for deployment resources (i.e. what classes to scan anntotations for).

        • 1. Re: all files that make up a deployment unit
          Adrian Brock Master

          Do what you want, I'll fix it later.
          This needs to work on the classpath notion.

          A visitor on the classpath (a concept that doesn't exist
          but I suggested you write on an earlier thread)
          should not be recursing into nested deployments.

          The notion of archive will be removed from the VFS
          to the deployers anyway, see the other thread where
          Scott and I were arguing about this.

          Manifest/Non-Manifest or more accurately (external/non-external)
          would be an attribute on the classpath visit.

          • 2. Re: all files that make up a deployment unit
            Bill Burke Master

             

            "adrian@jboss.org" wrote:
            Do what you want, I'll fix it later.
            This needs to work on the classpath notion.

            A visitor on the classpath (a concept that doesn't exist
            but I suggested you write on an earlier thread)
            should not be recursing into nested deployments.


            I'm fine with using DeploymentUnit.getDeploymentContext().getClassPath() as long as this classpath is equivalent to the notion of a resource loader in the old container.

            So for instance, a jar within a WAR would be its own DeploymentUnit with a context with a classpath of only that jar (and its manifest references).

            Bill