xml persistent format for attachments

[emuckenhuber]

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?

[starksm64]

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.

[emuckenhuber]

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 :)

[starksm64]

"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.

[emuckenhuber]

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.

[emuckenhuber]

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.

[adrian.brock]

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.

[slaboure]

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.

[starksm64]

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.

[starksm64]

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.

[emuckenhuber]

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.

[emuckenhuber]

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.

[starksm64]

"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?

[starksm64]

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

Ok, I'll make those changes.

[starksm64]

The DeploymentRepository spi has been updated with this change.