[jboss-dev-forums] [Design of POJO Server] - SerializableDeploymentRepository notions

[scott.stark@jboss.org]

So the majority of the repository based profile service is in the SerializableDeploymentRepository. This is an implementation of DeploymentRepository that relies on object serialization to store contents on the file system. The serialization is pluggable, so while today its simple java serialization, it could (and will be) jboss serization to an xml file to allow for a better long term storage format. It could be jdbc or something else as well if desired.

The repository uses the following locations under the {name} profile root:

root/{name}/bootstrap - the bootstrap beans
root/{name}/deployers - profile deployers
root/{name}/deploy - installed deployments
root/{name}/apps - post install deployments
root/{name}/attachments - pre-processed deployment metadata attachments
root/{name}/profile/edits - admin edits to deployments 

A DeploymentContext refers to the raw unedited deployment archive/directory, and when a DeploymentContext is processed through the MainDeployer.process(-1, Deployer.CLASSLOADER_DEPLOYER), the profile and by delegation the repository is updated with the parses metadata pojos. What needs to happen is that when a DeploymentContext is loaded from the repository and it has pre-parsed attachments, these are set as the getPredeterminedManagedObjects(). If there are admin edits then the attachments come from the profile/edits override of the attachments.

If a DeploymentContext has a non-empty getPredeterminedManagedObjects() attachments, processing should begin at the Deployer.CLASSLOADER_DEPLOYER and all attachment processing is skipped.

This check and deployer bypass logic should happen in the MainDeployerImpl. 


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

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