October 2007 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: metadata simplication

by wolfc

On 3: if we have a merge method with two jboss views, we can merge jboss view, standard jboss view and annotation view by just doing the motions: JBossMetaData standardJbossXml = unmarshall | JBossMetaData jbossXml = unmarshall | EjbJarMetaData ejbJarXml = unmarshall | if(!ejbJarXml.isMetaDataComplete()) | { | JBossMetaData annotationMetaData = .... (creator something) | merged = Merger.merge(standardJbossXml, annotationMetaData); | } | else | { | merged = standardJbossXml; | } | merged = Merger.merge(merged, ejbJarXml); | merged = Merger.merge(merged, jbossXml); View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097341#4097341 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097341

18 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: metadata simplication

by scott.stark＠jboss.org

4 is done, and a checkpoint of 1-3 has been committed to trunk for the ejb metadata. Its still broken as the merged behavior is not finished. I created a https://svn.jboss.org/repos/jbossas/projects/metadata/branches/stable/ branch with the pre-trunk code prior to the checkpoint. I hope to have the tests working again tomorrow. Hopefully you can do something with this in terms of getting the ejb metadata extensions you need in Carlo. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097311#4097311 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097311

18 years, 7 months

1
0
0 / 0

[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

1
0
0 / 0

[QA of JBoss Portal] - Re: JBoss Unit design (ant and maven support)

by julien＠jboss.com

I think we should move in Ant the section and scope it per . Indeed, one invocation of the command line will put all the reports and having several using the same file on the disk will likely produce overwrites. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097295#4097295 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097295

18 years, 7 months

1
0
0 / 0

[Design of JBoss Tools (dev)] - Re: xdoclet eclipse The currently displayed page contains in

by max.andersen＠jboss.com

guys - jbosside 1.6 was for eclipse 3.1; use jboss tools if you want eclipse 3.3 compability. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097286#4097286 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097286

18 years, 7 months

1
0
0 / 0

[Design of JBoss Tools (dev)] - Re: xdoclet eclipse The currently displayed page contains in

by epf

some problem Eclipse 3.3.1 (Linux) + JBossIDE 1.6.0.GA View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097281#4097281 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097281

18 years, 7 months

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[Design of JBoss Web Services] - Re: Endpoint redeployment

by richard.opalka＠jboss.com

No, it is not fixed in JBossWS 2.0.1 Richard View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097199#4097199 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097199

18 years, 7 months

1
0
0 / 0

[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

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 October 2007