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

[Design of JCA on JBoss] - Re: XAExpectionUnitTestCase Failures/JBossTS/JBoss 4.2

by weston.price＠jboss.com

anonymous wrote : | Now the explanation is over, what is the exact problem? | I explained this already. anonymous wrote : | The tests require the failure to occur in the matchManagedConnections method. When the test originally runs, the pool is empty. As a result, a connection is successfully created and enlisted/delisted in the tranasction and returned to the pool. | | The second attempt to acquire the connection fails in the match and the connection is destroyed. Howerver, JBossTS rightfully 'remembers' this guy and when JBossTS attempts to finish the txn protocol the connection has already been destroyed causing the failure. | | Basically, JBossTS is attempting to complete the XA protocol on a resource that has already been destroyed which is causing the failure presented in the JIRA issue. The tests itself, as you point out, is designed to make sure that the correct behavior occurs when a match in the managed connection fails. However, as is often the case, it has turned up this other issue. When you say anonymous wrote : | There has been some debate in the past on whether we should disable | interleaving by default since most XAResources don't support it. | This includes all xa datasources that I've come across which is why | their examples disable it. | This is basically what I am proposing since the default setting to allow for interleaving seems to cause problems with JBossTS and XAResources. My plan was to enable <track-connection-by-tx> by default for XA resources, and force it to be explicitly enabled for resources where this makes sense (ie JMS resources). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006848#4006848 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006848

17 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Failing tests

by adrian＠jboss.org

I don't like that this javabean2 code is using the MC metadata. 1) There is no way the javabean xml can support all this metadata 2) I want to move the javabean xml to the container project since it should only really be relying on the BeanInfo abstraction. The reason I have not moved it before is because it has a dependency on the KernelConfig class, so it needs a bit of refactoring to make this possible. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006842#4006842 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006842

17 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Failing tests

by adrian＠jboss.org

I've fixed the javabean2 test. The problem was caused because there was no constructor element on which the construction callback was invoked. I've added some fixup in the endElement of the javabean to cope with this case. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006834#4006834 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006834

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: JAXBDeployer

by adrian＠jboss.org

"jason.greene(a)jboss.com" wrote : Or different schemas need to be associated with the same object model. | -Jason Yes, this is also broken as well. :-) The namspace is associated with the package level annotation rather the root element. This is a basic reusability issue. e.g. It should be: | public class AbstractEJBModel | { | @XMLElement(name="enterpriseBeans") | public void setEJBs(List<EJB> ejbs); | } | | @XmlRootElement(namespace="EJB21Namespace") | public class Ejb21Model extends AbstractEJBModel | { | } | | @XmlRootElement(namespace="EJB30Namespace") | public class Ejb30Model extends AbstractEJBModel | { | } | The ejbs property should be mapped to EJB21Namespace/EJB21Model or EJB30Namespace/EJB30Model depending on the model chosen (the namespace in the xml). I have this in my prototype of bindings for JBossXB annotations - the USE_PARENT_NAMESPACE. | /** | * SchemaProperty. | * | * @author <a href="adrian(a)jboss.com">Adrian Brock</a> | * @version $Revision: 1.1 $ | */ | @Documented | @Target(ElementType.METHOD) | @Retention(RetentionPolicy.RUNTIME) | public @interface SchemaProperty | { | /** Whether it is mandatory */ | boolean mandatory() default true; | | /** The namespace, default empty */ | String namespace() default SchemaConstants.USE_PARENT_NAMESPACE; | | /** The local name, default use the property name */ | String name() default SchemaConstants.USE_PROPERTY_NAME; | | /** The implementation class */ | Class<?> impl() default Object.class; | | /** TODO remove this when groups work properly */ | boolean noInterceptor() default false; | | /** TODO combine with mandatory */ | boolean ignore() default false; | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006802#4006802 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006802

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: JAXBDeployer

by adrian＠jboss.org

anonymous wrote : | This is possible in JAXB, if you have the following in your root type: | Code: | | // Array of Element or JAXB elements. | @XmlAnyElement(lax="true") | public Object[] others; | | JAXB dynamically resolves type information off of annotations. So before unmarshalling, if you pass the JAXBContext a FooType.class. | That isn't what the example does. JBossXB uses the xml namespace to determine the class to unmarshal as the wildcard. You don't have to tell it a fixed number of classes/packages upfront on the JAXBContext. JAXB is simply not extensible to abitrary wildcards. | <xsd:choice> | <xsd:element name="string" type="stringType" minOccurs="0"/> | <xsd:element name="blah" type="blahType" minOccurs="0"/> | <xsd:any namespace="##other" processContents="strict" minOccurs="0"/> | </xsd:choice> | | @RootElement | public class MyClass | { |  | @XmlElement(name="string" type=StringSomething.class) | @XmlElement(name="blah" type=BlahSomething.class) | |  | @XmlAnyElement(I'll accept anything that implements the interface!) | public void setSomethings(List<Something> somethings) {} | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006792#4006792 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006792

17 years, 5 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: XAExpectionUnitTestCase Failures/JBossTS/JBoss 4.2

by adrian＠jboss.org

Now the explanation is over, what is the exact problem? The whole point of the XAException test is to make sure the correct exceptions are being reported, e.g. RuntimeExceptions are not getting leaked where XAExceptions are expected. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006782#4006782 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006782

17 years, 5 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: XAExpectionUnitTestCase Failures/JBossTS/JBoss 4.2

by adrian＠jboss.org

No. <track-connection-by-tx/> is there to disable transaction interleaving. It is only relevant for XA, it must be true for local. There has been some debate in the past on whether we should disable interleaving by default since most XAResources don't support it. This includes all xa datasources that I've come across which is why their examples disable it. e.g. possible change 1) Disable interleaving by default 2) Ignore the track-connection-by-tx 3) Add a new flag <interleaving/> JBossMQ supports transaction interleaving, meaning the pool does not have to be as big as for other JMS impls! See below. Explanation of transaction interleaving: The purpose of interleaving is to improve the performance of the pool. If the XAResource supports interleaving then multiple transactions can go through it at once (although only one transaction can be associated at once). e.g. Using a single real connection/XAResource Tx1: Ask for a connection and enlist the xa resource XAResource.start(xid1, TMNOFLAGS) Tx1: Return the connection to the pool XAResource.end(xid1, TMSUSPEND) Tx2: Ask for a connection and enlist the xa resource (it is the same) - XAResource.start(xid2, TMNOFLAGS) (Point A) Tx2: Return the connection to the pool XAResource.end(xid2, TMSUSPEND) Tx1: Ask for a connection and enlist the xa resource - we resume the old one XAResource.start(xid1, TMRESUME) Additionally, the XAResource 2PC commtt protocol can be invoked concurrently if the XAResource supports interleaving. i.e. in the above at (Point A) the Tx1/xid1 could be committed even though the XAResource is currently associated with xid2 As you can see. Support for interleaving greatly reduces the number of connections required in the pool. If you have transaction stickiness (track-connection-by-tx), you need one connection per transaction, even if the transaction has already tried to return the connection to the pool, but it hasn't committed it yet. Example of where interleaving is useful: 1) get jms connection and receive a message 2) return jms connection for somebody else to use 3) do long running process (might take minutes) 4) commit With track-connection-by-tx, the connection won't become available until after the long running process is complete, with interleaving somebody else can use the connection during the long running process. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006779#4006779 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006779

17 years, 5 months

1
0
0 / 0

[Design of JBoss Portal] - Re: 2.4.1 - source without thirdparty

by wojsal1

"thomas.heute(a)jboss.com" wrote : Just start the building, it will create the directory and get all the stuff in it from the Web. Thanks, WOJSAL View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006722#4006722 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006722

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Guidance for JBPM-725? Applies to 3.2?

by tom.baeyens＠jboss.com

thanks for bringing that up. it's a good poit and it would be great if you could help us with that. did you already sign a contributors agreement ? if not, see the jbpm wiki oncontributions and check Cotributors Agreement in the left menu of labs.jboss.org (you have to be logged in to sign an agreement) once that is done, you can get cvs commit access to apply ths change. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006721#4006721 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006721

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: what are the new features in JBPM 3.2?

by tom.baeyens＠jboss.com

* email integration is explained in a new chapter in the userguide in the download * enterprise beans an .ear packaging. these are not yet properly documented... working on it. * new project structure (both source tree and download) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006720#4006720 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006720

17 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2007