[jboss-dev-forums] [Design of POJO Server] - Re: EARStructure not deploying modules

[scott.stark@jboss.org]

"bill.burke at jboss.com" wrote : 
  | Ok, i stepped through the CandidateVisitor code and it is making sense now.
  | 
  | 1. I think there is a catch 22 in the current code.  The CandidateVisitor will not determineStructure if the ContextInfo already exists in the StructureMetaData.  StructureMetaData does not set the correct parent (and TreeSet order) until a parent has been added.  Get me?
  | 
the current candidate visitor is still too much of a port from the old DeploymentContext notion. One thing we are doing away with is the notion of a "candidate' as is, I'm not sure if this really is a deployment notion. The only things that show up in the StructureMetaData are ContextInfos for something that was recognized. If a deployer allows subdeployments that are not of the type it recognizes, then it delegates to the input deployers to identify the  subdeployments. We just need to get the legacy visitor notions working correctly.

"bill.burke at jboss.com" wrote : 
  | 2. Since the EAR knows the structure of its subdeployments and what virtual files should be candidates, shouldn't it locate candidates and determine their structure rather than delegate it to addAllChildren method that curently exists?
  | 
An ear structure deployer only has partial knowledge of its structure. Namely its lib classpath and what should be considered as possible subdeployments. Yes, it should build the ContextInfo for the ear itself and set the ear lib classpath, and then it should call deployers.determineStructure(moduleFile, metaData, deployers) to validate that the declared ear module file is in fact valid structurally. This is all addAllChildren(VirtualFile parent, StructureMetaData metaData, StructuredDeployers deployers) should be doing though. I have not walked through the catch22 you mentioned to really understand it, but I'm sure its just inconsistent legacy behavior. Its possible that the addAllChildren method should just be dropped since the deployers is all that is likely needed. The only reason I can see keeping it would be for the additional filter notion in the case that a containing deployer wanted to restrict the accepted sub-subdeployments, or maybe externalize the filter for subdeployments.

"bill.burke at jboss.com" wrote : 
  | Are you finishing this code?  I think I know what needs to be done now.
  | 
Yes, I'm working on it.


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

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