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

[Design of JCA on JBoss] - Re: JBossTS/JCA Recovery work for JBoss 4.2

by weston.price＠jboss.com

Technically, in that scenaior the JCA/JMS adapter is supposed to provide the recovery mechanism via the | XAResouce[] ResourceAdapter.getXAResources(ActivationSpec[]) | method. This is still TODO on my list to implement for our JMS/JCA adapter Ideally if an AppServer supports recovery it should call into this method after a crash and query the ResourceAdapter for the XAResource --> ActivationSpec (those specs that were deployed at the time fo the crash) mappings. From the XAResource they can obviously get the outstanding recovery work. I think the miscommunication is that Tim is thinking solely from the JMS, non EE perspective...at least that's what I can gather. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006037#4006037 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006037

17 years, 5 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBossTS/JCA Recovery work for JBoss 4.2

by bill.burke＠jboss.com

Tim, if you do it your way, won't recovery not work for JBMessaging in other app servers? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4006034#4006034 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4006034

17 years, 5 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBossTS/JCA Recovery work for JBoss 4.2

by weston.price＠jboss.com

Put another way ;-) Take the case of say an RDBMS system..let's take our friend Oracle for an example. Oracle is deployed, managed, utilized in JBossAS via our JCA JDBC Resource adapter. It is the adapter that manages resource enlistment/delistment of the underlying XAResource...in sum, JCA takes care of all the messy details of driving the underlying managed connection through the XA transaction lifecycle (and pooling, security etc). So, who implements the XAResourceRecovery interface in this case? In other words, how does the underlying Oracle XAResource participate in recovery assuming that the vendor doesn't provide the necessary mechanism to do so? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005985#4005985 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005985

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: JAXBDeployer

by jason.greene＠jboss.com

"adrian(a)jboss.org" wrote : | The latest version has resolved many of these issues, although there | are still a number of features missing, e.g. dynamic wildcard handling | like JBossXB can do. | | e.g. the recent spring integration code lets you mix and match | JBoss MC and Spring xml in the same file: | | | <?xml version="1.0" encoding="UTF-8"?> | | | | <deployment xmlns="urn:jboss:bean-deployer:2.0"> | | | |  | | <bean name="oldBean" class="org.jboss.test.spring.support.OldBean"> | | <property name="testBean"><inject/></property> | | </bean> | | | |  | | <bean xmlns="urn:jboss:spring-beans:2.0" id="testBean" class="org.jboss.test.spring.support.SimpleBean"> | | <property name="mylist"> | | <list value-type="java.lang.String"> | | <value>onel</value> | | <value>twol</value> | | <value>threel</value> | | </list> | | </property> | | </bean> | | | | </deployment> | | | This is possible in JAXB, if you have the following in your root type: | // 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. and FooType has an @XmlElementRoot, and the unmarshalled value matches that declaration, then "others" would contain an instance of FooType. Unknown elements would present a DOM Element. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005984#4005984 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005984

17 years, 5 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBossTS/JCA Recovery work for JBoss 4.2

by weston.price＠jboss.com

anonymous wrote : | I disagree. | | Let's take the example of JBM for a minute. We already have a recovery mechanism in place (we use an XAResourceRecovery instance). | That's fine. In this case, because you implemented XAResourceRecovery, you are able to integrate with JBossTS directly. This is the situation you control...all fine well and good. Now, how about for XAResources you don't control? How about Oracle, DB2, WebSphereMQ, etc. What about those? How do you think these XAResource get enlisted in a transaction to begin with and who provides access to them? Guess what, it's JCA. ResourceManagers (JMS, JDBC or otherwise) are managed in an EE environment via JCA. Because JCA is a generic framework for resource integration use of the underlying XAResource is governed by this framework. There is no concept of a standalone ResourceManager in an EE environment without an associated JCA resource adapter...well, other than in the case where the person is just blatantly attempting to do something wrong, Aunt Doris or otherwise. For your fundamental disagreement to hold water, you would effectively have to remove JCA from the equation all together and assume that the Tx Manager has direct access the underlying XAResources/ResourceManagers *without* JCA intervention. This is simply not the case and will never be the case in our Application server, or any compliant EE application server for that matter. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005980#4005980 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005980

17 years, 5 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBossTS/JCA Recovery work for JBoss 4.2

by timfox

"weston.price(a)jboss.com" wrote : | This is true, but in JCA land, to support recovery one approach (ie serializable XAResource or XAResourceRecovery implementaion) has to be done. Just as you had to do this for JBM, JCA needs to support this as well to integrate with JBossTS. I disagree. Let's take the example of JBM for a minute. We already have a recovery mechanism in place (we use an XAResourceRecovery instance). Now whether the transaction was started via JCA or directly by the user is of no consequence. The JBoss TS recovery manager will just get an xaresource from our XAResourceRecovery instance and return a list of xids, some of these may come from transactions initiated by JCA and others not. It doesn't matter. In this scenario there is absolutely no need for JCA to do anything. I think the same logic applies to any resource manager for which you can write an XAResourceRecovery. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005970#4005970 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005970

17 years, 5 months

1
0
0 / 0

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

by scott.stark＠jboss.org

The common-core version has been updated to 2.0.4.Alpha3 to pickup this change. There still is one expected test failure in the kernel module I need to resolve: InstantiateXMLTestCase.testValueInstantiateFromJavabean2 | junit.framework.AssertionFailedError | at junit.framework.Assert.fail(Assert.java:47) | at junit.framework.Assert.assertTrue(Assert.java:20) | at junit.framework.Assert.assertTrue(Assert.java:27) | at org.jboss.test.kernel.config.test.InstantiateXMLTestCase.testValueInstantiateFromJavabean2(InstantiateXMLTestCase.java:57) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at junit.framework.TestCase.runTest(TestCase.java:154) | at junit.framework.TestCase.runBare(TestCase.java:127) | at junit.framework.TestResult$1.protect(TestResult.java:106) | at junit.framework.TestResult.runProtected(TestResult.java:124) | at junit.framework.TestResult.run(TestResult.java:109) | at junit.framework.TestCase.run(TestCase.java:118) | at junit.framework.TestSuite.runTest(TestSuite.java:208) | at junit.framework.TestSuite.run(TestSuite.java:203) | at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) | at junit.extensions.TestSetup$1.protect(TestSetup.java:19) | at junit.framework.TestResult.runProtected(TestResult.java:124) | at junit.extensions.TestSetup.run(TestSetup.java:23) | at junit.framework.TestSuite.runTest(TestSuite.java:208) | at junit.framework.TestSuite.run(TestSuite.java:203) | at junit.framework.TestSuite.runTest(TestSuite.java:208) | at junit.framework.TestSuite.run(TestSuite.java:203) | at junit.framework.TestSuite.runTest(TestSuite.java:208) | at junit.framework.TestSuite.run(TestSuite.java:203) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005967#4005967 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005967

17 years, 5 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBossTS/JCA Recovery work for JBoss 4.2

by timfox

"weston.price(a)jboss.com" wrote : anonymous wrote : | | Not really. JBoss TS recovery works that way for any XAResource - whether it's from JBM, a database, or whatever. | | | | Huh? The underlying XAResource either has to be serializable, or the the XAResourceRecovery interface has to be implemented to support recovery via JBossTS. | | Can we agree on that ;-) | | I was just saying, that (for JBoss TS at least) you can write an XAResourceRecovery instance that will provide an XAResource on which the tx mgr can call recover(). This shouldn't be any different for any provider. Whether the transaction was started by JCA or not (e.g. for inflow) should be of no consequence. When the recovery manager calls recover() the resource manager is supposed to return a list of in doubt xids, whether they were started by JCA, some user application, or your great Aunt Doris. I still don't see what any of this has got to do with JCA. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005966#4005966 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005966

17 years, 5 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBossTS/JCA Recovery work for JBoss 4.2

by weston.price＠jboss.com

I think we may be crossing wires ;-) anonymous wrote : | Also, not everyone that wants recovery will be using JCA. | This is true, but in JCA land, to support recovery one approach (ie serializable XAResource or XAResourceRecovery implementaion) has to be done. Just as you had to do this for JBM, JCA needs to support this as well to integrate with JBossTS. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005962#4005962 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005962

17 years, 5 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBossTS/JCA Recovery work for JBoss 4.2

by weston.price＠jboss.com

anonymous wrote : | Not really. JBoss TS recovery works that way for any XAResource - whether it's from JBM, a database, or whatever. | Huh? The underlying XAResource either has to be serializable, or the the XAResourceRecovery interface has to be implemented to support recovery via JBossTS. Can we agree on that ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005961#4005961 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005961

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