[Design of JBossXB] - Re: Collections with interfaces
by scott.stark@jboss.org
This is due to this code block not checking the localPropertyType for the XmlType annotation:
| else if (propertyType.isCollection() && ((ClassInfo) propertyType).getUnderlyingAnnotation(XmlType.class) == null)
| {
| isCol = true;
| propertyHandler = new CollectionPropertyHandler(property, propertyType);
| ClassInfo typeArg = (ClassInfo) findComponentType(property);
|
| //if (((ClassInfo) typeArg).getUnderlyingAnnotation(XmlType.class) != null)
| if (typeArg != null && typeArg.getUnderlyingAnnotation(JBossXmlModelGroup.class) == null)
| {// it may be a model group in which case we don't want to change the type
|
| // TODO yes, this is another hack with collections
| JBossXmlChild xmlChild = ((ClassInfo) propertyType).getUnderlyingAnnotation(JBossXmlChild.class);
| if (xmlChild == null && localPropertyType.equals(propertyType))
| { // the localPropertyType was not overriden previously so use the collection parameter type
| localPropertyType = typeArg;
| }
| }
| }
|
when the property type is a parameterized interface, the localPropertyType refers to the real type that carries the annotation information. Changing the check to be:
| else if (propertyType.isCollection() && ((ClassInfo) localPropertyType).getUnderlyingAnnotation(XmlType.class) == null)
| {
|
gets the parsing to occur as I expect.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097301#4097301
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097301
18 years, 7 months
[Design of JBossXB] - Collections with interfaces
by scott.stark@jboss.org
When I switched the EnterpriseBeansMetaData to extend AbstractMappedMetaData instead of AbstractMappedMetaData, the child elements are lost:
| @XmlType(name="enterprise-beansType")
| public class EnterpriseBeansMetaData
| extends AbstractMappedMetaData<IEnterpriseBeanMetaData>
| implements IEnterpriseBeansMetaData
| {
|
Its the implementations of IEnterpriseBeanMetaData that would have the annotations:
| @JBossXmlModelGroup(
| kind=JBossXmlConstants.MODEL_GROUP_CHOICE,
| particles={
| @JBossXmlModelGroup.Particle(element=@XmlElement(name="session"), type=SessionBeanMetaData.class),
| @JBossXmlModelGroup.Particle(element=@XmlElement(name="entity"), type=EntityBeanMetaData.class),
| @JBossXmlModelGroup.Particle(element=@XmlElement(name="message-driven"), type=MessageDrivenBeanMetaData.class)})
| public abstract class EnterpriseBeanMetaData extends NamedMetaDataWithDescriptionGroup
| implements Environment,
| IEnterpriseBeanMetaData
| {
|
How would I propagate this info up to the EnterpriseBeansMetaData class?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097231#4097231
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097231
18 years, 7 months
[Design of JBossCache] - Re: Node removal not working with Invalidation?
by manik.surtani@jboss.com
"bstansberry(a)jboss.com" wrote :
| I was trying to think how this could break things; e.g. app removes some data and then tries to recreate it. Say an admin creates a "user" account entity; realizes he's mucked it up, deletes it and starts over with the same id. He could get version conflicts when he starts over.
|
Well, not necessarily. Version != identity. He would be allowed to add it again, the version would increment without a problem. Where it *does* step in is if 2 admins attempt to create the same id, but that is a valid conflict anyway.
"bstansberry(a)jboss.com" wrote :
| 3) If explicit data versioning is used, it could be a problem. But perhaps that can be handled in the Hibernate/JBC integration, which separately handles cache insertions of newly created entities.
Again, it shouldn't be a problem if used correctly. Explicit versioning should only be used if there is an external "true representation of state" (such as a database) which also maintains versioning for that state. Explicit versioning is only meant to be a way to expose the versioning maintained by the database.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097214#4097214
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097214
18 years, 7 months
[Design of JBossCache] - Concurrency issues on remote prepare when using optimistic l
by manik.surtani@jboss.com
This is in relation to JBCACHE-1201.
So this is in no way an easy fix. The main problem here is that when a cache enters it's prepare phase, modifications are broadcast, but the remote cache hasn't really entered the prepare phase so locks aren't acquired when you use OL. When the originating cache enters it's commit phase, then commit() is called on the remote cache's tx - which then causes it to enter it's prepare phase - and acquire locks - and then commit.
The only real solution I can think of, given the way we replicate at transaction boundary, is to actually use the PLI on remote caches, so that even when the originating cache enters it's prepare phase, remote caches obtain locks. But this opens up all sorts of other problems. Maybe the OptimisticLockInterceptor should obtain WLs for all method calls if the call's origin is remote, i.e., part of a remote prepare. Still, potentially a hairy situation - I'd rather defer for now given that there is a workaround (to set SyncCommitPhase and SyncRollbackPhase to true). Potentially even not fix this, given that this will change pretty drastically with MVCC.
WDYT?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097198#4097198
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097198
18 years, 7 months