-
15. Re: xml persistent format for attachments
"scott.stark@jboss.org" wrote:
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?
Basically what i meant is that if we do something like:ManagedObject mo = managedObjectFactory.createManagedObject(SomeClass.class, null); ManagedProperty p = result.getProperty("objectName"); p.setValue(SimpleValueSupport.wrap("jboss:service=Hypersonic,database=profileserviceTestDB")); SomeClass object = mo.getAttachment();
So if SomeClass is properly annotated and we persist actually everything needed, we could use this as predetermined attachment;
as those changes are already updated in the metadata model through the WritethroughManagedPropertyImpl.
If we want to just update the delta then the ManagedComponent from the ManagementView should actually only contain the changed values.
We then would need to merge those changes with the xml (if it already contains some previous values), and apply this during deployment to the metadata itself. -
16. Re: xml persistent format for attachments
The problem is most metadata build from scratch like that with just the ManagedObject property values is not going to be complete. We will have to just write out the deltas and apply those to the corresponding attachment before the component deployers run.
-
17. Re: xml persistent format for attachments
"scott.stark@jboss.org" wrote:
The problem is most metadata build from scratch like that with just the ManagedObject property values is not going to be complete. We will have to just write out the deltas and apply those to the corresponding attachment before the component deployers run.
Hmm okay, fine for me, as updating seems to be a easier than building that from scratch anyway :)
Although i think this would also require that ManagementView just pass the changed values to the deploymentRepository.
Furthermore it makes the ManagementObjectID immutable. As there needs to be a identifier to merge a collection of managed objects!? -
18. Re: xml persistent format for attachments
"emuckenhuber" wrote:
Although i think this would also require that ManagementView just pass the changed values to the deploymentRepository.
That is what is happening already though since the input is the ManagedComponent that was updated. We would only be writing out properties that have non-null values. I suppose this should go further and only write out properties that were explicitly updated, is that what you mean? We would need an isEdited flag on ManagedProperty for that."emuckenhuber" wrote:
Furthermore it makes the ManagementObjectID immutable. As there needs to be a identifier to merge a collection of managed objects!?
I don't follow. For a KernelDeployment for an mcbeans deployment, there is:
ManagedObject(KernelDeployment)
+ beanFactories = ManagedObject[](BeanMetaDataFactory)
where each BeanMetaDataFactory has a beans property of type ManagedObject(@ComponentType={MCBean,*},BeanMetaData)[] for the mcbeans compoment that maps to a ManagedComponent. The id is the name of the bean for the components, for the factories it would have to be the index in the array.
Are you talking about the id changing from Bean1 to Bean1.1? -
19. Re: xml persistent format for attachments
"scott.stark@jboss.org" wrote:
That is what is happening already though since the input is the ManagedComponent that was updated. We would only be writing out properties that have non-null values. I suppose this should go further and only write out properties that were explicitly updated, is that what you mean? We would need an isEdited flag on ManagedProperty for that.
Well i do persist everything. Also null values, because i think it should be possible to change the value to null (e.g. for a String) ?
What i mean is more or less a isEdited flag - so that i can differentiate between values which are from the original deployment descriptor
(which do not need to be persisted) and changed values.
At the moment letting that run over a ManagedComponentFactoryDeployment i get a 10 times bigger attachment as the original deployment descriptor ;)
This is also because of some additional information and a more generic xml structure.
Most probably can remove some additional information as the marshalling/unmarshalling heavily depends on the created ManagedObject with MetaTypes anyway - i'll take a look at that when it's done.
And i think we also need a isRemoved flag for the ManagedProperty.
e.g. if you have a list of properties and you want to remove one property
we would need to persist that too and remove that when updating the persisted attachment..."scott.stark@jboss.org" wrote:
I don't follow. For a KernelDeployment for an mcbeans deployment, there is:
ManagedObject(KernelDeployment)
+ beanFactories = ManagedObject[](BeanMetaDataFactory)
where each BeanMetaDataFactory has a beans property of type ManagedObject(@ComponentType={MCBean,*},BeanMetaData)[] for the mcbeans compoment that maps to a ManagedComponent. The id is the name of the bean for the components, for the factories it would have to be the index in the array.
Are you talking about the id changing from Bean1 to Bean1.1?
Hmm what i mean is that if you have a collection of ManagedObjects which represent for example your datasources or beans.
And you update one of them it would be good to have a identifier to see which ManagedObject to update.
Because if the order of this collection (for some reason) changes, it will just change the properties of a different bean or datasource.
Making the ManagedObjectID required and immutable, would help to identify that again...
Not sure if there is a different way to do that ? -
20. Re: xml persistent format for attachments
"emuckenhuber" wrote:
Well i do persist everything. Also null values, because i think it should be possible to change the value to null (e.g. for a String) ?
What i mean is more or less a isEdited flag - so that i can differentiate between values which are from the original deployment descriptor
(which do not need to be persisted) and changed values.
...
And i think we also need a isRemoved flag for the ManagedProperty.
e.g. if you have a list of properties and you want to remove one property
we would need to persist that too and remove that when updating the persisted attachment...
Ok, I'll add isEdited and isRemoved/remove notions."emuckenhuber" wrote:
Hmm what i mean is that if you have a collection of ManagedObjects which represent for example your datasources or beans.
And you update one of them it would be good to have a identifier to see which ManagedObject to update.
Because if the order of this collection (for some reason) changes, it will just change the properties of a different bean or datasource.
Making the ManagedObjectID required and immutable, would help to identify that again...
Not sure if there is a different way to do that ?
The problem is that ManagedObjectID is generally derived from a property like the bean name or the jndi name. Your essentially talking about a standard xml ID that uniquely creates an association between the attachment and ManagedObject. We don't specify this today and its too burdensome to require all descriptors be changed to have an id. The problem does exist for changing what the original deployment ManagedObjectID is as well, for example changing the DefaultDS jndi-name to MyDefaultDS. For that we would have to have the original ManagedObjectID.