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

[Design of JBoss internal QA (Test Suite)] - prevent tests get overwritten

by akostadinov

We've had recently a problem where some tests was run twice or more from different targets without being renamed with the jboss formatter. This leaded to the possibility of undetected failures if a test fails and on the next run passes. See this link for a reference: http://jboss.com/index.html?module=bb&op=viewtopic&t=101760 It was decided to rename all tests but tests-standard-unit ones. I'm thinking about how to prevent this in the future - when new test targets are added and the developers forget to use the custom formatter. I can think of two options: 1. implement in the JBoss AS test suite itself 2. implement into our continuous integration system First one is hard. I see it like counting test cases files specified by the patterns used in the build file and comparing to the number of generated XML report files or number reported in the final report. I think there will be plenty of problems to count the files. First we'll need a resourcecont ant task or a similar one and also some of the patterns might be invisible to where the task is called. ResourceCount target is available in ant 1.7 and we are using 1.6.5. That's why I think it will be easier and enough for our needs to have the check implemented in our continuous builds. It should be one line shell script. If overwriting occurs developers will be notified. Any other ideas/thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040577#4040577 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040577

18 years, 11 months

1
0
0 / 0

[Design of JCA on JBoss] - JBAS-2854 Fire Local Transaction Events From JMSResourceAdap

by weston.price＠jboss.com

This will require a fair amount of work because of the way we allocate Sessions. IMO, we are doing this incorrectly: Because we defer allocating a resource with the CM until *after* the connection has been created we don't enlist in a Txn until the client calls createSession(true | false, ackMode) When we create the underlying ManagedConnection, we also allocate the physical Sesssion in the setup() method. Because of this, by the time we enlist the LocalXAResource, the Session has alredy been created. If the user calls: createSession(false, Session.AutoAcknowledge) we essentially ignore all transaction lifecycle events because we are taking the transacted flag from the createSession method as a boolean to control local transaction behavior (see JmsLocalTransaction). This flag should really be ignored as it has no bearing in CMT because we are managing this for the client. One way to fix this would be 1) Don't allocate the physical Session in the setup() method 2) When a LocalTransaction is started, in the | getSession() | method create a transacted Session and set a flag to say 'in transaction'. Note, we will also have to account for the no-tx-connection-factory deployment to actually take the flags from the CRI into account in the case the client wants to control the transaction. A different getSession() method for the JmsLocalTransaction will probably do the trick. 3) Set the state variable on transaction completion. The other approach would be to rework the JmsConnectionFactory to allocate a real connection handle for the Connection. On enlistment we create a transacted Session which ultimately gets returned to the user on the | createSession(true | false, ackMode) | call. As the JIRA task mentions, this is not a trivial change but IMO we pretty much have to do this as I don't think the using the transact flag as a way to control transaction behavior in CMT is correct. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040575#4040575 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040575

18 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB

by timfox

And XATest (at least) is now passing 100% View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040572#4040572 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040572

18 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB

by timfox

I have added tests in XATest to test our new expected behaviour. Some of these are reconsituted from the old graveyard tests View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040571#4040571 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040571

18 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB

by timfox

Pls Ignore my previous comment - I don't think it is correct. So what we end up with is the following behaviour: An XASession that is not enlisted in a global tx behaves: a) As a local transacted session for any messages *consumed*, this is so we can consume messages in an MDB in the context of a global tx (This is the old chestnut where the container can't enlist the session in the global tx until after the message has been consumed from the provider using ASF). b) As a non transacted session for any messages *sent*. So as you can see it will behave differently for any messages sent as opposed to consumed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040545#4040545 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040545

18 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB

by timfox

I suspect your fix will cause the following use case to fail: Send message to another queue from inside the onMessage method of an MDB. Immediately after sending throw a RuntimeException. Make sure onMessage executes transactionally. This should cause the tx to rollback and the message shouldn't be sent. What you'll probably find with your latest change is that the message gets sent even though the tx rolls back. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040534#4040534 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040534

18 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB

by timfox

The problem with 410 is it is inconsistent with transactional delivery in an MDB. If an XASession not enlisted in a transaction acts as non transacted, then you end up with transacted delivery of messages in an MDB failing. This is because the message is delivered and sometime *after* the XASession is enlisted in the tx. This is why we fall back to being transacted, otherwise messages we get immediately acked from transacted MDBs. Your "fix" reverses this behaviour for sends but not receives. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040512#4040512 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040512

18 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: aop-mc-int tests with maven

by kabir.khan＠jboss.com

OK, I found the magic -X option I am using | <plugin> | <groupId>org.apache.maven.plugins</groupId> | <artifactId>maven-surefire-plugin</artifactId> | <executions> | <execution> | <id>weave</id> | <phase>test</phase> | <goals> | <goal>test</goal> | </goals> | <configuration> | <skip>false</skip> | <includes> | <include>org/jboss/test/**/*TestCase.java</include> | </includes> | <argLine>-Djava.system.class.loader=org.jboss.aop.standalone.SystemClassLoader</argLine> | <forkMode>always</forkMode> | <systemProperties> | <property> | <name>jboss.aop.exclude</name> | <value>org.jboss.,org.apache.</value> | </property> | <property> | <name>jboss.aop.include</name> | <value>org.jboss.test.</value> | </property> | <property> | <name>jboss-junit-configuration</name> | <value>weave</value> | </property> | <property> | <name>build.testlog</name> | <value>target/log</value> | </property> | <property> | <name>jboss.aop.verbose</name> | <value>true</value> | </property> | </systemProperties> |  | </configuration> | </execution> | | $ mvn -X | + Error stacktraces are turned on. | Maven version: 2.0.5 | .... | [DEBUG] Test Classpath : | [DEBUG] C:\cygwin\home\Kabir\sourcecontrol\microcontainer-mvn\aop-mc-int\target\classes | [DEBUG] C:\cygwin\home\Kabir\sourcecontrol\microcontainer-mvn\aop-mc-int\target\test-classes | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\jboss\jboss-vfs\2.0.4.snapshot\jboss-vfs-2.0.4.snapshot.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\jboss\jboss-common-core\2.0.4.GA\jboss-common-core-2.0.4.GA.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\jboss\jboss-common-logging-spi\2.0.4.GA\jboss-common-logging-spi-2.0.4.GA.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\org\apache\ant\ant\1.7.0\ant-1.7.0.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\javassist\javassist\3.5-SNAPSHOT\javassist-3.5-SNAPSHOT.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\junit\junit\3.8.1\junit-3.8.1.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\apache-xerces\xercesImpl\2.7.1\xercesImpl-2.7.1.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\ant\ant\1.6.5\ant-1.6.5.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\jboss\jboss-kernel\2.0.0-SNAPSHOT\jboss-kernel-2.0.0-SNAPSHOT.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\jboss\jboss-dependency\2.0.0-SNAPSHOT\jboss-dependency-2.0.0-SNAPSHOT.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\sun-jaf\activation\1.0.2\activation-1.0.2.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\wutka-dtdparser\dtdparser121\1.2.1\dtdparser121-1.2.1.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\jboss\jboss-logging-log4j\2.0.2.GA\jboss-logging-log4j-2.0.2.GA.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\org\apache\ant\ant-junit\1.7.0\ant-junit-1.7.0.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\qdox\qdox\1.6\qdox-1.6.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\jboss\jboss-kernel\2.0.0-SNAPSHOT\jboss-kernel-2.0.0-SNAPSHOT-tests.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\jboss\jboss-logging-spi\2.0.2.GA\jboss-logging-spi-2.0.2.GA.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\trove\trove\2.1.1\trove-2.1.1.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\jboss\jbossxb\2.0.0.CR3\jbossxb-2.0.0.CR3.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\apache-log4j\log4j\1.2.8\log4j-1.2.8.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\apache-xerces\xml-apis\2.7.1\xml-apis-2.7.1.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\jboss\jboss-test\1.0.3.GA\jboss-test-1.0.3.GA.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\oswego-concurrent\concurrent\1.3.4\concurrent-1.3.4.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\jboss\profiler\jvmti\jboss-profiler-jvmti\1.0.0.CR5\jboss-profiler-jvmti-1.0.0.CR5.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\apache-slide\webdavlib\2.0\webdavlib-2.0.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\apache-httpclient\commons-httpclient\2.0.2\commons-httpclient-2.0.2.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\jboss\jboss-aop\2.0.0-SNAPSHOT\jboss-aop-2.0.0-SNAPSHOT.jar | [DEBUG] C:\Java\jdk\jdk1.5.0_10\jre\..\lib\tools.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\log4j\log4j\1.2.14\log4j-1.2.14.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\jboss\jboss-container\2.0.0-SNAPSHOT\jboss-container-2.0.0-SNAPSHOT.jar | [DEBUG] C:\Documents and Settings\Kabir\.m2\repository\org\apache\ant\ant-launcher\1.7.0\ant-launcher-1.7.0.jar | [DEBUG] Setting system property [jboss-junit-configuration]=[weave] | [DEBUG] Setting system property [build.testlog]=[target/log] | [DEBUG] Setting system property [jboss.aop.verbose]=[true] | [DEBUG] Setting system property [localRepository]=[C:\Documents and Settings\Kabir\.m2\repository] | [DEBUG] Setting system property [jboss.aop.include]=[org.jboss.test.] | [DEBUG] Setting system property [jboss.aop.exclude]=[org.jboss.,org.apache.] | [DEBUG] Setting system property [basedir]=[C:\cygwin\home\Kabir\sourcecontrol\microcontainer-mvn\aop-mc-int] | [DEBUG] Using JVM: C:\Java\jdk\jdk1.5.0_10\jre\bin\java | [INFO] Surefire report directory: C:\cygwin\home\Kabir\sourcecontrol\microcontainer-mvn\aop-mc-int\target\surefire-reports | Forking command line: C:\Java\jdk\jdk1.5.0_10\jre\bin\java -Djava.system.class.loader=org.jboss.aop.standalone.SystemClassLoader -classpath "C:\Documents and Settings\Kabir\.m2\repository\org\codehaus\plexus\plexus-archiver\1.0-alpha-7\plexus-archiver-1.0-alpha-7.jar;C:\Documents and Settings\Kabir\.m2\repository\junit\junit\3.8.1\junit-3.8.1.jar;C:\Documents and Settings\Kabir\.m2\repository\org\codehaus\plexus\plexus-container-default\1.0-alpha-8\plexus-container-default-1.0-alpha-8.jar;C:\Documents and Settings\Kabir\.m2\repository\org\apache\maven\surefire\surefire-api\2.3\surefire-api-2.3.jar;C:\Documents and Settings\Kabir\.m2\repository\classworlds\classworlds\1.1-alpha-2\classworlds-1.1-alpha-2.jar;C:\Documents and Settings\Kabir\.m2\repository\org\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar;C:\Documents and Settings\Kabir\.m2\repository\commons-lang\commons-lang\2.1\commons-lang-2.1.jar;C:\Documents and Settings\Kabir\.m2\repository\org\apache\maven\surefire\surefire-booter\2.3\surefire-booter-2.3.jar" org.apache.maven.surefire.booter.SurefireBooter C:\DOCUME~1\Kabir\LOCALS~1\Temp\surefire3057tmp C:\DOCUME~1\Kabir\LOCALS~1\Temp\surefire3058tmp | Error occurred during initialization of VM | java.lang.Error: java.lang.ClassNotFoundException: org.jboss.aop.standalone.SystemClassLoader | Digging into this a bit, one of the tmp files contains the test classpath. So it seems that the surefire plugin is meant to instantiate the test with the reall classpath, and the-Djava.system.class.loader=org.jboss.aop.standalone.SystemClassLoader system property is being used "too early" (when creating the SureFireBooter rather than when instantiating the test) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040508#4040508 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040508

18 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting is throwing unrecognized listener ID: blah blah

by timfox

If these are "to be expected" I guess they should be logged as debug rather than warn so users can filter them out with their log4j settings. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040502#4040502 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040502

18 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Remoting is throwing unrecognized listener ID: blah blah

by timfox

Remoting is frequently throwing the following warnings: | 14:26:40,328 WARN [BisocketServerInvoker] unrecognized listener ID: a00h-citaru-f0we4a0g-1-f0we6jfw | -1s | 14:28:39,609 WARN [BisocketServerInvoker] unrecognized listener ID: a00h-citaru-f0we4a0g-1-f0we940c | -1y | 14:30:39,046 WARN [BisocketServerInvoker] unrecognized listener ID: a00h-citaru-f0we4a0g-1-f0webol9 | I remember Ron explaining there was some reason for this some time ago. Ron - can you advise? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040500#4040500 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040500

18 years, 11 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 April 2007