August 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBoss internal QA (Test Suite)] - Integration of JBoss Messaging tests into testsuite

by rachmatowicz＠jboss.com

Dear All The JBAS testsuite presently executes integration tests for the JMS provider JBossMQ, but not for the new JMS provider Messaging. This topic concerns changes to the testsuite to incorporate integration tests for Messaging. Adding these tests to the testsuite involves the following steps: 1. create a new directory $JBAS/testsuite/src/main/org/jboss/test/jbossmessaging to hold the new integration tests and define an appropriate patternset 2. import the Messaging artifacts (e.g. jboss-messaging.jar) from repository.jboss.com into $JBAS/thirdparty (Messaging is no longer built within the JBAS build) 3. modify the tests.classpath to incorporate the new Messaging artifacts so that the new test classes are correctly compiled by the target compile-classes-only and make changes to $JBAS/testsuite/src/imports/test-jars.xml to create a suitable jar file jbossmessagingtests.jar 4. create a new messaging configuration 6. start up JBAS with the new configuration, call run-junit with the patternset to execute the tests and then shutdown the JBAS server Steps 2 & 3 involve testsuite independently importing Messaging artifacts from respoitory.jboss.com into $JBAS/thirdparty. A mechanisms for doing this was incorporated into the testsuite/build.xml file in svn.repository.com/repos/jbossas/branches/Branch_4_0, making use of a new target createthirdparty in testsuite/build.xml and a new file build-thirdparty.xml. The target checks if the thirdparty directory is up to date, and calls build-thirdparty.xml if it is not. It also generates a file thirdparty/testsuite-libraries.ent containing path definitions for the new thirdparty entries. This mechanism allows testsuite to independently make use of thirdparty libraries from the repository. However, if you need to add those libraries to the key testsuite classpaths, there is a problem, as the key classpaths (e.g. tests.classpath) get constructed before any targets are executed, including createthirdparty. What we propose is to force the classpaths to be built after createthirdparty has had a chance to execute by defining a target createclasspaths in which all the key testsuite claspath targets are built and which gets executed after createthirdparty. Dependencies will be added to ensure that the overall desired testsuite behaviour does not change. This will allow testsuite-libraries.ent to be included and used in a more flexible manner. This is one proposed change. Step 4 involves creating a new messaging configuration. An existing ant script for doing this, release-admin.xml, is already present in the Messaging build. Rather than duplicate this code in the testsuite build, we propose to import release-admin.xml just as any other Messaging artifact, bring it into the $JBAS/testsuite/src/resources directory, and execute it to create the nmessaging configuration. This is a second proposed change. We would like to incorporate these changes as follows: 1. Make the changes to allow testsuite to independently import and use thirdparty libraries. Commit the changes and monitor builds for a few days. 2. make the changes to allow release-admin.xml to be imported and executed. Commit the changes and monitor for a few days. 3. Continue adding tests cases for Messaging to $JBAS/testsuite/src/org/test/jboss/test/jbossmessaging If there are no objections, we aim to incorporate the first set of changes late tomorrow (Friday, 1 September). Richard PS Please excuse the brevity - my first version of this posting, much more detailed and taking over an hour to write, was sent into the ether by the Preview button. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968806#3968806 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968806

18 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Graphic Installer for Messaging

by alex.pinkin＠jboss.com

Adding "Standalone JBoss Messaging" profile to the installer is not such a big deal. However, I'm currently maxed out with other work :( So we have to either postpone this or find somebody else to implement it. If we go with the 2nd approach, I could help out by explaining what needs to be done. Izpack installer knowledge will be required to get this done. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968803#3968803 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968803

18 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi

by ovidiu.feodorov＠jboss.com

If it did, we'd fall back to the exact behavior we actually want for Messaging, and it already happens in JBossMQ. Remember that the JCA layer has nothing to do with the decision to send the message through, which is taken by SpyXAResourceManager in JBossMQ's case, and could be taken by MessagingResourceManager in ours. The JCA layer just (correctly) does not enslist the XAResource with an inexistent JTA transaction. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968793#3968793 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968793

18 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi

by timfox

Another solution is for the JCA layer to be clever enough to realise there is no transaction and execute the jms operations using a standard Session rather than an XASession, then we avoid these problems. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968791#3968791 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968791

18 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi

by ovidiu.feodorov＠jboss.com

Right, but we control the XASession/XAResource implementation, so we can case for it. If a session has been enlisted once, then it will be reenlisted again with the next transaction, unless it closes. This is the common behavior. This is not the case we're talking again, which is when the session did not see a transaction ever. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968786#3968786 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968786

18 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Using preinstantiated collections, maps (JBMICROCONT-35)

by alesj

"alesj" wrote : anonymous wrote : | | Reopened since this isn't working. | | | | The only reason the test passed is because the default constructor | | was changed to set preinstantiated to true. | | | | If it uses the default constructor then it is not using preinstantiated object. | | Will look into this one. | The problem is that preinstantiated lookup needs to pass MetaDataVisitor.initialVisit() for meta data node stack lookup and controller set up. And test case simply uses plain meta data - no controller. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968784#3968784 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968784

18 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi

by timfox

Actually this gets more complex. There are some situations where sending messages directly if the transaction is not enlisted in a global tx will give incorrect behaviour. See this comment from MesagingXAResource: | //If I commit/rollback the tx, then there is a short period of time between the AS (or whoever) | //calling commit on the tx and calling start to enrolling the session in a new tx. | //If the session has any listeners then in that period, messages can be received asychronously | //but we want them to be received in the context of a tx, so we convert. | So we have to be very careful here. AFAICT the only time when it would be valid to directly send messages using an XASession is if the session had never been enlisted in a global tx. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968783#3968783 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968783

18 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi

by ovidiu.feodorov＠jboss.com

timfox wrote : | If we're really that bothered the place to get an answer (maybe) from the spec authors is the jms-interest mailing list at Sun. Good idea. I'll do that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968781#3968781 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968781

18 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi

by ovidiu.feodorov＠jboss.com

http://jira.jboss.org/jira/browse/JBMESSAGING-539 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968780#3968780 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968780

18 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-410 - Use of JmsXA in non transactional envi

by timfox

Regarding the reference implementation, based on the amount of effort Sun put into the specification in the xa area, personally I doubt whether they have specifically considered this edge case, so any results obtained from there may just be an accident of implementation. I think we should be driven by what our customers expect the behaviour to be , i.e. we should make it work like JBoss MQ. I am interested in what the RI says, but only as a curiousity. If we're really that bothered the place to get an answer (maybe) from the spec authors is the jms-interest mailing list at Sun. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968779#3968779 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968779

18 years, 3 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 August 2006