Russian doll packaging in arbitrary directories - JBAS-5900

[adrian.brock]

https://jira.jboss.org/jira/browse/JBAS-5900

This raises the issue of a change in behaviour in "Russian doll" packaging
in JBoss5.

The behaviour asserted is actually not tested in the AS testsuite, instead
it is documentated to be otherwise,
see "Deploy Applications Inside of An Application" here:
http://docs.jboss.org/jbossas/upgrade4/html/

"If you want to make a subdeployment (for those archives that support simple Russian Doll packaging), place it in the root of the parent deployment."
(My emphasis)

Possible Solutions:

1) We could create a new but deprecated "DirectoryStructure" that adds this behaviour
for backwards compatiblity purposes.
i.e. instead of ignoring directories inside deployments that don't have
a META-INF subfolder, we could scan them (recursively) for deployments.

2) We could add something to that treats directories like "lib" specially
and scans them for jars, since this is becoming a standard within JavaEE.

3) Close the issue saying it was an "undocumented feature"

[adrian.brock]

1) We could create a new but deprecated "DirectoryStructure" that adds this behaviour
for backwards compatiblity purposes.
i.e. instead of ignoring directories inside deployments that don't have
a META-INF subfolder, we could scan them (recursively) for deployments.

This solution has the problem that directories no longer need extensions
to be deployable. e.g.

parent.jar/child/WEB-INF/web.xml

makes "child" a valid web application subdeployment.

so If there was also a

parent.jar/child/WEB-INF/lib/util.jar

it would be wrong to treat util.jar as a subdeployment since it is part of the
war classpath.

[adrian.brock]

so If there was also a

parent.jar/child/WEB-INF/lib/util.jar

it would be wrong to treat util.jar as a subdeployment since it is part of the
war classpath.

Which basically means the "DirectoryStructure" has to come after
other StructureDeployers so when the WARStructure recognises the "child" directory
it doesn't get processed by the DirectoryStructure.

[alesj]

How do we diff between this example:
- test-in-lib.sar/lib
- test-in-lib.sar/lib/somejar.jar/META-INF

For war it's not a problem,
it's jar structure that recursively checks all children as possible contexts.
Hence it's picking up META-INF, which we now recognize as dir structure.

This is my current DirectoryStructure code:

 public boolean determineStructure(StructureContext context) throws DeploymentException
 {
 try
 {
 // jar structure should already handle top level dirs
 if (context.isTopLevel() == false)
 {
 VirtualFile file = context.getFile();
 // only simple directories, non-leaves with META-INF are handled by jar structure
 if (isLeaf(file) == false)
 {
 addAllChildren(context);
 return true;
 }
 }
 return false;
 }
 catch (Exception e)
 {
 throw DeploymentException.rethrowAsDeploymentException("Error determining structure.", e);
 }
 }

[alesj]

And the same issue, if not even worse :-),
is the packages directories:
- myapp.jar/org/jboss/demos/foorbar/acme/...
Each of those is gonna be checked.

[alesj]

Actually, the right thing is to remove that 'return true'.
Since we don't want to recognize dir as deployment context,
we only want its valid children to be recognized.

Then it's just an issue of performance,
since we check all directories (recursively) for possible valid deployments.

But the test is still failing for me, even if I add this DirectoryStructure.
I'll look into it a bit more. :-)

[alesj]

"alesj" wrote:
I'll look into it a bit more. :-)

I've managed to see/find the problem.
Hacking this dir structure deployer deploys that 'broken' sar deployment:

public class DirectoryStructure extends AbstractVFSStructureDeployer
{
 public DirectoryStructure()
 {
 setRelativeOrder(Integer.MAX_VALUE);
 }

 public boolean determineStructure(StructureContext context) throws DeploymentException
 {
 try
 {
 VirtualFile file = context.getFile();
 // jar structure should already handle top level dirs
 if (context.isTopLevel() == false && isLeaf(file) == false && isMetadataPath(context) == false)
 {
 List<VirtualFile> children = file.getChildren();
 if (children != null && children.isEmpty() == false)
 {
 VFSStructuralDeployers structuralDeployers = context.getDeployers();

 // get top
 while (context.getParentContext() != null)
 context = context.getParentContext();

 for (VirtualFile child : children)
 structuralDeployers.determineStructure(child, context);
 }
 }
 return false;
 }
 catch (Exception e)
 {
 throw DeploymentException.rethrowAsDeploymentException("Error determining structure.", e);
 }
 }

 /**
 * Is the current context already part of metadata path.
 *
 * @param context the current structure context
 * @return true if already part of parent's context metadata path
 */
 protected boolean isMetadataPath(StructureContext context)
 {
 String relativePath = AbstractStructureDeployer.getRelativePath(context.getParent(), context.getFile());
 return "META-INF".equalsIgnoreCase(relativePath) || "WEB-INF".equalsIgnoreCase(relativePath);
 }
}

But it looks too much of a hack. :-(
e.g. dunno how it would handle that top structure context search in some ear deployment

[adrian.brock]

Rather than the hacky hardwiring of META-INF/WEB-INF
can't you just tell it not to recurse into paths that are defined as metadata locations
in the parent structure?

[alesj]

I'll port this DirectoryStructure to deployers project, to simplify the work needed to test this:
--> sar with lib
--> sar with top/snd/third (multiple dirs)
--> sar inside ear with lib
--> sar inside ear with top/snd/third (multiple dirs)

Then if someone wants to use this, (s)he can enable it in AS - in some xyz-dpeloyers-jboss-beans.xml

[alesj]

I've committed initial version of it - see trunk.

If you can add a test to RealDirStructureUnitTestCase that breaks this
- e.g. some classloading scoping,
I'm willing to fix it to work against 'real' parent structure context. :-)

[alesj]

The JBoss5_trunk deployers part of testsuite
works w/o any problems with this new addition. :-)