13 Replies Latest reply on Jan 17, 2007 1:32 PM by bill.burke

    SerializableDeploymentRepository notions

    starksm64

      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.

        • 1. Re: SerializableDeploymentRepository notions
          bill.burke

          so how are the objects serialized up? Do you precompile? Or will it just do it?

          • 2. Re: SerializableDeploymentRepository notions
            starksm64

            Its done dynamically as part of the deployment processing of the profile. If a DeploymentContext does not have predetermined managed objects its run through the MainDeployer.process to the CLASSLOADER_DEPLOYER and then the profile.updateDeployment so that the attachments can be saved. Its just object serialization of the context attachments object at that point using the serializer associated with the repository.

            • 3. Re: SerializableDeploymentRepository notions
              bill.burke

              So does a specific deployer need to change to take advantage of this? I'm thinking yes, because the XML or other source of metadata may have been updated in the meantime.

              • 4. Re: SerializableDeploymentRepository notions
                starksm64

                The deployers need to have a stable api relative to the serialization format. That can be based on a stable pojo object model that is binary compatible as it evolves, or a serializer that deals with evolution. Right now the serialization is not a function of the attachment type, but that is what I want to support.

                • 5. Re: SerializableDeploymentRepository notions
                  bill.burke

                   

                  "scott.stark@jboss.org" wrote:
                  The deployers need to have a stable api relative to the serialization format. That can be based on a stable pojo object model that is binary compatible as it evolves, or a serializer that deals with evolution. Right now the serialization is not a function of the attachment type, but that is what I want to support.



                  im not thinking of evolution, more of that the app developer has updated an XML file/annotation in their application/deployment

                  • 6. Re: SerializableDeploymentRepository notions
                    starksm64

                    If that happens then the pre-processed attachments need to be thrown away. This is a check that needs to be added to the loadAttachments logic. If a raw deployment is newer than the attachments the are thrown away.

                    Now if there are also admin edits, whether or not they can be reapplied will depend on the change and how the edits are stored.

                    • 7. Re: SerializableDeploymentRepository notions
                      bill.burke

                      Don't see how the current logic could work with exploded archive. You have the "WATCH FILE" problem all over again. A deploymentContext could have a number of attachments associated with it that are loaded from different deployers and multiple files. One attachment could even be loaded from multiple files. This logic is going to need callbacks to the deployer that needs the attachment so that the deployer can identify timestamps to check the serialization event against.

                      • 8. Re: SerializableDeploymentRepository notions
                        starksm64

                        That really should be an optional development type feature where a vfs visitor provides the deployment timestamp. If the visitor is configured then edits made outside of the profile service can be identified. The simplest initial implementation is to simply touch the top level deployment anytime content is changed.

                        • 9. Re: SerializableDeploymentRepository notions
                          bill.burke

                          So, you're going to have a generic service check every timestamp of, of every file in the deployment context? Still think it would be much simpler if the deployers control this as they know exactly what files to look for and what timestamps of what files to store in the attachment serialization. They would even be able to control whether or not serialization is allowed for that type of deployment.

                          • 10. Re: SerializableDeploymentRepository notions
                            starksm64

                            It should be a pluggable visitor implementation. How much you want to check is up to you. Having the deployers check is essentially is a structural scan with a list of files to check. It would be better to have deployers expose the metadata vfs paths that should go into timestamp verification and feed them into a simple vfs visitor that can return the most recently modified file amongh the patterns. This is bolierplate code that every deployer should not be repeating mister monolithic deployer writer.

                            • 11. Re: SerializableDeploymentRepository notions
                              bill.burke

                              I'm thinking of:

                              DeploymentContext.getAttachments().addAttachment(key, value, List<VirtualFile> metaSources);
                              


                              Then, when getAttachment() is called, DC scans and checks to see if that attachment should be killed.

                              Also, there should be additional methods on DeploymentContext:

                              
                              getAttachments();
                              getManagedObjects();
                              
                              


                              These attachments would actually be serialized with the profile while getTransientAttachments() would not.

                              If i'm being too obvious, then apologies.






                              • 12. Re: SerializableDeploymentRepository notions
                                starksm64

                                 

                                "bill.burke@jboss.com" wrote:
                                I'm thinking of:

                                DeploymentContext.getAttachments().addAttachment(key, value, List<VirtualFile> metaSources);
                                


                                Then, when getAttachment() is called, DC scans and checks to see if that attachment should be killed.

                                It should be the repository that scans the deployment and throws aways preprocessed content, not the DC. The repository could already have an index of metadata files, etc. I would rather have the api just provide the DC relative metadata file path than the full VirtualFile.

                                "bill.burke@jboss.com" wrote:

                                Also, there should be additional methods on DeploymentContext:

                                getAttachments();
                                getManagedObjects();
                                


                                These attachments would actually be serialized with the profile while getTransientAttachments() would not.

                                If i'm being too obvious, then apologies.

                                There is no difference between getAttachments() and getManagedObjects(). Both are attachments, or are you saying you want to express a DC ManagedObject at that level rather than use the ManagedObjectBuilder:
                                public interface ManagedObjectBuilder
                                {
                                 /**
                                 * Build managed objects for this deployment context
                                 *
                                 * @param unit the deployment unit
                                 * @param managedObjects the managed objects
                                 * @throws DeploymentException
                                 */
                                 void build(DeploymentUnit unit, Map<String, ManagedObject> managedObjects) throws DeploymentException;
                                }
                                




                                • 13. Re: SerializableDeploymentRepository notions
                                  bill.burke

                                   

                                  There is no difference between getAttachments() and getManagedObjects(). Both are attachments, or are you saying you want to express a DC ManagedObject at that level rather than use the ManagedObjectBuilder: ]

                                  Im saying that I want to be able to control which attachments get serialized and which dont (like our Payload shit in INvocation)