1 2 Previous Next 20 Replies Latest reply on Nov 22, 2008 1:57 PM by Scott Stark

    xml persistent format for attachments

    Emanuel Muckenhuber Master

      I created some simple tests trying to persists some metadata as xml with JAXB,
      using ManagedConnectionFactoryDeploymentGroup, ServiceDeployment/ServiceMetaData and AbstractKernelDeployment/AbstractBeanMetaData

      Baiscally for ManagedConnectionFactoryDeploymentGroup the problem is that the @XmlAdapter for the mbean just implements the unmarshal part.
      So there is only ServiceMetaDataParser and nothing equivalent for the marshalling part. So the mbean would get lost :)

      Similar for ServiceDeployment. We could maybe reuse the org.w3c.dom.Element information, although it would need to get updated with the information of the changed ManagedComponent.
      So not sure if updating the element makes more sense than writing a counterpart of the parsing.

      JAXB also does not like the annotated BeanMetaData for marshalling.
      This ends up in a exception like this:

      com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 45 counts of IllegalAnnotationExceptions
      org.jboss.kernel.plugins.deployment.AbstractKernelDeployment#beanFactories has mutually exclusive annotations @javax.xml.bind.annotation.XmlElements and @javax.xml.bind.annotation.XmlAnyElement
      ...
      at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment
       @XmlValue is not allowed on a class that derives another class.
      ...
      


      Although i haven't really looked into that in more detail yet :)

      So maybe we need different xml AttachmentSerializer for each metadata,
      as the deployment descriptors are also parsed differently in the first place?



        • 1. Re: xml persistent format for attachments
          Scott Stark Master

          We need the option to have a AttachmentSerializer per attachment type, but for our own metadata using jaxb, we should fix the marshalling/unmarshalling so its consistent.

          • 2. Re: xml persistent format for attachments
            Emanuel Muckenhuber Master

             

            "scott.stark@jboss.org" wrote:
            We need the option to have a AttachmentSerializer per attachment type, but for our own metadata using jaxb, we should fix the marshalling/unmarshalling so its consistent.


            I do have a JAXBAttachmentSerializer for the local-ds i was testing the attachment persistence with.
            This now also persists the mbean with a basic marshalling implementation of the @XmlJavaTypeAdapter(ServiceMetaDataAdapter.class).
            So it creates a w3c.dom.Element from the ServiceMetaData for that.

            For the ServiceDeployment i think the best we be to add JAXB annotations
            and do the parsing for: LoaderRepositoryConfig, ServiceDeploymentClassPath similiar with an Adapter?
            Well at least it seems to work, and i doubt that we can use JAXB fully for this parsing without changing the whole ServiceMetaData model :)

            • 3. Re: xml persistent format for attachments
              Scott Stark Master

               

              "emuckenhuber" wrote:

              For the ServiceDeployment i think the best we be to add JAXB annotations
              and do the parsing for: LoaderRepositoryConfig, ServiceDeploymentClassPath similiar with an Adapter?
              Well at least it seems to work, and i doubt that we can use JAXB fully for this parsing without changing the whole ServiceMetaData model :)

              We don't need to force the use of jaxb. Just have an AttachmentSerializer for ServiceDeployment that deals with its issues. If you already have a jaxb variation working, great.

              • 4. Re: xml persistent format for attachments
                Emanuel Muckenhuber Master

                 

                "scott.stark@jboss.org" wrote:

                We don't need to force the use of jaxb. Just have an AttachmentSerializer for ServiceDeployment that deals with its issues. If you already have a jaxb variation working, great.


                Well let's say partly - at the moment it is required to leave the initial parsing as it is.
                Otherwise things like nested mbeans would get lost.
                The flattened metadata then can be marshalled/unmarshalled with the JAXBAttachmentSerializer.
                So doing that with the conf/jboss-service.xml looks quite ok,
                but there are still some things missing and this of course needs some testing.

                I committed the things i have for the ManagedConnectionFactoryDeploymentGroup.
                So the attachment of the updated datasource is now persisted in xml.

                Basically all tests in the profileservice target there are passing except:
                org.jboss.test.profileservice.test.SecurityManagedObjectsTestCase, which also fails on hudson.

                • 5. Re: xml persistent format for attachments
                  Emanuel Muckenhuber Master

                  I've added some JAXB annotations plus adapters to the ServiceDeployment
                  and a basic marshalling/unmarshalling testcase.
                  http://anonsvn.jboss.org/repos/jbossas/trunk/testsuite/src/main/org/jboss/test/profileservice/persistenceformat/test/JBossServicePersistenceFormatTestCase.java

                  As mentioned before, if the initial parsing is done as it's now it now works
                  to marshal/unmarshal the flattened serviceDeployment metadata and services
                  with the JAXBAttachmentSerializer.

                  • 6. Re: xml persistent format for attachments
                    Adrian Brock Master

                    Sorry to interrupt your flow of conversation, but I was thinking about this last night.

                    Why are you trying to serialize the attachments?

                    Wouldn't it be more logical to serialize the ManagedObject and then recreate
                    the attachment from that?

                    I imagine its a lot easier to write a single MO <-> xml marshaller/unmarshaller
                    than to do the same for all metadata (especially when some of it may have
                    been created by thirdparties so we have no control of the actual attachment classes).

                    In terms of MO<->xml all you need to do is marshal the value of the fields
                    which are a small list of known MetaTypes/Values.

                    • 7. Re: xml persistent format for attachments
                      Sacha Labourey Master

                      Well, glad you are raising this :) This is exactly what I was trying to say to Emmanuel the other day coming back from lunch but failed to expose with such precise terminology. Seems much easier to me.

                      • 8. Re: xml persistent format for attachments
                        Scott Stark Master

                        Good point, the main drawback that has been raised is a completely different format from the original deployment descriptor. Reliability of the attachment serialization/deserialization would definitely be a priority though.

                        • 9. Re: xml persistent format for attachments
                          Scott Stark Master

                          Also, if we are only persisting the managed object view of the attachment, it won't be a predetermined attachment any longer. Its a delta against the original transient managed attachment, so we would have to integrate the change in a PRE_REAL deployer. Not that this is a big issue, but there is no authoritative view of the metadata out on disk somewhere.

                          • 10. Re: xml persistent format for attachments
                            Emanuel Muckenhuber Master

                             

                            "scott.stark@jboss.org" wrote:
                            Also, if we are only persisting the managed object view of the attachment, it won't be a predetermined attachment any longer. Its a delta against the original transient managed attachment, so we would have to integrate the change in a PRE_REAL deployer. Not that this is a big issue, but there is no authoritative view of the metadata out on disk somewhere.


                            Concerning unmarshalling of the persisted attachment i think we can try to rebuild the ManagedObject
                            from the metadata and due to this WritethroughManagedProperty we actually should be able to directly reuse the attachment.
                            Most probably there are some ManagementProperty annotations missing in some parts (e.g. ServiceMetaData)
                            to persist and restore everything needed, as i'm currently only planning to persist ViewUse.CONFIGURATION only.

                            But maybe we want to do the delta thing later on and see how far we can get with restoring the attachment that way?
                            As it should not require changes to the persistence format itself.



                            • 11. Re: xml persistent format for attachments
                              Emanuel Muckenhuber Master

                              Ah before i forget, i think we should update the DeploymentRepository interface to:

                               public void updateDeployment(VFSDeployment d, DeploymentPhase phase, ManagedComponent component)
                              
                              or
                              
                               public void updateDeployment(VFSDeployment d, DeploymentPhase phase, ManagedObject object)
                              
                              instead of:
                              
                               public void updateDeployment(VFSDeployment d, DeploymentPhase phase, Map<String, Object> attachments)
                              


                              Baiscally i'm already putting the ManagedComponent in the map to persist the attachment.

                              Furthermore i think we could delete the:
                               public void addManagedObject(String vfsPath, Attachments edits)
                              

                              as this does not seem to make sense anymore. Maybe we can add something similar later on if needed.

                              • 12. Re: xml persistent format for attachments
                                Scott Stark Master

                                 

                                "emuckenhuber" wrote:

                                Concerning unmarshalling of the persisted attachment i think we can try to rebuild the ManagedObject
                                from the metadata and due to this WritethroughManagedProperty we actually should be able to directly reuse the attachment.
                                Most probably there are some ManagementProperty annotations missing in some parts (e.g. ServiceMetaData)
                                to persist and restore everything needed, as i'm currently only planning to persist ViewUse.CONFIGURATION only.

                                But maybe we want to do the delta thing later on and see how far we can get with restoring the attachment that way?
                                As it should not require changes to the persistence format itself.

                                I'm not really following. You have the marshalled form of the ManagedObject and build it back up, to apply to the deployment attachment or are you talking about something else?


                                • 13. Re: xml persistent format for attachments
                                  Scott Stark Master

                                   

                                  "emuckenhuber" wrote:
                                  Ah before i forget, i think we should update the DeploymentRepository interface to:
                                  ...


                                  Ok, I'll make those changes.

                                  • 14. Re: xml persistent format for attachments
                                    Scott Stark Master

                                    The DeploymentRepository spi has been updated with this change.

                                    1 2 Previous Next