JBMICROCONT-105, structural deployer, vfs refactoring

[starksm64]

In terms of getting a stable mc spi for jboss5, resolving the current structural deployers/vfs isArchive issue is an important one. I created JBMICROCONT-105 to get this done. Let's hash out an spi that both jboss5/ejb3 embedded/hem can work with.

[starksm64]

My main requirement is that there be support for explicitly declaring the structure: subdeployments, classpath (including ordering), metdata paths, etc. It always has been a pain/weakness to rely on the packaging determining this.

[starksm64]

A refactoring I have working with the DeclaredStructure deployer is the following:

public interface StructureDeployer
{
 /**
 * Determine the structure of a deployment
 *
 * @param file - the candidate root file of the deployment
 * @param metaData - the structure metadata to build
 * @param deployers - the available structure deployers
 * @return true when it is recongnised
 */
 boolean determineStructure(VirtualFile file, StructureMetaData metaData, StructuredDeployers deployers);

 int getRelativeOrder();

 /** The comparator for relative ordering of deployers */
 Comparator<StructureDeployer> COMPARATOR = new StructureComparator();
...
}

where the externalized view of the structure deployers is:

public interface StructuredDeployers
{
 /**
 *
 * @param file - root of the deployment in the VFS
 * @param metaData - the existing metadata to use/populate with structure metadata
 * @return
 * @throws DeploymentException
 */
 public boolean determineStructure(VirtualFile file, StructureMetaData metaData) throws DeploymentException;

 /**
 * Get the ordered set of deployers.
 * @return the ordered set of deployers.
 */
 public SortedSet<StructureDeployer> getDeployers();
 /**
 * Are there any deployers
 * @return
 */
 public boolean isEmpty();
}

to transform the StructureMetaData resulting from the structural parse into a DeploymentContext, there is a StructureVisitorFactory notion that is external to the structure parse. This replaces the CandidateStructureVisitorFactory notion that was incorporated into the abstract structural deployer classes, and is another aspect of the MainDeployer.

public interface StructureVisitorFactory
{
 /**
 * Create the visitor
 *
 * @param context the deployment context
 * @param attributes the visitor attributes uses {@link VisitorAttributes#DEFAULT} when null
 * @return the visitor
 * @throws Exception for any error
 */
 VirtualFileVisitor createVisitor(DeploymentContext context, StructureMetaData metaData,
 VisitorAttributes attributes) throws Exception;
}

The StructureMetaData abstraction is:

/**
 * A map of vfs paths to deployment context information.
 */
public interface StructureMetaData
{
 public void addContext(ContextInfo context);
 public ContextInfo getContext(String vfsPath);
 public ContextInfo removeContext(String vfsPath);
}
public interface ContextInfo
{
 public String getVfsPath();
 public void setVfsPath(String path);

 public String getMetaDataPath();
 public void setMetaDataPath(String metaDataPath);

 public List<ClassPathInfo> getClassPath();
 public void setClassPath(List<ClassPathInfo> classPath);
}
public interface ClassPathInfo
{
 /**
 * path relative to the context virtual file.
 */
 public String getPath();
 public void setPath(String path);

 /**
 * Classpath options
 */
 public Map getOptions();
 public void setOptions(Map options);

 public Object getOption(Object key);
 public void setOption(Object key, Object value);
}

How does this look?

I'm creating some tests that replace the usage of the common ArchiveBrowser to validate that this can be replaced with the vfs/StructuredDeployers abstractions.

[starksm64]

One issue I'm running into with the refactored structural deployer code is that a number of the unit tests expect that "top-level" deployments are accepted as valid. Both the JarStructure and FileStructure were accepting top-level directories (based on DeploymentContext.isTopLevel()) as valid without validating anything about the actual structure.

Before trying to restore this behavior, I want to question this as a valid construct. Its essentially a mix of pre-determined structure with the root being marked as a valid deployment, but the children unknown. With the new structure deployment spi, such a deployment would have to have a StructureMetaData with a ContextInfo that corresponds to the valid root. With such a StructureMetaData, there is not much point in validating that the structure deployers recognize the VirtualFile for the root as valid since its declared to be so.

I'll hack around it for now and come back to this if its causing other issues.

[starksm64]

I have all of the deployer tests working in the mc project. The EARStructure deployer needs to be ported over to be able to move this into head. I'm working on that now.

[starksm64]

This has been committed and the snapshot jboss-deployers.jar updated.