View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-cache-testsuite?log=log20060126005415
TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-JBossCache.xml:96: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-portal-2.2-testsuite?log=log20060126005306
BUILD FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-portal.xml:57: Exit code: 1 See compile.log in Build Artifacts for details.Date of build: 0
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-portal-2.0-testsuite?log=log20060126005015
TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-portal.xml:67: The following error occurred while executing this line: /services/cruisecontrol/work/s
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-3.2-testsuite?log=log20060125183155
TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:191: The following error occurred while executing this line: /services/cruisecontrol/work/scripts
I guess that could workits extremely undesireable, but technically
feasible. It would be rather unpleasent to look up ever independent
attribute as a seperate JNDI lookup and forcibly inject it. For the
moment dealing with the drawbacks of XMBeans and the integration
issues is less unpl
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/ejb3-4.0-testsuite?log=log20060125133530
BUILD FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-ejb3-4.0-testsuite.xml:83: Exit code: 1 See tests.log in Build Artifacts for details.Date of build: 01/25
[EMAIL PROTECTED] wrote:
Having the dependency information will make things work a lot more
smoothly for us, we will still not be able to use service beans
without at least deploytime dependency injection. We will have to
continue to kludge around these holes in the near future but one day
Having the dependency information will make things work a lot more
smoothly for us, we will still not be able to use service beans
without at least deploytime dependency injection. We will have to
continue to kludge around these holes in the near future but one day
5.0 will fix all of our prob
[EMAIL PROTECTED] wrote:
Bill Burke wrote:
[EMAIL PROTECTED] wrote:
1. @Tx tags can only be used on classes but not interfaces (in the case
of MBeans)
a. reason this would be handled by the MBean deployer adding a
transaction interceptor rather than AOP proper.
b. there is no fram
Bill Burke wrote:
[EMAIL PROTECTED] wrote:
1. @Tx tags can only be used on classes but not interfaces (in the case
of MBeans)
a. reason this would be handled by the MBean deployer adding a
transaction interceptor rather than AOP proper.
b. there is no framework within jboss for XMBean
On Wed, 25 Jan 2006 18:54:08 +0100, Kabir Khan <[EMAIL PROTECTED]>
wrote:
I'll try to take a look tomorrow, and include the missing files in the
hibernate-client.jar
But should this file not be created by hibernate rather than as part of
the
ejb 3 build?
sure, patches to our build is ver
I'll try to take a look tomorrow, and include the missing files in the
hibernate-client.jar
But should this file not be created by hibernate rather than as part of the
ejb 3 build?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 25 January 2006 18:47
To: [EMAIL
[EMAIL PROTECTED] wrote:
1. @Tx tags can only be used on classes but not interfaces (in the case
of MBeans)
a. reason this would be handled by the MBean deployer adding a
transaction interceptor rather than AOP proper.
b. there is no framework within jboss for XMBeans using attribute
ta
1. @Tx tags can only be used on classes but not interfaces (in the case
of MBeans)
a. reason this would be handled by the MBean deployer adding a
transaction interceptor rather than AOP proper.
b. there is no framework within jboss for XMBeans using attribute
tags to specify interception
> It’s
a bug, but I only see the MILLISECOND value being used. I don’t see that
javax.management.j2ee.statistics.TimeStatistic
has these constants in the 4.0 branch, so where are you seeing that?
Actually, it was removed from 4.x, should be ok
now.
From:
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-remoting-testsuite-1.5?log=log20060125001807
BUILD TIMED OUTAnt Error Message: build timeoutDate of build: 01/25/2006 00:18:07Time to build: Last changed: 12/31/2005 20:37:24Last log entry: JBREM-272:Added tests for (clientP
16 matches
Mail list logo
