[JBoss-dev] jboss-3.2-compatibility-matrix Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-3.2-compatibility-matrix?log=log20060202001416 TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:235: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:26: Build Successful - Tests completed with errors or failures.Date of build: 02/02/2006 00:14:16Time to build: 17 minutes 12 secondsLast changed: 02/01/2006 23:40:20Last log entry: JBAS-2758: add usage of org.jboss.j2ee.Serialization flag to compatibility matrix Unit Tests: (1527) Total Errors and Failures: (46)org.jboss.test.jbossmq.test.Jms11UnitTest::testQueueMessageOrderorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_6)org.jboss.test.jbossmq.test.Jms11UnitTest::testTemporaryQueueDeleteorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_6)org.jboss.test.jbossmq.test.Jms11UnitTest::testTemporaryTopicDeleteorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_6)org.jboss.test.jbossmq.test.Jms11UnitTest::testInvalidDestinationQueueSendorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_6)org.jboss.test.jbossmq.test.Jms11UnitTest::testInvalidDestinationQueueBrowseorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_6)org.jboss.test.jbossmq.test.Jms11UnitTest::testInvalidDestinationTopicPublishorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_6)org.jboss.test.jbossmq.test.Jms11UnitTest::testErrorsTopicSubscribeorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_6)org.jboss.test.jbossmq.test.Jms11UnitTest::testCreateQueueorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_6)org.jboss.test.jbossmq.test.Jms11UnitTest::testMessageListenerorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_6)org.jboss.test.jbossmq.test.Jms11UnitTest::testApplicationServerStufforg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_6)org.jboss.test.jbossmq.test.Jms11UnitTest::testTopicsorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_6)org.jboss.test.jbossmq.test.Jms11UnitTest::testTopicNoLocalorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_6)org.jboss.test.jbossmq.test.Jms11UnitTest::testTopicNoLocalBounceorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_6)org.jboss.test.jbossmq.test.Jms11UnitTest::testTopicSelectorChangeorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_6)org.jboss.test.jbossmq.test.Jms11UnitTest::testTopicSelectorNullOrEmptyorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_6)org.jboss.test.jbossmq.test.Jms11UnitTest::testSendReceiveOutdatedorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_6)org.jboss.test.jbossmq.test.Jms11UnitTest::testSendReceiveExpiredorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_6)org.jboss.test.jbossmq.test.Jms11UnitTest::testSendListenOutdatedorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_6)org.jboss.test.jbossmq.test.Jms11UnitTest::testQueueMessageOrderorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_7)org.jboss.test.jbossmq.test.Jms11UnitTest::testTemporaryQueueDeleteorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_7)org.jboss.test.jbossmq.test.Jms11UnitTest::testTemporaryTopicDeleteorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_7)org.jboss.test.jbossmq.test.Jms11UnitTest::testInvalidDestinationQueueSendorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_7)org.jboss.test.jbossmq.test.Jms11UnitTest::testInvalidDestinationQueueBrowseorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_7)org.jboss.test.jbossmq.test.Jms11UnitTest::testInvalidDestinationTopicPublishorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_7)org.jboss.test.jbossmq.test.Jms11UnitTest::testErrorsTopicSubscribeorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_7)org.jboss.test.jbossmq.test.Jms11UnitTest::testCreateQueueorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_7)org.jboss.test.jbossmq.test.Jms11UnitTest::testMessageListenerorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_7)org.jboss.test.jbossmq.test.Jms11UnitTest::testApplicationServerStufforg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_7)org.jboss.test.jbossmq.test.Jms11UnitTest::testTopicsorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_7)org.jboss.test.jbossmq.test.Jms11UnitTest::testTopicNoLocalorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_7)org.jboss.test.jbossmq.test.Jms11UnitTest::testTopicNoLocalBounceorg.jboss.test.compatibility.test.matrix.MatrixTestContainer(jms_3_2_7)org.jboss.test.jbossmq.test.Jms11UnitTes
[JBoss-dev] undeploy a dependency?
I'm seeing start being
called twice for a particular MBean and thus, I'm getting an error. I
think what is happening is this:
1. deploy 'A' MBean, its dependency 'B' has not been resolved
2. Deploy 'B', resolve 'A''s dependency, call create/start
3. Undeploy 'B'
4. Deploy 'B'
Is this the correct behavior? Is the 4.0.4 kernel attempting to do
redploys correct?
This is a JUnit test. testPUDependencies runs fine. testDepends fails
as a service EJB3 created MBean gets start() called twice.
public class DependencyUnitTestCase
extends JBossTestCase
{
public void testPUDependencies() throws Exception
{
Stateless2 test = null;
boolean exceptionThrown = false;
try
{
test = (Stateless2)
getInitialContext().lookup("Stateless2Bean/remote");
test.createCustomer();
}
catch (Exception ex)
{
exceptionThrown = true;
}
assertTrue(exceptionThrown);
super.deploy("dependedon.sar");
try
{
test = (Stateless2)
getInitialContext().lookup("Stateless2Bean/remote");
test.createCustomer();
}
finally
{
super.undeploy("dependedon.sar");
}
}
public void testDepends() throws Exception
{
boolean exceptionThrown = false;
try
{
HasMBeanDependency dependency =
(HasMBeanDependency)getInitialContext().lookup("dependency-test/HasMBeanDependencyBean/remote");
}
catch (Exception e)
{
exceptionThrown = true;
}
assertTrue(exceptionThrown);
exceptionThrown = false;
try
{
HasXmlMBeanDependency dependency =
(HasXmlMBeanDependency)getInitialContext().lookup("dependency-test/HasXmlMBeanDependencyBean/remote");
}
catch (Exception e)
{
exceptionThrown = true;
}
assertTrue(exceptionThrown);
exceptionThrown = false;
super.deploy("dependedon.sar");
try
{
try
{
HasMBeanDependency dependency =
(HasMBeanDependency)getInitialContext().lookup("dependency-test/HasMBeanDependencyBean/remote");
}
catch (Exception e)
{
exceptionThrown = true;
}
assertTrue(exceptionThrown);
// should pass now
HasXmlMBeanDependency dependency =
(HasXmlMBeanDependency)getInitialContext().lookup("dependency-test/HasXmlMBeanDependencyBean/remote");
dependency.noop();
super.deploy("anotherdependedon.sar");
try
{
HasMBeanDependency dependency2 =
(HasMBeanDependency)getInitialContext().lookup("dependency-test/HasMBeanDependencyBean/remote");
dependency2.testNotNull();
}
finally
{
super.undeploy("anotherdependedon.sar");
}
}
finally
{
super.undeploy("dependedon.sar");
}
}
public static Test suite() throws Exception
{
return getDeploySetup(DependencyUnitTestCase.class,
"dependency-test.ear, ejbdepends.jar");
}
}
--
Bill Burke
Chief Architect
JBoss Inc.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-head-jdk-matrix Build Failed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-jdk-matrix?log=log20060201125533 BUILD FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:216: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-common.xml:64: Exit code: 1 See compile.log in Build Artifacts for details.Date of build: 02/01/2006 12:55:33Time to build: 47 minutes 12 secondsLast changed: 02/01/2006 12:38:44Last log entry: Multiple changes in serialization, performance and various other fixes Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build: (first 50 of 154)1.4modifiedtimfoxjms/tests/src/org/jboss/test/messaging/jms/message/base/MessageTestBase.javaMultiple changes in serialization, performance and various other fixes1.2modifiedtimfoxjms/tests/src/org/jboss/test/messaging/jms/persistence/JBossBytesMessageTransactionLogTest.javaMultiple changes in serialization, performance and various other fixes1.2modifiedtimfoxjms/tests/src/org/jboss/test/messaging/jms/persistence/JBossMapMessageTransactionLogTest.javaMultiple changes in serialization, performance and various other fixes1.2modifiedtimfoxjms/tests/src/org/jboss/test/messaging/jms/persistence/JBossMessageTransactionLogTest.javaMultiple changes in serialization, performance and various other fixes1.2modifiedtimfoxjms/tests/src/org/jboss/test/messaging/jms/persistence/JBossObjectMessageTransactionLogTest.javaMultiple changes in serialization, performance and various other fixes1.2modifiedtimfoxjms/tests/src/org/jboss/test/messaging/jms/persistence/JBossStreamMessageTransactionLogTest.javaMultiple changes in serialization, performance and various other fixes1.2modifiedtimfoxjms/tests/src/org/jboss/test/messaging/jms/persistence/JBossTextMessageTransactionLogTest.javaMultiple changes in serialization, performance and various other fixes1.19modifiedtimfoxjms/tests/src/org/jboss/test/messaging/tools/jmx/ServiceContainer.javaMultiple changes in serialization, performance and various other fixes1.3modifiedtimfoxjms/tests/src/org/jboss/test/messaging/tools/tx/TransactionImpl.javaMultiple changes in serialization, performance and various other fixes1.2modifiedtimfoxjms/tests/bin/perf-jndi.propertiesMultiple changes in serialization, performance and various other fixes1.2modifiedtimfoxjms/tests/bin/runperfMultiple changes in serialization, performance and various other fixes1.2modifiedtimfoxjms/tests/bin/runslaveMultiple changes in serialization, performance and various other fixes1.60modifiedtimfoxjms/tests/bin/runtestMultiple changes in serialization, performance and various other fixes1.35modifiedtimfoxjms/tests/etc/log4j.xmlMultiple changes in serialization, performance and various other fixes1.2modifiedtimfoxjms/tests/src/org/jboss/test/messaging/core/CoreMessage.javaMultiple changes in serialization, performance and various other fixes1.2modifiedtimfoxjms/tests/src/org/jboss/test/messaging/core/plugin/JDBCTransactionLogTest.javaMultiple changes in serialization, performance and various other fixes1.2modifiedtimfoxjms/tests/src/org/jboss/test/messaging/core/plugin/PersistentMessageStoreTest.javaMultiple changes in serialization, performance and various other fixes1.2modifiedtimfoxjms/tests/src/org/jboss/test/messaging/core/plugin/base/MessageStoreTestBase.javaMultiple changes in serialization, performance and various other fixes1.22modifiedtimfoxjms/tests/src/org/jboss/test/messaging/jms/ConnectionConsumerTest.javaMultiple changes in serialization, performance and various other fixes1.79modifiedtimfoxjms/tests/src/org/jboss/test/messaging/jms/MessageConsumerTest.javaMultiple changes in serialization, performance and various other fixes1.3modifiedtimfoxjms/src/main/org/jboss/messaging/core/message/MessageFactory.javaMultiple changes in serialization, performance and various other fixes1.14modifiedtimfoxjms/src/main/org/jboss/messaging/core/message/MessageSupport.javaMultiple changes in serialization, performance and various other fixes1.17modifiedtimfoxjms/src/main/org/jboss/messaging/core/message/RoutableSupport.javaMultiple changes in serialization, performance and various other fixes1.17modifiedtimfoxjms/src/main/org/jboss/messaging/core/message/WeakMessageReference.javaMultiple changes in serialization, performance and various other fixes1.2modifiedtimfoxjms/src/main/org/jboss/messaging/core/plugin/InMemoryMessageStore.javaMultiple changes in serialization, performance and various other fixes1.3modifiedtimfoxjms/src/main/org/jboss/messaging/core/plugin/JDBCMessageStore.javaMultiple changes in serialization, performance and various other fixes1.8modifiedtimfoxjms/src/main/org/jboss/messaging/core/plugin/JDBCTransactionLog.javaMultiple changes in serialization, performance and various other fixes1.2modifiedtimfoxjms/src/main/or
Re: [JBoss-dev] Re: Guessing datasource name
Doesn't help me on 4.0.3SP1. What we should *really* do is create those JNDI dependencies we were arguing about before. Adrian Brock wrote: Perhaps we should just byte the bullet and fix this naming confusion? The problem is everybody's existing config that uses it. e.g. JMS and login-config.xml that reference these names. You can certainly "fix" the stylesheet and change this config in jbossjca-service.xml -ds.xml 300:-ds.xml stylesheets/ConnectionFactoryTemplate.xsl false On Wed, 2006-02-01 at 12:52, Adrian Brock wrote: On Wed, 2006-02-01 at 12:05, Bill Burke wrote: Can I use: "jboss.jca:service=ManagedConnectionFactory,name=DefaultDS"? It is the DataSourceBinding or ConnectionFactoryBinding that you want to depend upon. This is what populates JNDI. Bill Burke wrote: In EJB3 I'm trying to guess the datasource MBean name so that I can create a dependency on it. I do this based on the JNDI name passed into persistence.xml. So, if the datsource is "java:/DefaultDS" I assume that there is a: "jboss.jca:service=DataSource,name=DefaultDS" mbean available. Is this a valid assumption? Thanks, Bill -- Bill Burke Chief Architect JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: Guessing datasource name
On Wed, 2006-02-01 at 12:05, Bill Burke wrote: > Can I use: > > "jboss.jca:service=ManagedConnectionFactory,name=DefaultDS"? > It is the DataSourceBinding or ConnectionFactoryBinding that you want to depend upon. This is what populates JNDI. > Bill Burke wrote: > > In EJB3 I'm trying to guess the datasource MBean name so that I can > > create a dependency on it. I do this based on the JNDI name passed into > > persistence.xml. So, if the datsource is "java:/DefaultDS" I assume > > that there is a: > > > > "jboss.jca:service=DataSource,name=DefaultDS" mbean available. > > > > Is this a valid assumption? > > > > Thanks, > > > > Bill > > -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Guessing datasource name
Adrian Brock wrote:
e.g. at least firebird has its own rar that is deployed this way.
Yes, this *exactly* where the user was complaining. EJB3 assumes the
Datasource MBean name.
Don't blame me for the different names, this is legacy rubbish
that dates back to 2.4.x
They should really all be just:
jboss.jca:service=ConnectionManager,name={jndiName}
If somebody doesn't use a -ds.xml (not recommended, but it
is the only way to use your own pool implementation) then who knows
what they called the MBean?...
Thanks,
Bill
--
Bill Burke
Chief Architect
JBoss Inc.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: Guessing datasource name
Perhaps we should just byte the bullet and fix this naming confusion? The problem is everybody's existing config that uses it. e.g. JMS and login-config.xml that reference these names. You can certainly "fix" the stylesheet and change this config in jbossjca-service.xml -ds.xml 300:-ds.xml stylesheets/ConnectionFactoryTemplate.xsl false On Wed, 2006-02-01 at 12:52, Adrian Brock wrote: > On Wed, 2006-02-01 at 12:05, Bill Burke wrote: > > Can I use: > > > > "jboss.jca:service=ManagedConnectionFactory,name=DefaultDS"? > > > > It is the DataSourceBinding or ConnectionFactoryBinding > that you want to depend upon. > > This is what populates JNDI. > > > Bill Burke wrote: > > > In EJB3 I'm trying to guess the datasource MBean name so that I can > > > create a dependency on it. I do this based on the JNDI name passed into > > > persistence.xml. So, if the datsource is "java:/DefaultDS" I assume > > > that there is a: > > > > > > "jboss.jca:service=DataSource,name=DefaultDS" mbean available. > > > > > > Is this a valid assumption? > > > > > > Thanks, > > > > > > Bill > > > -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Guessing datasource name
On Wed, 2006-02-01 at 11:57, Bill Burke wrote:
> In EJB3 I'm trying to guess the datasource MBean name so that I can
> create a dependency on it. I do this based on the JNDI name passed into
> persistence.xml. So, if the datsource is "java:/DefaultDS" I assume
> that there is a:
>
> "jboss.jca:service=DataSource,name=DefaultDS" mbean available.
>
> Is this a valid assumption?
>
There are degrees of valid assumption. :-)
If it is deployed as an xxx-datasource in a -ds.xml then yes.
See the stylesheet that creates the MBean config.
If it is deployed as an xxx-connection-factory then no.
http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJCALoginModule
shows the difference in the names and there is obviously no
DataSourceBinding.
e.g. at least firebird has its own rar that is deployed this way.
Don't blame me for the different names, this is legacy rubbish
that dates back to 2.4.x
They should really all be just:
jboss.jca:service=ConnectionManager,name={jndiName}
If somebody doesn't use a -ds.xml (not recommended, but it
is the only way to use your own pool implementation) then who knows
what they called the MBean?...
> Thanks,
>
> Bill
--
Adrian Brock
Chief Scientist
JBoss Inc.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Guessing datasource name
Can I use: "jboss.jca:service=ManagedConnectionFactory,name=DefaultDS"? Bill Burke wrote: In EJB3 I'm trying to guess the datasource MBean name so that I can create a dependency on it. I do this based on the JNDI name passed into persistence.xml. So, if the datsource is "java:/DefaultDS" I assume that there is a: "jboss.jca:service=DataSource,name=DefaultDS" mbean available. Is this a valid assumption? Thanks, Bill -- Bill Burke Chief Architect JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-head-jdk-matrix Build Failed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-jdk-matrix?log=log20060201115514 BUILD FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:173: The value of attribute "todir" associated with an element type "copy" must not contain the '<' character.Date of build: 02/01/2006 11:55:14Time to build: 0 secondsLast changed: 02/01/2006 11:10:33Last log entry: Fixed queue's messageCount() to count both undeliveries and deliveries Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build: (first 50 of 7)1.7modifiedafujms/src/etc/xmdesc/Queue-xmbean.xmlFixed queue's messageCount() to count both undeliveries and deliveries1.22modifiedafujms/src/main/org/jboss/messaging/core/NonRecoverableState.javaFixed queue's messageCount() to count both undeliveries and deliveries1.19modifiedafujms/src/main/org/jboss/messaging/core/State.javaFixed queue's messageCount() to count both undeliveries and deliveries1.18modifiedafujms/src/main/org/jboss/messaging/core/local/Queue.javaFixed queue's messageCount() to count both undeliveries and deliveries1.6modifiedaloubyanskytestsuite/src/main/org/jboss/test/xml/WildcardUnresolvedElementsUnitTestCase.javasome more xml content to test1.2modifiedaloubyanskytestsuite/src/main/org/jboss/test/xml/XsiTypeUnitTestCase.javaadded correct bindings, refactoring1.35modifiedaloubyanskycommon/src/main/org/jboss/xb/binding/sunday/unmarshalling/SundayContentHandler.javaquick fix to support for unmarshalling with xsi:type (related to JBWS-549)
[JBoss-dev] Guessing datasource name
In EJB3 I'm trying to guess the datasource MBean name so that I can create a dependency on it. I do this based on the JNDI name passed into persistence.xml. So, if the datsource is "java:/DefaultDS" I assume that there is a: "jboss.jca:service=DataSource,name=DefaultDS" mbean available. Is this a valid assumption? Thanks, Bill -- Bill Burke Chief Architect JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] EJB3StandaloneBootstrap implementation
I'm saying the ide should be creating the optimized metadata view as the project evolves. Of course this is an optional behavior. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Wednesday, February 01, 2006 10:13 AM To: jboss-development@lists.sourceforge.net Subject: Re: [JBoss-dev] EJB3StandaloneBootstrap implementation Scott M Stark wrote: > How can the scanClasspath() step be optimized/skipped in say an embedded > ejb3 project in jbosside where the data obtained during the scan was > written out in an optimized metadata store as part of the project say? > The definition of embedded is *simple*. This optimized metadata store should be an optional feature. We don't want to require the user to have a special directory structure or special configuration requirements other than putting stuff in the classpath. Also, in an IDE environment an optimized metadata store doesn't make much sense since users are recompiling, repackaging with each run. IMO, a scan to create an optimized metadata store does not improve development time, its just overhead. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: jboss-3.2-testsuite Build Failed
This is ignorable, all tests passed. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 01, 2006 10:54 AM To: Dimitris Andreadis; jboss-development@lists.sourceforge.net; QA Subject: jboss-3.2-testsuite Build Failed Importance: High View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-3.2-testsuite?log=log20060201110410 BUILD FAILED Ant Error Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:220: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-common.xml:142: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-common.xml:173: The value of attribute "todir" associated with an element type "copy" must not contain the '<' character. Date of build: 02/01/2006 11:04:10 Time to build: 48 minutes 0 seconds Last changed: 02/01/2006 07:18:46 Last log entry: fix compatibility test failures Unit Tests: (1847) Total Errors and Failures: (0) All Tests Passed Modifications since last build: (first 50 of 5) 1.1.4.3 modified dimitris testsuite/src/main/org/jboss/test/jbossmx/performance/TestCase.java fix compatibility test failures 1.1.4.3 modified dimitris testsuite/src/main/org/jboss/test/jbossmx/implementation/TestCase.java fix compatibility test failures 1.2.4.4 modified dimitris testsuite/src/main/org/jboss/test/jbossmx/compliance/TestCase.java fix compatibility test failures 1.1.4.2 modified dimitris common/src/main/org/jboss/util/id/GUID.java JBAS-2718, define a serialVersionUID for GUID and introduce SerialVersion. The default for 3.2..x will be legacy compatibility (3.2.x and maybe 4.0.0/4.0.1) which can be overriden by defining org.jboss.j2ee.Serialization for 4.0.2+ compatibility (the opposite of the 4.0.x branch) 1.2.4.2 modified dimitris common/src/main/org/jboss/util/id/SerialVersion.java JBAS-2718, define a serialVersionUID for GUID and introduce SerialVersion. The default for 3.2..x will be legacy compatibility (3.2.x and maybe 4.0.0/4.0.1) which can be overriden by defining org.jboss.j2ee.Serialization for 4.0.2+ compatibility (the opposite of the 4.0.x branch)
RE: [JBoss-dev] Generic Embedded/Bootstrap was RE: [JBoss-dev] EJB3StandaloneBootstrap implementation
Hello Adrian, This is really great, that is a much needed step for the MC usage/adoption IMHO. > I am starting work on a prototype of the following three new > modules (I am not sure these are good names :-) Yeah, not sure as well, but I am not sure i have great ideas at this point. > 1) Integration - Cross (other) container integration spi like > "how do I bind to jndi?", give me the transaction synchronizer, etc. OK. Why not simply JBoss SPI? > 2) Services - abstraction of our common container spi, such > that other projects can use these interfaces to talk to each > other rather than linking directly to implementation e.g. Who > knows whether the user wants to use JBossJTA or JBoss Transactions? What is the real difference with 1)? I mean, 2) is really the SPI interface while 1) simply looks like a factory/finder to this SPI. Right? If that is the case, not sure we need to split them. > 3) Embedded - an extension to the kernel module that > introduces aop, jmx, profile service and eventually > aspectized deployments (all optional) What are "profile service"? Is that what you refere as SPI above or something else? These extensions are different "Personnalities", right? A JMX personnality, an AOP one, etc. right? There could be an OSGi as well, correct? > My plans for enhanced embedded bootstrap implementations are: > * Explicit - tell me what you want to do > - suitable for extension > > * Classpath - like current MC Standalone bootstrap > - suitable for main() usage I don't get this one compared to the previous one > * "URLClassLoader" - parse getURLs() and look for config > relative to this > - suitable for running inside an EJB container, servlet > container, etc. > > * Test - shared base common config + test specific config > - suitable for use in JUnit/TestNG I am not sure what you are really trying to do there? > I think this has some redundancy with the EJB3 bootstrap > methods but it doesn't make sense to have this EJB3 specific. > e.g. I want to > * bootstrap/configure some JBoss Service inside a servlet > context of another JEE container > * run tests against a service that requires other services > * provide a real standalone distribution of JBoss Messaging > * etc. > > My motivation for this prototype is not to get a product out > of it yet. It is to flush out the integration details between > the projects. Is that a bandwidth issue or something else? I think it is really important to do and I wouldn't be affraid to put it as "a product" if it raises its priority. That is great work Adrian, it is very important to setup this foundation to JEMS. Cheers, Sacha --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-3.2-testsuite Build Failed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-3.2-testsuite?log=log20060201110410 BUILD FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:220: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-common.xml:142: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-common.xml:173: The value of attribute "todir" associated with an element type "copy" must not contain the '<' character.Date of build: 02/01/2006 11:04:10Time to build: 48 minutes 0 secondsLast changed: 02/01/2006 07:18:46Last log entry: fix compatibility test failures Unit Tests: (1847) Total Errors and Failures: (0)All Tests Passed Modifications since last build: (first 50 of 5)1.1.4.3modifieddimitristestsuite/src/main/org/jboss/test/jbossmx/performance/TestCase.javafix compatibility test failures1.1.4.3modifieddimitristestsuite/src/main/org/jboss/test/jbossmx/implementation/TestCase.javafix compatibility test failures1.2.4.4modifieddimitristestsuite/src/main/org/jboss/test/jbossmx/compliance/TestCase.javafix compatibility test failures1.1.4.2modifieddimitriscommon/src/main/org/jboss/util/id/GUID.javaJBAS-2718, define a serialVersionUID for GUID and introduce SerialVersion. The default for 3.2..x will be legacy compatibility (3.2.x and maybe 4.0.0/4.0.1) which can be overriden by defining org.jboss.j2ee.Serialization for 4.0.2+ compatibility (the opposite of the 4.0.x branch)1.2.4.2modifieddimitriscommon/src/main/org/jboss/util/id/SerialVersion.javaJBAS-2718, define a serialVersionUID for GUID and introduce SerialVersion. The default for 3.2..x will be legacy compatibility (3.2.x and maybe 4.0.0/4.0.1) which can be overriden by defining org.jboss.j2ee.Serialization for 4.0.2+ compatibility (the opposite of the 4.0.x branch)
Re: [JBoss-dev] EJB3StandaloneBootstrap implementation
Scott M Stark wrote:
How can the scanClasspath() step be optimized/skipped in say an embedded
ejb3 project in jbosside where the data obtained during the scan was
written out in an optimized metadata store as part of the project say?
The definition of embedded is *simple*. This optimized metadata store
should be an optional feature. We don't want to require the user to
have a special directory structure or special configuration requirements
other than putting stuff in the classpath. Also, in an IDE environment
an optimized metadata store doesn't make much sense since users are
recompiling, repackaging with each run.
IMO, a scan to create an optimized metadata store does not improve
development time, its just overhead.
I don't really follow adding aspects like clustering to deployments
based on the location in a filesystem, virtual or otherwise. Just seems
like too much meaning being linked to the deployment url/location.
Its not that different than the singleton stuff. The point is that
users shouldn't have to configure each component to be clustered (or
not) and repackage.
I'm busy through tomorrow, but come thu I will just checkin the current
vfs stuff I have had sitting in the workspace for months and see what
start can be made on pushing this forward.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill
Burke
Sent: Tuesday, January 31, 2006 9:28 AM
To: jboss-development@lists.sourceforge.net
Subject: Re: [JBoss-dev] EJB3StandaloneBootstrap implementation
I think going the E-EJB3 route to start is a good idea as it will force
us to implement bare-bones implementations that do not have the idea of
a classloader or j2ee deployment schemes within them. Once we have
e-ejb3 (really e-jboss) in place, it will force us to be careful about
adding things like classloading and j2ee packaging as to not break or
bloat e-jboss.
The way I envision it working is basically how it works with current
kernel
* This shit must be REALLY FAST. Remember, we're using it with junit
tests.
* embedded-jboss-beans.xml configures a MainDeployer, BeanDeployer,
AOPDeployer, EJB3Deployer, (etc.) and basic services like TM, JNDI, etc.
* EJB3StandaloneBootstrap still exists and has three methods:
- boot(): This loads embeddded-jboss-beans.xml
- scanClasspath(). The scans the entire classpath for deployments and
calls MainDeployer.deploy() for each jar/directory/config file it finds.
calling MainDeployer.deploy(URL).
- scanClasspath(String) comma delimited list of files that should be
deployed. These files are in the classpath (java.class.path)
- deployResource(String) deploys an individual Classpath resource.
("ejb3-interceptors-aop.xml") by calling MainDeployer.deploy(URL)
My second thought is that Scanners should be responsible for creating
the DeploymentUnit rather than the main deployer. This will allow the
scanner to add metadata about the deployment or to work with different
"filesystems", like a database or profile. For instance, I envision a
cluster/ directory where any deployment put in it that supports
clustering will be clustered. The scanner could also be configured for
default security domain. For this to work, the scanner needs to attach
metadata to the deploymentunit. Since the MainDeployer will not be
responsible for creating the deployment unit, this will make it easier.
If you look at the EJB3 code, you will also find that I have done a
kernel abstraction so that the EJB3 deployer and codebase does not have
to be concerned about whether you are deployment to JBoss4 or MC. If we
do the new deployers right, the new architecture can be used as an
abstraction for projects that need to work in both JBoss4 and MC.
Man, I want to help prototype this stuff. I was about to do it for the
last EJB3 release, but I ran out of time. I'll want to jump in and help
after I finish the EJB3 book.
Later,
Bill
Scott M Stark wrote:
I browsed through the EJB3StandaloneBootstrap and embedded ejb3 usage
of the mc to see what extent the mc is being used. In browsing through
the conf/embedded-jboss-beans.xml for the mc config, I did not see
anything related to the ejb3 container or aop layer to load the
conf/ejb3-interceptors-aop.xml. The embedded ejb3 docs show this
prototype code block for setting up embedded ejb3:
EJB3StandaloneBootstrap.boot(null);
// initialize JBoss MQ core services
EJB3StandaloneBootstrap.deployXmlResource("jboss-jms-beans.xml");
// initialize configured test queue and topic
EJB3StandaloneBootstrap.deployXmlResource("testjms.xml");
// scan classpath for ejbs and MDBs
EJB3StandaloneBootstrap.scanClasspath();
So a lot of configuration is being done outside of the mc
embedded-jboss-beans.xml. I guess this is due to missing implementation
details of the mc such as the vfs, virtual deployment impl, and class
loader configuration. I have been thi
[JBoss-dev] jboss-remoting-testsuite-1.5 Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-remoting-testsuite-1.5?log=log20060201085214 TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-remoting.xml:96: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build: 02/01/2006 08:52:14Time to build: 72 minutes 15 secondsLast changed: 12/31/2005 20:37:24Last log entry: JBREM-272:Added tests for (clientPool != null) and (threadPool != null) in cleanup. Unit Tests: (287) Total Errors and Failures: (12)testStartorg.jboss.test.remoting.callback.pull.memory.callbackstore.CallbackStoreCallbackTestCase(java_serialization)testStartorg.jboss.test.remoting.callback.pull.memory.callbackstore.CallbackStoreCallbackTestCase(jboss_serialization)testStartorg.jboss.test.remoting.transport.multiplex.BasicServerSocketTestCase(java_serialization)testStartorg.jboss.test.remoting.transport.multiplex.BasicServerSocketTestCase(jboss_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerConfigTestCase(java_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerConfigTestCase(java_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerConfigTestCase(jboss_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerConfigTestCase(jboss_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase(java_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase(java_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase(jboss_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase(jboss_serialization) Modifications since last build: (first 50 of 2026)1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/TimeoutClientTest.javaJBREM-235 - added new lgpl headers.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/TimeoutServerTest.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/TimeoutTestCase.javaJBREM-235 - added new lgpl headers.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/ComplexObject.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/WebInvocationHandler.javaJBREM-235 - added new lgpl headers.1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/WebInvokerTestClient.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TestClient.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TestServer.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TestServerImpl.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TransporterTestCase.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/SSLInvokerConstants.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerClientTest.javaJBREM-235 - added new lgpl headers.1.8modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerServerTest.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerTestCase.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerClientTest.javaJBREM-235 - added new lgpl headers.1.7modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerServerTest.javaJBREM-235 - added new lgpl headers.1.5modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerTestCase.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/test/SSLSimpleClient.javaJBREM-235 - added new lgpl headers.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/test/SSLSimpleServer.javaJBREM-235 - added new lgpl headers.1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/keepalive/TimeoutClientTest.javaJBREM-235 - added new lgpl headers.1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/keepalive/TimeoutServerTest.javaJBREM-235 - added new lgpl headers.1.7modifiedrsigalsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerServerTest.javaJBREM-270:Replaced "," with "&"1.6modifiedrsigalsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerServerTest.javaJBREM-270
[JBoss-dev] Generic Embedded/Bootstrap was RE: [JBoss-dev] EJB3StandaloneBootstrap implementation
FYI
I am starting work on a prototype of the following three
new modules (I am not sure these are good names :-)
1) Integration - Cross (other) container integration spi
like "how do I bind to jndi?", give me the transaction synchronizer,
etc.
2) Services - abstraction of our common container spi, such that
other projects can use these interfaces to talk to each other
rather than linking directly to implementation
e.g. Who knows whether the user wants to use
JBossJTA or JBoss Transactions?
3) Embedded - an extension to the kernel module that introduces aop,
jmx, profile service and eventually aspectized deployments
(all optional)
My plans for enhanced embedded bootstrap implementations are:
* Explicit - tell me what you want to do
- suitable for extension
* Classpath - like current MC Standalone bootstrap
- suitable for main() usage
* "URLClassLoader" - parse getURLs() and look for config relative
to this
- suitable for running inside an EJB container, servlet container, etc.
* Test - shared base common config + test specific config
- suitable for use in JUnit/TestNG
I think this has some redundancy with the EJB3 bootstrap methods
but it doesn't make sense to have this EJB3 specific.
e.g. I want to
* bootstrap/configure some JBoss Service inside a
servlet context of another JEE container
* run tests against a service that requires other services
* provide a real standalone distribution of JBoss Messaging
* etc.
My motivation for this prototype is not to get a product
out of it yet. It is to flush out the integration details
between the projects.
In particular, AOP and MC. I started the new jca project for
this purpose as well, but I haven't had any real feedback
on this prototype from the AOP team.
It also includes a simple AOP proxy replacement for org.jboss.proxy
in the aspects module (again a prototype) and POJOs to allow
aspects to be configured via DI in the MC.
Bill did help me with some pointcut definition enhancements
to implement MessageEndpoint properly.
I'm hoping if I do this for something less esoteric than JCA
then I will get some feedback ;-)
On Tue, 2006-01-31 at 22:26, Scott M Stark wrote:
> How can the scanClasspath() step be optimized/skipped in say an embedded
> ejb3 project in jbosside where the data obtained during the scan was
> written out in an optimized metadata store as part of the project say?
>
> I don't really follow adding aspects like clustering to deployments
> based on the location in a filesystem, virtual or otherwise. Just seems
> like too much meaning being linked to the deployment url/location.
>
> I'm busy through tomorrow, but come thu I will just checkin the current
> vfs stuff I have had sitting in the workspace for months and see what
> start can be made on pushing this forward.
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Bill
> Burke
> Sent: Tuesday, January 31, 2006 9:28 AM
> To: jboss-development@lists.sourceforge.net
> Subject: Re: [JBoss-dev] EJB3StandaloneBootstrap implementation
>
> I think going the E-EJB3 route to start is a good idea as it will force
> us to implement bare-bones implementations that do not have the idea of
> a classloader or j2ee deployment schemes within them. Once we have
> e-ejb3 (really e-jboss) in place, it will force us to be careful about
> adding things like classloading and j2ee packaging as to not break or
> bloat e-jboss.
>
> The way I envision it working is basically how it works with current
> kernel
>
> * This shit must be REALLY FAST. Remember, we're using it with junit
> tests.
> * embedded-jboss-beans.xml configures a MainDeployer, BeanDeployer,
> AOPDeployer, EJB3Deployer, (etc.) and basic services like TM, JNDI, etc.
> * EJB3StandaloneBootstrap still exists and has three methods:
> - boot(): This loads embeddded-jboss-beans.xml
> - scanClasspath(). The scans the entire classpath for deployments and
> calls MainDeployer.deploy() for each jar/directory/config file it finds.
>
> calling MainDeployer.deploy(URL).
> - scanClasspath(String) comma delimited list of files that should be
> deployed. These files are in the classpath (java.class.path)
> - deployResource(String) deploys an individual Classpath resource.
> ("ejb3-interceptors-aop.xml") by calling MainDeployer.deploy(URL)
>
> My second thought is that Scanners should be responsible for creating
> the DeploymentUnit rather than the main deployer. This will allow the
> scanner to add metadata about the deployment or to work with different
> "filesystems", like a database or profile. For instance, I envision a
> cluster/ directory where any deployment put in it that supports
> clustering will be clustered. The scanner could also be configured for
> default security domain. For this to work, the scanner needs to attach
> metadata to the deploymentunit. Since the MainDeployer will not be
> responsible for creating the deployment unit, this will make it easier.
[JBoss-dev] jboss-remoting-testsuite-1.4 Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-remoting-testsuite-1.4?log=log20060201042107 TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-remoting.xml:96: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build: 02/01/2006 04:21:07Time to build: 17 minutes 35 seconds Unit Tests: (142) Total Errors and Failures: (5)testStartorg.jboss.test.remoting.transport.multiplex.BasicServerSocketTestCase(java_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerConfigTestCase(java_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerConfigTestCase(java_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase(java_serialization)unknownorg.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase(java_serialization) Modifications since last build: (first 50 of 0)
[JBoss-dev] jboss-portal-2.0-testsuite Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-portal-2.0-testsuite?log=log20060201035602 TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-portal.xml:67: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-portal.xml:93: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-portal.xml:278: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build: 02/01/2006 03:56:02Time to build: 2 minutes 16 secondsLast changed: 12/28/2005 00:15:42Last log entry: - targetWindowRef rename Unit Tests: (67) Total Errors and Failures: (25)testAorg.jboss.portal.test.cms.stress.ConcurrentTestCasetestIfFalseorg.jboss.portal.test.core.IfTagTestCasetestIfTrueorg.jboss.portal.test.core.IfTagTestCasetestFindUser1org.jboss.portal.test.core.RoleModelTestCasetestFindUser2org.jboss.portal.test.core.RoleModelTestCasetestFindUsersorg.jboss.portal.test.core.RoleModelTestCasetestCreateUserorg.jboss.portal.test.core.RoleModelTestCasetestCreateRoleorg.jboss.portal.test.core.RoleModelTestCasetestCountUserorg.jboss.portal.test.core.RoleModelTestCasetestRemoveNonExistingRoleorg.jboss.portal.test.core.RoleModelTestCasetestRemoveRoleorg.jboss.portal.test.core.RoleModelTestCasetestRemoveUserorg.jboss.portal.test.core.RoleModelTestCasetestFindRolesorg.jboss.portal.test.core.RoleModelTestCasetestFindRoleMembersorg.jboss.portal.test.core.RoleModelTestCasetestResourceBundleorg.jboss.portal.test.portlet.portletconfig.PortletConfigTestCasetestResourceBundleCascadeorg.jboss.portal.test.portlet.portletconfig.PortletConfigTestCasetestGetResourceBundleDuringInitorg.jboss.portal.test.portlet.portletconfig.PortletConfigTestCase Modifications since last build: (first 50 of 2315)1.24modifiedjulientools/etc/buildfragments/libraries.entbranches: 1.24.2; 1.24.4;update jboss cache jars to those of 4.0.3SP11.23modifiedjulientools/etc/buildfragments/libraries.entswitching to facelets that provide a decent support for inclusion and thus enable reusability of JSF sub trees1.7modifiedjulientools/etc/buildfragments/modules.entadded the faces modules to the build1.7modifiedjulienthirdparty/jboss-system/README.txtupdates jboss thirdparty to 4.0.3SP1fix the redeployment issue of jboss portal related to the dynamic proxy class loading issue1.6modifiedjulienthirdparty/jboss-system/lib/jboss-common.jarupdates jboss thirdparty to 4.0.3SP1fix the redeployment issue of jboss portal related to the dynamic proxy class loading issue1.6modifiedjulienthirdparty/jboss-system/lib/jboss-jmx.jarupdates jboss thirdparty to 4.0.3SP1fix the redeployment issue of jboss portal related to the dynamic proxy class loading issue1.6modifiedjulienthirdparty/jboss-system/lib/jboss-system.jarupdates jboss thirdparty to 4.0.3SP1fix the redeployment issue of jboss portal related to the dynamic proxy class loading issue1.6modifiedjulienthirdparty/jboss-j2ee/lib/jboss-j2ee.jarupdates jboss thirdparty to 4.0.3SP1fix the redeployment issue of jboss portal related to the dynamic proxy class loading issue1.7modifiedjulienthirdparty/jboss-server/README.txtupdates jboss thirdparty to 4.0.3SP1fix the redeployment issue of jboss portal related to the dynamic proxy class loading issue1.6modifiedjulienthirdparty/jboss-server/lib/jboss.jarupdates jboss thirdparty to 4.0.3SP1fix the redeployment issue of jboss portal related to the dynamic proxy class loading issue1.7modifiedjulienthirdparty/jboss-sx/README.txtupdates jboss thirdparty to 4.0.3SP1fix the redeployment issue of jboss portal related to the dynamic proxy class loading issue1.7modifiedjulienthirdparty/jboss-sx/lib/jbosssx.jarupdates jboss thirdparty to 4.0.3SP1fix the redeployment issue of jboss portal related to the dynamic proxy class loading issue1.7modifiedjulienthirdparty/jboss-j2ee/README.txtupdates jboss thirdparty to 4.0.3SP1fix the redeployment issue of jboss portal related to the dynamic proxy class loading issue1.6modifiedmholznertools/etc/buildfragments/modules.entadded security module1.22modifiedjulientools/etc/buildfragments/libraries.entadded the myfaces entry in the libraries1.3modifiedjulientools/etc/tagdiff.xsl- added dispatch() method on Invocation that delivers the invocation to the target- made the interceptor service citizen so we can apply on them management and dependency management- removed the relationship between the Server and the RequestController- removed the PortletDispatcherInterceptor and delegate to the portlet container the way the API call must be delivered to the target portlet- removed the ExecuteCommandInterceptor that is not necessary, same for the ControllerInterceptor1.5modifiedpalbertools/etc/buildfragm
