November 2008 - jboss-dev-forums - Jboss List Archives

[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

1
0
0 / 0

[Design of POJO Server] - Re: MetaValue representation of javax.management.ObjectNames

by scott.stark＠jboss.org

Looking at the MetaMapper class more, its not a registry of mappers. The static getMetaMapper(TypeInfo typeInfo) method derives the MetaMapper from either an attachment on the TypeInfo, or a MetaMapping annotation on the java type (ClassInfo). I'm not sure what the hooks are for introducing an attachment or an annotation on jdk types like javax.management.ObjectName are. ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191487#4191487 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191487

17 years, 4 months

1
0
0 / 0

[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

1
0
0 / 0

[Design of POJO Server] - Re: MetaValue representation of javax.management.ObjectNames

by scott.stark＠jboss.org

Ok, sounds good. I'm going to change the current @ManagementProperty.marshallerFactory field to a MetaMapper from an InstanceClassFactory as that iface has too evolved into something beyond a simple MetaValue/value conversion iface. I'm going to create a MetaValueMapper interface that MetaMapper implements and use MetaValueMapper as the ManagementProperty.valueMapper field. https://jira.jboss.org/jira/browse/JBMAN-43 https://jira.jboss.org/jira/browse/JBMAN-44 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191485#4191485 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191485

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: xml persistent format for attachments

by emuckenhuber

"scott.stark(a)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!? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191477#4191477 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191477

17 years, 4 months

1
0
0 / 0

[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

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Large message code review

by timfox

Another point: ClientMessage:isLargeMessage() ClientMessage:setLargeMessage() is only getting called for file messages, not large messages in general. Also in ServerConsumerImpl: Ugly instanceof check: if (message instanceof ServerLargeMessage) { Instead, how about moving isLargeMessage to the Message interface so it's implemented by both ClientMessage and ServerMessage, and it can be specified in the constructor? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191468#4191468 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191468

17 years, 4 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Missing integration source jars

by pgier

The cache is in the "target" directory in thirdparty. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191450#4191450 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191450

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Handling of null native values

by alesj

Done. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191446#4191446 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191446

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Handling of null native values

by scott.stark＠jboss.org

Will do View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191445#4191445 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191445

17 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2008