[jboss-dev-forums] [Design of POJO Server] - Re: Using temp at undeploy

[alesj]

Describing what I did.
Discussing whether it's not too much of a hack.

Currently the only way to apply ModificationType is via jboss-structure.xml/context/modification=temp|unpack|explode.
Which sounds a bit too limiting for a simple modification=temp instruction.

The way current structure recognition part of VDF works, we need to get that info before 
StructureBuilder::populateContext is invoked in AbstractStructuralDeployers::determineStructure.

What I've done is introduced a new StructureDeployer,
which actually doesn't recognize the structure, but knows how to
recognize if there should be any modification.


  | public class ModificationTypeStructureDeployer implements StructureDeployer
  | {
  |    private List<ModificationTypeMatcher> matchers;
  | 
  |    public boolean determineStructure(StructureContext context) throws DeploymentException
  |    {
  |       if (matchers != null && matchers.isEmpty() == false)
  |       {
  |          for (ModificationTypeMatcher matcher : matchers)
  |          {
  |             if (matcher.determineModification(context))
  |             {
  |                break;
  |             }
  |          }
  |       }
  |       return false;
  |    }
  | 
  |    /**
  |     * Set modification type matchers.
  |     *
  |     * @param matchers the modification type matchers.
  |     */
  |    public void setMatchers(List<ModificationTypeMatcher> matchers)
  |    {
  |       this.matchers = matchers;
  |    }
  | 
  |    /**
  |     * Add modification type matcher.
  |     *
  |     * @param matcher the modification type matcher
  |     */
  |    public void addMatcher(ModificationTypeMatcher matcher)
  |    {
  |       if (matchers == null)
  |          matchers = new ArrayList<ModificationTypeMatcher>();
  | 
  |       matchers.add(matcher);
  |    }
  | 
  |    /**
  |     * Remove modification type matcher.
  |     *
  |     * @param matcher the modification type matcher
  |     */
  |    public void removeMatcher(ModificationTypeMatcher matcher)
  |    {
  |       if (matchers != null)
  |       {
  |          matchers.remove(matcher);
  |       }
  |    }
  | 
  |    public boolean isSupportsCandidateAnnotations()
  |    {
  |       return false;
  |    }
  | 
  |    public int getRelativeOrder()
  |    {
  |       return 1;
  |    }
  | }
  | 
It runs right after DeclarativeStructureDeployer.

Actually the parts that recognize if modification should kick in are ModificationTypeMatcher implementations.
They add this information to StructureContext, which then passes it fwd in AbstractStructureDeployer::applyContextInfo
where the real ContextInfo is created or it's directly applied if one of the children sets modification to top level ContextInfo.

Here is an example of such ModificationTypeMatcher.
It matches any path in any deployment level.

  | public class FileModificationTypeMatcher extends AbstractModificationTypeMatcher
  | {
  |    private String[] paths;
  | 
  |    public FileModificationTypeMatcher(String... paths)
  |    {
  |       if (paths == null || paths.length == 0)
  |          throw new IllegalArgumentException("Null or empty paths");
  | 
  |       this.paths = paths;
  |    }
  | 
  |    /**
  |     * Get the starting file.
  |     *
  |     * @param structureContext the structure context
  |     * @return the startting file; where do we start checking for paths
  |     */
  |    protected VirtualFile getStartingFile(StructureContext structureContext)
  |    {
  |       return structureContext.getFile();
  |    }
  | 
  |    protected boolean isModificationDetermined(StructureContext structureContext)
  |    {
  |       VirtualFile startingFile = getStartingFile(structureContext);
  |       for (String path : paths)
  |       {
  |          try
  |          {
  |             if (startingFile.getChild(path) != null)
  |                return true;
  |          }
  |          catch (Exception e)
  |          {
  |             log.debug("Cannot determine modification type, cause: " + e);
  |          }
  |       }
  |       return false;
  |    }
  | }
  | 
e.g. we could look for META-INF/web-beans.xml (still using the old name)

Wdyt, too much of a hack?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204460#4204460

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204460