September 2007 - jboss-dev-forums

[Design the new POJO MicroContainer] - Re: mc release prep

by adrian＠jboss.org

I think you're confusing? transaction-api == javax.transaction with transaction-spi == org.jboss.tm transaction-spi obviously depends on transaction-api but it also defines an extension to jca's XATerminator. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081739#4081739 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081739

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: mc release prep

by scott.stark＠jboss.org

Nevermind. I was confusing jboss-transaction-api with jboss-transaction-spi. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081738#4081738 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081738

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: mc release prep

by scott.stark＠jboss.org

Ok, then non-snapshot releases of javaee, and integration are needed to do the mc release. I have asked Kabir to do an aop release as well. There seems to be a circular reference between javaee and integration as javaee depends on integration/jboss-transaction-api and integration/jboss-transaction-api depends on javaee/jboss-jca. javaee should just be the ee interfaces should it not? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081731#4081731 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081731

17 years, 1 month

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Removal of JBossTM from JBossAS trunk

by mark.little＠jboss.com

"adrian(a)jboss.org" wrote : | For the CORBA/OTS integration, we probably need a seperate | jboss-corba-spi in the integration project? Or should this go in the | jboss-transaction-spi? | How about jboss-corba-orb-spi and jboss-corba-ots-spi? I doubt we'll be adding any further implementations based on OMG technologies in the near future, but keeping the projects hierarchical should make it easier to manage in the future. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081730#4081730 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081730

17 years, 1 month

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Removal of JBossTM from JBossAS trunk

by adrian＠jboss.org

The TM integration interfaces have been moved to the jboss integration project. http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/integration/t... The outstanding work is on the JIRA issue at the top of this topic. There's the OTS issue, the XIDFactory usage and cleaning up the testsuite. For the CORBA/OTS integration, we probably need a seperate jboss-corba-spi in the integration project? Or should this go in the jboss-transaction-spi? Ideally, there should be a jboss-corba-spi anyway for the JacORB integration to implement. Then somebody else can choose to integrate a different ORB for JBoss by implementing that spi. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081723#4081723 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081723

17 years, 1 month

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Removal of JBossTM from JBossAS trunk

by jhalliday

> I am not sure I fully understand the implications of removing JBoss TM (JTA). Have all dependencies from that TM been eliminated? We want to retain some of its interfaces (e.g., the TPC importer/exporter interfaces), right? Adrian (? at least I think it was him) has a project underway to separate out the interfaces that pluggable components should use to interface to the app server. I think it already has the JBoss TM interfaces. If not they should move into there before disappearing from the AS. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081720#4081720 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081720

17 years, 1 month

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Removal of JBossTM from JBossAS trunk

by reverbel

Ivan already copied the JBoss TM/OTS/DTM code to a Sourceforge project. I can look into removing OTS/DTM from trunk. I am not sure I fully understand the implications of removing JBoss TM (JTA). Have all dependencies from that TM been eliminated? We want to retain some of its interfaces (e.g., the TPC importer/exporter interfaces), right? Currently there is a hardcoded dependency from the IIOP module on the OTS code. The IIOP servant directly accesses an OTS class in order to obtain the transaction context, which is then stuffs into the Invocation object. That dependency on a class needs to be replaced by a dependency on an interface, which any deployable OTS module may implement. Besides allowing the current OTS code to continue working even after its removal from trunk, this should also be useful to JBossTS, for "transaction bridging" across OTS and XA (JTA). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081717#4081717 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081717

17 years, 1 month

1
0
0 / 0

[Design of JBoss Transaction Services] - Corba TxServerInterceptor in JBoss Head

by adrian＠jboss.org

This was commented out in the iiop-service.xml in jboss-head with a message about using JBoss JTS. While that is all well and good, tx propogation should fail (RemoteException) if JBoss JTS is not being used (the default). I've re-instated this interceptor which provides that functionality by injecting a dummy "ForeignTransaction" into the invocation which will trigger failures for Required, Supported and Mandatory demarcation in EJBs. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081697#4081697 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081697

17 years, 1 month

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Scoped AOP rewrite probably delayed

by kabir.khan＠jboss.com

OK, good. This task is top of my list, so I will keep at it - so if we do the classloader switch after beta3, we should be good to go View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081682#4081682 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081682

17 years, 1 month

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Scoped AOP rewrite probably delayed

by adrian＠jboss.org

It's only ESSENTIAL if we switch over to the new classloader by default. We're probably too close to the beta3 release to do that now, i.e. go through all the re-testing to iron out any problems/invalid assumptions made by code that it reveals. If it isn't done by beta3 then we want to do as soon as possible after that release. I do want to get the new classloader in soon so we can properly modularize the bootstrap, i.e. optional AOP/JMX/etc rather than one big bootstrap-beans.xml View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4081674#4081674 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4081674

17 years, 1 month

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