all files that make up a deployment unit

[bill.burke]

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).

[adrian.brock]

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.

[bill.burke]

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