[Design of POJO Server] - Re: xml persistent format for attachments
by emuckenhuber
"scott.stark(a)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(a)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 ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191488#4191488
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191488
17 years, 4 months
[Design of POJO Server] - Re: xml persistent format for attachments
by scott.stark@jboss.org
"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?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191486#4191486
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191486
17 years, 4 months
[Design of POJO Server] - Re: MetaValue representation of javax.management.ObjectNames
by emuckenhuber
"scott.stark(a)jboss.org" wrote : The type on the underlying mbean is ObjectName, so either we could create a ObjectNameMetaValueHandler to simplify the building/viewing of the CompositeValue, or make use of the ManagementProperty.marshallerFactory() to map the ObjectName to/from a string MetaValue. This later bit does not seem tested, so I'll have to look at that.
|
| In terms of the values not being set, I'll update our JmsDestinationUnitTestCase to set these values and assert that they are not null.
|
How about using a MetaMapper for transforming ObjectNames, as this already exists.
something like:
| public class ObjectNameMetaMapper extends MetaMapper<ObjectName>
| {
|
| @Override
| public MetaType getMetaType()
| {
| return SimpleMetaType.STRING;
| }
|
| @Override
| public MetaValue createMetaValue(MetaType metaType, ObjectName object)
| {
| return SimpleValueSupport.wrap(object.getCanonicalName());
| }
|
| @Override
| public ObjectName unwrapMetaValue(MetaValue metaValue)
| {
| return internalUnwrap(metaValue);
| }
| }
|
And add a static mapping to the MetaMapper for that, as this seems to be a common use case?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191475#4191475
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191475
17 years, 4 months