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

[Design of JBoss jBPM] - Re: jBPM 3.3 GA feedback in the user forum

by kukeltje

Just to let you guys know the urgency of this: I'm not going to answer those..... and it will make jBPM look bad if it is not solved in 3.3.1 (7 weeks still????) I think something should be updated before that... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191512#4191512 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191512

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM 3.3 GA feedback in the user forum

by kukeltje

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

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Adding handy isInstance(Object) method to TypeInfo

by alesj

I'm thinking about adding convenient isInstance method to TypeInfo. On ClassInfoImpl/JavassistTypeInfo it would use getType::isInstance, but on PrimitiveInfo it would still look into progression. The method would hide simple impl detail. | TypeInfo ti = ...; | Object value = ...; // not null | | //long version | TypeInfoFactory tif = ti.getTypeInfoFactory(); | TypeInfo other = tif.getTypeInfo(value.getClass()); | boolean isInstance = ti.isAssignableFrom(other); | | // short | boolean isInstance = ti.isInstance(value); | | // where this doesn't consider progression | boolean isInstance = ti.getType().isInstance(value); | OK? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191505#4191505 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191505

17 years, 4 months

1
0
0 / 0

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

by alesj

"scott.stark(a)jboss.org" wrote : | I guess we need a transient Attachments notion where server specific information could be placed | You already have this in TypeInfo. e.g. | /** The attachments */ | private transient TypeInfoAttachments attachments; | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191500#4191500 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191500

17 years, 4 months

1
0
0 / 0

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

by scott.stark＠jboss.org

One problem with inclusion of something like a MetaMapper class in the ManagementProperty annotation is that its leaking server side types to the client since MetaMapper will reference the server side java class. If this is used by an attachment to map a non-simple deployment type to a CompostiteValue for example, this can't be marshaled to the client environment as thta type will not be available. I guess we need a transient Attachments notion where server specific information could be placed, and have a convention of looking for the MetaMapper.class attachment in the AbstractManagedObjectFactory. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191498#4191498 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191498

17 years, 4 months

1
0
0 / 0

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

by alesj

"scott.stark(a)jboss.org" wrote : I'm not sure what the hooks are for introducing an attachment or an annotation on jdk types like javax.management.ObjectName are. ? Something like this: | public <T> void registerMapper(Class<T> clazz, MetaMapper<T> metaMapper) | { | ClassInfo ci = configuration.getClassInfo(clazz); | ci.setAttachment(MetaMapper.class.getName(), metaMapper); | } | | MetaMapper<ObjectName> onMetaMapper = new ObjectNameMetaMapper(); | registerMapper(ObjectName.class, onMetaMapper); | You only need to be careful for transient ClassInfos, since it's all weak (value) hash map in the background. But for jdk classes this should stick in there forever. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191493#4191493 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191493

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 : | 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191492#4191492 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191492

17 years, 4 months

1
0
0 / 0

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

by scott.stark＠jboss.org

I would add the registry to the AbstractManagedObjectFactory so that when it creates ManagedPropertys it could set the mapper if the property has a known type and does not have mapper defined at the property level. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191491#4191491 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191491

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 : 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. ? Hmm well i was rather thinking of adding a static registry for types we cannot easily annotate ourself? So that this is checked before it tries to the process the annotation. I think that would be the easiest way - especially for very basic transformations like this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191490#4191490 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191490

17 years, 4 months

1
0
0 / 0

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

by scott.stark＠jboss.org

Also, I guess there is no advantage to a MetaValueMapper interface, so the valueMapper would just be an extension of the MetaMapper class. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191489#4191489 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191489

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