How should recursive .sar deployment work - or should it? The new *-service.xml format has a classpath element that contains references to packages needed for the current package. Marc assumed that the entries here would be only jars, so all we have to do is load them. However, its easy to extend this so they can be sars, *-service.xmls, or jars. This allows one package to recursively deploy all packages it depends on -- so I could deploy say a package containing my datasource setup, and through recursive dependincies, that would deploy all of (non spine) jboss. I think this is pretty neat, however there are a couple of complications when it comes time to undeploy - or autodeploy. 1. Undeploy ought to be the inverse of deploy - if we recursively deployed a bunch of stuff, we should recursively undeploy it. 2. Redeploying a package undeploys and deploys it. 3. Autodeploy currently doesn't have any ordering on how it deploys stuff. So here's an example of the problems: Suppose we have two packages A and B, B depends on A. We want them deployed so that B can be removed without removing A. A naive implementation may result in this: Autodeployer deploys B first This recursively deploys A Autodeployer deploys A This undeploys A, undeploying B, redeploys A, which redeploys B All we really wanted was "mark A so if we undeploy B, A stays" I've thought of 3 solutions, and would like comments. 1. Drop recursive deployment feature ;-( 2. Include in the classpath element of *-service.xml whether the package mentioned should be undeployed when the current package is undeployed. 3. Modify autodeployer so it keeps track of everything deployed in a autodeployment pass and only registers packages it is supposed to autodeploy that were recursively deployed in the same pass. This would need deployment notifications, which have been requested anyway. In our example, B deploying would cause A then B to deploy. Autodeployer, considering deploying A, would look at its list of "just deployed", see A in it, and just register A so it won't be undeployed if B is undeployed: this is to avoid the churn in the naive implementation. Are there some other possibilities? I think if we don't do (1) the classpath element should be renamed dependencies and we should allow multiple instances, so we can depend on packages in many locations rather than insisting on a single directory. So, I hope I've included enough detail so this is comprehensible :-) Please ask if this is not clear. david jencks _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
