[jboss-cvs] JBossAS SVN: r77993 - branches/JBPAPP_4_3_0_GA_CC/testsuite/src/resources/cc.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Thu Sep 4 13:14:22 EDT 2008
Author: smcgowan at redhat.com
Date: 2008-09-04 13:14:22 -0400 (Thu, 04 Sep 2008)
New Revision: 77993
Modified:
branches/JBPAPP_4_3_0_GA_CC/testsuite/src/resources/cc/testCaseMapping_1.0.xml
Log:
update test case mapping with the correct file
Modified: branches/JBPAPP_4_3_0_GA_CC/testsuite/src/resources/cc/testCaseMapping_1.0.xml
===================================================================
--- branches/JBPAPP_4_3_0_GA_CC/testsuite/src/resources/cc/testCaseMapping_1.0.xml 2008-09-04 17:10:20 UTC (rev 77992)
+++ branches/JBPAPP_4_3_0_GA_CC/testsuite/src/resources/cc/testCaseMapping_1.0.xml 2008-09-04 17:14:22 UTC (rev 77993)
@@ -65,7 +65,7 @@
</test>
</testCase>
<testCase name="org.jboss.ejb3.test.security.unit.EJBSpecUnitTestCase">
- <desc>Test of EJB spec conformace using the security-spec.jar deployment unit. These test the basic role based access model. The EJBs associated with these test cases use javax.annotation.security annotations as defined in Section 2.2 of the FSP.</desc>
+ <desc>Test of EJB spec conformance using the security-spec.jar deployment unit. These test the basic role based access model. These tests incorporate the use of the javax.annotation.security annotations: PermitAll, DeclareRoles, RolesAllowed, DenyAll, RunAs and org.jboss.annotation.security SecurityDomain</desc>
<test name="testSecurityDomain">
<desc>Validate that the users have the expected logins and roles.</desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
@@ -200,6 +200,32 @@
<TSFI>tsfi.rmi.http</TSFI>
</test>
</testCase>
+ <testCase name="org.jboss.ejb3.test.security.unit.ServletUnitTestCase">
+ <desc>Tests of servlet container integration into the JBoss server. This test
+ requires than a web container be integrated into the JBoss server. The tests
+ currently do NOT use the java.net.HttpURLConnection and associated http client
+ and these do not return valid HTTP error codes so if a failure occurs it
+ is best to connect the webserver using a browser to look for additional error
+ info.
+
+ The secure access tests require a user named 'jduke' with a password of 'theduke'
+ with a role of 'AuthorizedUser' in the servlet container.</desc>
+ <test name="testEJBServlet">
+ <desc></desc>
+ <TSFI>tsfi.http</TSFI>
+ </test>
+ </testCase>
+ <testCase name="org.jboss.test.security.test.ClientLoginModuleEJBUnitTestCase">
+ <desc>Call BeanA using jduke/theduke
+ +-- call BeanB switching idenity using ClientLoginModule
+ +---- call BeanC switching idenity using ClientLoginModule
+ validing the expected caller principal with different ejb method permissions</desc>
+ <test name="testClientLoginModule">
+ <desc></desc>
+ <TSFI>???jnp.. isn't it disabled?</TSFI>
+ </test>
+ </testCase>
+
<testCase name="">
<desc></desc>
<test name="">
@@ -227,11 +253,11 @@
</testCase>
<testCase name="org.jboss.test.security.test.DeepCopySubjectUnitTestCase">
<desc>JBAS-2657: Add option to deep copy the authenticated subject sets
- *
- * Testcase that unit tests the cloneability of various JBossSX
- * Principal/Groups
- * Also does a test of the serverside Subject deep copy via a mutable
- * Principal</desc>
+
+ Testcase that unit tests the cloneability of various JBossSX
+ Principal/Groups
+ Also does a test of the serverside Subject deep copy via a mutable
+ Principal</desc>
<test name="testSubjectCloning">
<desc>Test the Deep Copy of Subjects by the JaasSecurityManager via a test servlet deployed</desc>
<TSFI>tsfi.http</TSFI>
@@ -292,13 +318,11 @@
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testUncheckedRemote">
- <desc>Test access to a bean with a mix of remote interface permissions and
- * unchecked permissions with the unchecked permissions declared first.</desc>
+ <desc>Test access to a bean with a mix of remote interface permissions and unchecked permissions with the unchecked permissions declared first.</desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testRemoteUnchecked">
- <desc>Test access to a bean with a mix of remote interface permissions and
- * unchecked permissions with the unchecked permissions declared last.</desc>
+ <desc>Test access to a bean with a mix of remote interface permissions and unchecked permissions with the unchecked permissions declared last.</desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
</test>
<test name="testUnchecked">
@@ -563,21 +587,6 @@
<TSFI>tsfi.https</TSFI>
</test>
</testCase>
- <testCase name="org.jboss.ejb3.test.security.unit.ServletUnitTestCase">
- <desc>Tests of servlet container integration into the JBoss server. This test
- requires than a web container be integrated into the JBoss server. The tests
- currently do NOT use the java.net.HttpURLConnection and associated http client
- and these do not return valid HTTP error codes so if a failure occurs it
- is best to connect the webserver using a browser to look for additional error
- info.
-
- The secure access tests require a user named 'jduke' with a password of 'theduke'
- with a role of 'AuthorizedUser' in the servlet container.</desc>
- <test name="testEJBServlet">
- <desc></desc>
- <TSFI>tsfi.http</TSFI>
- </test>
- </testCase>
<testCase name="org.jboss.test.security.test.ClientLoginModuleEJBUnitTestCase">
<desc>Call BeanA using jduke/theduke
+-- call BeanB switching idenity using ClientLoginModule
@@ -1554,6 +1563,13 @@
<TSFI>???jnp.. isn't it disabled?</TSFI>
</test>
</testCase>
+ <testCase name="org.jboss.test.ha.farm.test.ClusterFileTransferTestCase">
+ <desc>The easiest way to deploy an application into the cluster is to use the farming service. That is to hot-deploy the application archive file (e.g., the EAR, WAR or SAR file) in the serverconfig/farm/directory of any of the cluster member and the application is automatically duplicated across all nodes in the same cluster.</desc>
+ <test name="testFarmDeploy">
+ <desc>Check to be sure the target application does not exist in either node of the Cluster. Generate the test archive and deploy to node0. Give appropriate time for the scanner to pick up the test archive. Verify archive was propagated to node1 and the files are identical.</desc>
+ <TSFI></TSFI>
+ </test>
+ </testCase>
<!-- template -->
<testCase name="">
@@ -1767,16 +1783,175 @@
<testCase name="com.sun.ts.tests.ejb.ee.timer.entity.cmp20.Client">
<desc>EJB:SPEC:864, 864.1, 864.2 If the Bean Provider invokes the setRollbackOnly method from within the ejbTimeout method, the container must rollback the transaction in which the ejbTimeout method is invoked. The container must retry the timeout after the transaction rollback. </desc>
<test name="rollbackTxInEjbTimeoutIntervalTest">
- <desc>Create a cmt bean implementing the TimedObject interface. Create an entity bean with two flags; one flag is set with a Requires method, the other with RequiresNew. Both flags are initialized unset. Create an interval timer. In a transaction context in the ejbTimeout method, set both flags, and cause the transaction to be rolled back. When the ejbTimeout method is retried, verify that the transaction has been rolled back if the RequiresNew flag is set and the Requires flag is unset. In the application client, block on a JMS receive for a period longer than the timer's duration. Verify that the correct message from ejbTimeout was received. API tested: TimerService.createTimer(long, long, Serializable) </desc>
+ <desc>Create a container-managed transaction bean implementing the TimedObject interface. Create an entity bean with two flags; one flag is set with a Requires method, the other with RequiresNew. Both flags are initialized unset. Create an interval timer. In a transaction context in the ejbTimeout method, set both flags, and cause the transaction to be rolled back. When the ejbTimeout method is retried, verify that the transaction has been rolled back if the RequiresNew flag is set and the Requires flag is unset. In the application client, block on a JMS receive for a period longer than the timer's duration. Verify that the correct message from ejbTimeout was received. API tested: TimerService.createTimer(long, long, Serializable) </desc>
<TSFI>tsfi.jts.api</TSFI>
</test>
<test name="rollbackTxInEjbTimeoutIntervalTest">
- <desc>>Create a cmt bean implementing the TimedObject interface. Create an entity bean with two flags; one flag is set with a Requires method, the other with RequiresNew. Both flags are initialized unset. Create an single-event timer. In a transaction context in the ejbTimeout method, set both flags, and cause the transaction to be rolled back. When the ejbTimeout method is retried, verify that the transaction has been rolled back if the RequiresNew flag is set and the Requires flag is unset. In the application client, block on a JMS receive for a period longer than the timer's duration. Verify that the correct message from ejbTimeout was received. API tested: TimerService.createTimer(long, Serializable)</desc>
+ <desc>>Create a container-managed transaction bean implementing the TimedObject interface. Create an entity bean with two flags; one flag is set with a Requires method, the other with RequiresNew. Both flags are initialized unset. Create an single-event timer. In a transaction context in the ejbTimeout method, set both flags, and cause the transaction to be rolled back. When the ejbTimeout method is retried, verify that the transaction has been rolled back if the RequiresNew flag is set and the Requires flag is unset. In the application client, block on a JMS receive for a period longer than the timer's duration. Verify that the correct message from ejbTimeout was received. API tested: TimerService.createTimer(long, Serializable)</desc>
<TSFI>tsfi.jts.api</TSFI>
</test>
</testCase>
+
+ <testCase name="com.sun.ts.tests.ejb.ee.timer.mdb.Client">
+ <desc>EJB:SPEC:864, 864.1, 864.2 If the Bean Provider invokes the setRollbackOnly method from within the ejbTimeout method, the container must rollback the transaction in which the ejbTimeout method is invoked. The container must retry the timeout after the transaction rollback. </desc>
+ <test name="rollbackTxInEjbTimeoutIntervalTest">
+ <desc>Create a message-driven container-managed transaction bean implementing the TimedObject interface. Create an entity bean with two flags; one flag is set with a Requires method, the other with RequiresNew. Both flags are initialized unset. Create an interval timer. In a transaction context in the ejbTimeout method, set both flags, and cause the transaction to be rolled back. When the ejbTimeout method is retried, verify that the transaction has been rolled back if the RequiresNew flag is set and the Requires flag is unset. In the application client, block on a JMS receive for a period longer than the timer's duration. Verify that the correct message from ejbTimeout was received. API tested: TimerService.createTimer(long, long, Serializable) </desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ <test name="rollbackTxInEjbTimeoutIntervalTest">
+ <desc>>Create a message-driven container-managed transaction bean implementing the TimedObject interface. Create an entity bean with two flags; one flag is set with a Requires method, the other with RequiresNew. Both flags are initialized unset. Create an single-event timer. In a transaction context in the ejbTimeout method, set both flags, and cause the transaction to be rolled back. When the ejbTimeout method is retried, verify that the transaction has been rolled back if the RequiresNew flag is set and the Requires flag is unset. In the application client, block on a JMS receive for a period longer than the timer's duration. Verify that the correct message from ejbTimeout was received. API tested: TimerService.createTimer(long, Serializable)</desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ </testCase>
+
+ <testCase name="com.sun.ts.tests.ejb.ee.timer.session.stateless.bm.Client">
+ <desc>EJB:SPEC:849 If an enterprise bean cancels a timer within a transaction, and if the transaction is rolled back, the container rescinds the timer cancellation. </desc>
+ <test name="cancelAndRollbackSingleEventTest">
+ <desc> Create a bean implementing the TimedObject interface.
+ In the ejbTimeout method, send a JMS message.
+ Create a single-event timer within a transaction
+ context.
+ In a separate transaction, cancel the timer and
+ roll back the transaction.
+ Access the timer and verify that no exception is
+ thrown.
+ In the application client, block on a JMS receive
+ for a period longer than the timer's duration.
+ Verify that the message is received.
+ API tested:
+ TimerService.createTimer(long, Serializable)
+ Timer.getHandle()
+ TimerHandle.getTimer()
+ </desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+</testCase>
+ <testCase name="com.sun.ts.tests.ejb.ee.timer.session.stateless.cm.Client">
+ <desc>EJB:SPEC:848 If an enterprise bean creates a timer within a transaction, and if the transaction is rolled back, the timer creation is rolled back.</desc>
+ <test name="rollbackTxOnCreationSingleEventTest">
+ <desc>>Create a container-managed transaction bean implementing the TimedObject interface. Create an entity bean with two flags; one flag is set with a Requires method, the other with RequiresNew. Both flags are initialized unset. Create an single-event timer. In a transaction context in the ejbTimeout method, set both flags, and cause the transaction to be rolled back. When the ejbTimeout method is retried, verify that the transaction has been rolled back if the RequiresNew flag is set and the Requires flag is unset. In the application client, block on a JMS receive for a period longer than the timer's duration. Verify that the correct message from ejbTimeout was received. API tested: TimerService.createTimer(long, Serializable)</desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ </testCase>
+ <testCase name="com.sun.ts.tests.ejb.ee.tx.entity.cmp.cm.Tx_SetRollbackOnly.Client">
+ <desc>EJB:SPEC:589 When the EJBContext.setRollbackOnly() method is invoked from a business method executing with the Required, RequiresNew, or Mandatory transaction attribute, the Container must ensure that the transaction will never commit. </desc>
+ <test name="test1">
+ <desc>setRollbackOnly with EJB - Required
+ Create an instance of a stateful session Testbean bean.
+ Create an instance of a stateful session TxECMPBean (Required) bean.
+ Perform a delete row operation to a table
+ and force a rollback via EJBContext.setRollbackOnly().
+ Ensure the EJBContext.getRollbackOnly() status returns true.
+ Ensure the transaction is rolledback.
+ </desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ <test name="test5">
+ <desc>setRollbackOnly with EJB - Mandatory
+ Create an instance of a stateful session Testbean bean.
+ Create an instance of a stateful session TxECMPBean (Mandatory) bean.
+ Mark a transaction involving an entity EJB for rollback, in a Mandatory case
+ Verify that and TransactionRequiredException is thrown due to the fact that the call to create was not in a transaction.
+ </desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ <test name="test8">
+ <desc>setRollbackOnly with EJB - RequiresNew
+ Create an instance of a stateful session Testbean bean.
+ Create an instance of a stateful session TxECMPBean (RequiresNew) bean.
+ Perform a delete row operation to a table
+ and force a rollback via EJBContext.setRollbackOnly().
+ Ensure the EJBContext.getRollbackOnly() status returns true.
+ Ensure the transaction is rolledback.
+ </desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ </testCase>
+
+ <testCase name="com.sun.ts.tests.ejb.ee.tx.session.stateful.bm.TxM_GlobalSingle.Client">
+ <desc>EJB:SPEC:543 The javax.transaction.UserTransaction interface is used to demarcate transactions for beans with bean-managed transaction demarcation. An enterprise bean with bean-managed transaction demarcation can rollback a transaction using the rollback() method of the javax.transaction.UserTransaction interface.</desc>
+ <test name="test2">
+ <desc> Create a stateful session TX_BEAN_MANAGED bean.
+ Obtain the UserTransaction interface.
+ Perform a global transactions using the TxBean
+ (deployed as TX_MANDATORY) to a single RDBMS table.
+ Insert/Delete followed by a rollback to a single table.
+ </desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ </testCase>
+
+
+ <testCase name="com.sun.ts.tests.ejb.ee.tx.session.stateful.bm.TxBM_GlobalSingle.Client">
+ <desc>EJB:SPEC:543 The javax.transaction.UserTransaction interface is used to demarcate transactions for beans with bean-managed transaction demarcation. An enterprise bean with bean-managed transaction demarcation can rollback a transaction using the rollback() method of the javax.transaction.UserTransaction interface.</desc>
+ <test name="test2">
+ <desc> Create a stateful session TX_BEAN_MANAGED bean.
+ Obtain the UserTransaction interface.
+ Perform a global transactions using the TxBean
+ (deployed as TX_BEAN_MANAGED) to a single RDBMS table.
+ Insert/Delete followed by a rollback to a single table.
+ </desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ </testCase>
+
+ <testCase name="com.sun.ts.tests.ejb.ee.tx.session.stateful.bm.TxS_GlobalSingle.Client">
+ <desc>EJB:SPEC:543 The javax.transaction.UserTransaction interface is used to demarcate transactions for beans with bean-managed transaction demarcation. An enterprise bean with bean-managed transaction demarcation can rollback a transaction using the rollback() method of the javax.transaction.UserTransaction interface.</desc>
+ <test name="test2">
+ <desc> Create a stateful session TX_BEAN_MANAGED bean.
+ Obtain the UserTransaction interface.
+ Perform a global transactions using the TxBean
+ (deployed as TX_SUPPORTS) to a single RDBMS table.
+ Insert/Delete followed by a rollback to a single table.
+ </desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ </testCase>
+
+ <testCase name="com.sun.ts.tests.ejb.ee.tx.session.stateful.bm.TxRN_GlobalSingle.Client">
+ <desc>EJB:SPEC:543 The javax.transaction.UserTransaction interface is used to demarcate transactions for beans with bean-managed transaction demarcation. An enterprise bean with bean-managed transaction demarcation can rollback a transaction using the rollback() method of the javax.transaction.UserTransaction interface.</desc>
+ <test name="test2">
+ <desc> Create a stateful session TX_BEAN_MANAGED bean.
+ Obtain the UserTransaction interface.
+ Perform a global transactions using the TxBean
+ (deployed as TX_REQUIRESNEW) to a single RDBMS table.
+ Insert/Delete followed by a rollback to a single table.
+ </desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ </testCase>
+
+ <testCase name="com.sun.ts.tests.ejb.ee.tx.session.stateful.bm.TxR_GlobalSingle.Client">
+ <desc>EJB:SPEC:543 The javax.transaction.UserTransaction interface is used to demarcate transactions for beans with bean-managed transaction demarcation. An enterprise bean with bean-managed transaction demarcation can rollback a transaction using the rollback() method of the javax.transaction.UserTransaction interface.</desc>
+ <test name="test2">
+ <desc> Create a stateful session TX_BEAN_MANAGED bean.
+ Obtain the UserTransaction interface.
+ Perform a global transactions using the TxBean
+ (deployed as TX_REQUIRES) to a single RDBMS table.
+ Insert/Delete followed by a rollback to a single table.
+ </desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ </testCase>
+
+ <testCase name="com.sun.ts.tests.ejb.ee.pm.ejbql.tx.Client">
+ <desc>The Container is responsible for ensuring that updates to the states of all entity beans in the same transaction context as the ejbFindMETHOD method are visible in the results of the ejbFindMETHOD method. Before invoking the ejbFindMETHOD method, the container must therefore first synchronize the state of any entity bean instances that are participating in the same transaction context as it is used to execute the ejbFindMETHOD method by invoking ejbStore() method on those entity bean instances.</desc>
+ <test name="txTest2">
+ <desc>Create an instance of a CMP 2.0 entity bean. Begin a transaction with the transaction attribute set to Required. Update the data and ensure that the update is visible within the transaction context by invoking a finder method with associated EJB-QL. Rollback the transaction and verify the rollback was successful.</desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ <test name="txTest4">
+ <desc>Create an instance of a CMP 2.0 entity bean. Begin a transaction with the transaction attribute set to RequiredNew. Update the data and ensure that the update is visible within the transaction context by invoking a finder method with associated EJB-QL. Rollback the transaction and verify the rollback was successful.</desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ <test name="txTest6">
+ <desc>Create an instance of a CMP 2.0 entity bean. Begin a transaction with the transaction attribute set to Mandatory. Update the data and ensure that the update is visible within the transaction context by invoking a finder method with associated EJB-QL. Rollback the transaction and verify the rollback was successful.</desc>
+ <TSFI>tsfi.jts.api</TSFI>
+ </test>
+ </testCase>
+
<testCase name="com.sun.ts.tests.integration.session.jspejbjdbc.URLClient">
-<desc>J2EE:SPEC:40, 40.1, 40.2, J2EE:SPEC:47 Servlets and JSP pages may access multiple resource managers and invoke multiple enterprise beans within a single transaction. The specified transaction context is automatically propagated to the enterprise beans and transactional resource managers.The result of the propagation may be subject to the enterprise bean transaction attributes. If a web component invokes an enterprise bean from a thread associated with a JTA transaction, the J2EE platform must propagate the transaction context with the enterprise bean invocation. Whether the target enterprise bean will be invoked in this transaction context or not is determined by the rules defined in the EJB specification.</desc>
+<desc>J2EE:SPEC:40, 40.1, 40.2, J2EE:SPEC:47 JSP pages may access multiple resource managers and invoke multiple enterprise beans within a single transaction. The specified transaction context is automatically propagated to the enterprise beans and transactional resource managers.The result of the propagation may be subject to the enterprise bean transaction attributes. If a web component invokes an enterprise bean from a thread associated with a JTA transaction, the J2EE platform must propagate the transaction context with the enterprise bean invocation. Whether the target enterprise bean will be invoked in this transaction context or not is determined by the rules defined in the EJB specification.</desc>
<test name="test1">
<desc> Functional test to demonstrate an N-Tier client which performs database transactions via accessing web server component, ejb server component and database server component using the Application Programming Model as described in the J2EE Platform Specification. The test is a complete end-to-end tests and is modeled as follows: URLClient -> JSP -> JAVABEAN -> EJB -> DB. The test strategy is to create an N-Tier Application Test involving jsp and ejb. Deploy it on the J2EE server. Verify correct operations.
</desc>
@@ -1784,9 +1959,9 @@
</test>
</testCase>
<testCase name="com.sun.ts.tests.integration.entity.servletejbjdbc.URLClient">
-<desc>J2EE:SPEC:40, 40.1, 40.2, J2EE:SPEC:47 Servlets and JSP pages may access multiple resource managers and invoke multiple enterprise beans within a single transaction. The specified transaction context is automatically propagated to the enterprise beans and transactional resource managers.The result of the propagation may be subject to the enterprise bean transaction attributes. If a web component invokes an enterprise bean from a thread associated with a JTA transaction, the J2EE platform must propagate the transaction context with the enterprise bean invocation. Whether the target enterprise bean will be invoked in this transaction context or not is determined by the rules defined in the EJB specification.</desc>
+<desc>J2EE:SPEC:40, 40.1, 40.2, J2EE:SPEC:47 Servlets may access multiple resource managers and invoke multiple enterprise beans within a single transaction. The specified transaction context is automatically propagated to the enterprise beans and transactional resource managers.The result of the propagation may be subject to the enterprise bean transaction attributes. If a web component invokes an enterprise bean from a thread associated with a JTA transaction, the J2EE platform must propagate the transaction context with the enterprise bean invocation. Whether the target enterprise bean will be invoked in this transaction context or not is determined by the rules defined in the EJB specification.</desc>
<test name="test1">
- <desc> Functional test to demonstrate an N-Tier client which performs database transactions via accessing web server component, ejb server component and database server component using the Application Programming Model as described in the J2EE Platform Specification. The test is a complete end-to-end tests and is modeled as follows: URLClient -> JSP -> JAVABEAN -> EJB -> DB. The test strategy is to create an N-Tier Application Test involving jsp and ejb. Deploy it on the J2EE server. Verify correct operations.
+ <desc> Functional test to demonstrate an N-Tier client which performs database transactions via accessing web server component, ejb server component and database server component using the Application Programming Model as described in the J2EE Platform Specification. The test is a complete end-to-end tests and is modeled as follows: URLClient -> SERVLET -> JAVABEAN -> EJB -> DB. The test strategy is to create an N-Tier Application Test involving jsp and ejb. Deploy it on the J2EE server. Verify correct operations.
</desc>
<TSFI>tsfi.jts.api</TSFI>
</test>
More information about the jboss-cvs-commits
mailing list