-
15. Re: EARStructure not deploying modules
"scott.stark@jboss.org" wrote:
"bill.burke@jboss.com" wrote:
addAllChildren isn't the way to go because the ear only deploys those things at the top level or those deployed in application.xml ... plus ... jars in the lib/ directory (for JPA).
So, why did you remove the code in the old EarStructure code that I wrote that created DeploymentContexts? WHo is responsible for creating the deployment contexts in the EAR and determining their structure?
I am really confused on WTF is going on. It was pretty clear before, but with this structure metadata it is not anymore...
I said an addAllChildren that started at each file listed in the ear modules. The DeploymentContext is a mix of structure info and runtime metadata like the object models for ear descriptors. The StructureMetaData is to describe exactly what contexts in the vfs should be treated as deployment contexts, what the context classpaths are, and what the parent child relationships are. That is input to the MainDeployer to initiate the runtime deployment where the metadata can be obtained from the DeploymentContexts (created by the MainDeployer.StructureBuilder) using the associated virtual file and classpath info.
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?
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?
Are you finishing this code? I think I know what needs to be done now.
Thanks for being patient. -
16. Re: EARStructure not deploying modules
"bill.burke@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@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@jboss.com" wrote:
Are you finishing this code? I think I know what needs to be done now.
Yes, I'm working on it. -
17. Re: EARStructure not deploying modules
The other place where the visitor pattern used by addAllChildren could be applied is to the not-yet-implemented ear scanning behavior in the absence of an application.xml. Maybe you can look at implementing that?
-
18. Re: EARStructure not deploying modules
The one place where we still might need some enhancement is a notion of options/properties at the ContextInfo level. We are currently throwing away information like what structure deployer produced a given ContextInfo. We may want additional attributes like:
type=jsr77 type or deployer type in terms of structure
name=an alternate name for a context. This could be used to build a structure tree graph that has names different than the raw vfs paths. -
-
20. Re: EARStructure not deploying modules
Not producing ContextInfos. This code:
if (scan) { JARCandidateStructureVisitorFactory factory = new JARCandidateStructureVisitorFactory(); final J2eeApplicationMetaData my = metaData; factory.setFilter(new VirtualFileFilter() { public boolean accepts(VirtualFile file) { if (my.hasModule(file.getName())) return false; return true; } }); VirtualFileVisitor visitor = factory.createVisitor(context, null); root.visit(visitor); }
would need to be ported to create ContextInfos. I also do not see where the J2eeApplicationMetaData is created in the first placed based on annotations. The only place there the J2eeApplicationMetaData is populated is when its imported from the xml descriptors. If the J2eeApplicationMetaData has the module, there is no reason to scan so this looks like circular code to me. -
21. Re: EARStructure not deploying modules
A number of the ejb3 tests are deploying remotely and from the deploy dir. One ear that is having deployment failures is the factory-test.ear. There is a failure to find a META-INF/persistence.xml is a nested jar although the file does exist:
Caused by: java.io.FileNotFoundException: /tmp/nestedjar45108.tmp/META-INF/persistence.xml at org.jboss.net.protocol.file.FileURLConnection.connect(FileURLConnection.java:94) at org.jboss.net.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:103) at java.net.URL.openStream(URL.java:1007) at org.hibernate.ejb.packaging.PersistenceXmlLoader.loadURL(PersistenceXmlLoader.java:43) at org.hibernate.ejb.packaging.PersistenceXmlLoader.deploy(PersistenceXmlLoader.java:73) at org.jboss.ejb3.Ejb3Deployment.initializePersistenceUnits(Ejb3Deployment.java:450) at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:314) at org.jboss.ejb3.deployers.EJBRegistrationDeployer.deploy(EJBRegistrationDeployer.java:137) ... 12 more *** DEPLOYMENTS IN ERROR: Name -> Error jar:file:/home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.Beta/server/default/deploy/factory-test.ear!/session1.jar -> java.io.FileNotFoundException: /tmp/nestedjar45104.tmp/META-INF/persistence.xml jar:file:/home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.Beta/server/default/deploy/factory-test.ear!/session2.jar -> java.io.FileNotFoundException: /tmp/nestedjar45108.tmp/META-INF/persistence.xml 23:40:22,093 INFO [Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8080 23:40:22,118 INFO [AjpProtocol] Starting Coyote AJP/1.3 on ajp-0.0.0.0-8009 23:40:22,120 INFO [ServerImpl] JBoss (Microcontainer) [5.0.0.Beta (build: CVSTag=HEAD date=200610262157)] Started in 15s:241ms ... [starksm@succubus Security]$ jar -tf /tmp/nestedjar45108.tmp META-INF/ META-INF/MANIFEST.MF org/ org/jboss/ org/jboss/ejb3/ org/jboss/ejb3/test/ org/jboss/ejb3/test/factory/ org/jboss/ejb3/test/factory/Entity2.class org/jboss/ejb3/test/factory/MyService.class org/jboss/ejb3/test/factory/MyServiceBean.class org/jboss/ejb3/test/factory/Session2.class org/jboss/ejb3/test/factory/Session2Bean.class META-INF/persistence.xml
The vfs does not use the no copy nested jar code by default. I'll look into this error more tomorrow. -
22. Re: EARStructure not deploying modules
I'm back to where I was before :) I can continue from ere.