[jboss-cvs] JBossAS SVN: r77992 - 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:10:20 EDT 2008
Author: smcgowan at redhat.com
Date: 2008-09-04 13:10:20 -0400 (Thu, 04 Sep 2008)
New Revision: 77992
Modified:
branches/JBPAPP_4_3_0_GA_CC/testsuite/src/resources/cc/testCaseMapping_1.0.xml
Log:
update test case mapping 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 16:49:32 UTC (rev 77991)
+++ branches/JBPAPP_4_3_0_GA_CC/testsuite/src/resources/cc/testCaseMapping_1.0.xml 2008-09-04 17:10:20 UTC (rev 77992)
@@ -13,6 +13,8 @@
tsfi.jms - JMS traffic
+ tsfi.jts.api - JBossTS API
+
tsfi.ws.http - Web Services over HTTP
tsfi.ws.https - Web Services over HTTPS
@@ -63,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.</desc>
+ <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>
<test name="testSecurityDomain">
<desc>Validate that the users have the expected logins and roles.</desc>
<TSFI>tsfi.rmi.jrmp</TSFI>
@@ -1762,42 +1764,87 @@
<!-- JBoss (TOE) has passed J2EE TCK 1.4, so some testcases from there are also picked up -->
<testSuite name="CTS">
- <testCase name="J2EE">
- <desc>J2EETM 1.4 Platform assertions</desc>
- <test name="J2EE:SPEC:21">
- <desc> All J2EE products are required to support three login mechanisms: HTTP basic authentication, SSL mutual authentication, and form-based login. An application is not required to use any of these mechanisms, but they are required to be available for any application's use.</desc>
- <TSFI>tsfi.http</TSFI>
+ <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>
+ <TSFI>tsfi.jts.api</TSFI>
</test>
- <test name="J2EE:SPEC:22">
- <desc>All J2EE products are required to support HTTP basic authentication (RFC2068). Platform Providers are also required to support basic authentication over SSL.</desc>
- <TSFI>tsfi.http</TSFI>
- <TSFI>tsfi.https</TSFI>
+ <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>
+ <TSFI>tsfi.jts.api</TSFI>
</test>
- <test name="J2EE:SPEC:25">
- <desc>Web containers are required to support access to web resources by clients that have not authenticated themselves to the container. This is the common mode of access to web resources on the Internet. A web container reports that no user has been authenticated by returning null from the HttpServletRequest method getUserPrincipal. This is different than the corresponding result for EJB containers. The EJB specification requires that the EJBContext method getCallerPrincipal always return a valid Principal object. The method can never return null. Components running in a web container must be able to call enterprise beans even when no user has been authenticated in the web container. When a call is made in such a case from a component in a web container to an enterprise bean, a J2EE product must provide a principal for use in the call. A J2EE product may provide a principal for use by unauthenticated callers using many approaches, including, but not limited to: Alw!
ays use a single distinguished principal. Use a different distinguished principal per server, or per session, or per application. Allow the deployer or system administrator to choose which principal to use through the Run As capability of the web and enterprise bean containers. </desc>
- <TSFI>tsfi.http</TSFI>
+ </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>
+ <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>
+ <TSFI>tsfi.jts.api</TSFI>
</test>
- <test name="J2EE:SPEC:27">
- <desc>A Product Provider must support both of the following: 1. Configured Identity.AJ2EE container must be able to authenticate for access to the resource using a principal and authentication data specified by a Deployer at deployment time.The authentication must not depend in any way on data provided by the application components. Providing for the confidential storage of the authentication information is the responsibility of the Product Provider. 2. Programmatic Authentication. The J2EE product must provide for specification of the principal and authentication data for a resource by the application component at runtime using appropriate APIs. The application may obtain the principal and authentication data through a variety of mechanisms, including receiving them as parameters, obtaining them from the component's environment, and so forth.</desc>
- <TSFI>tsfi.http</TSFI>
+</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>
+ <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>
+ <TSFI>tsfi.jts.api</TSFI>
</test>
- <test name="J2EE:SPEC:30">
- <desc> Caller Authorization A J2EE product must enforce the access control rules specified at deployment time (see Section J2EE.3.6, Deployment Requirements) and more fully described in the EJB and servlet specifications.</desc>
+</testCase>
+<testCase name="com.sun.ts.tests.integration.sec.propagation.Client">
+ <desc>J2EE:SPEC:25 Web containers are required to support access to web resources by clients that have not authenticated themselves to the container. This is the common mode of access to web resources on the Internet. A web container reports that no user has been authenticated by returning null from the HttpServletRequest method getUserPrincipal. This is different than the corresponding result for EJB containers. The EJB specification requires that the EJBContext method getCallerPrincipal always return a valid Principal object. The method can never return null. Components running in a web container must be able to call enterprise beans even when no user has been authenticated in the web container. When a call is made in such a case from a component in a web container to an enterprise bean, a J2EE product must provide a principal for use in the call. A J2EE product may provide a principal for use by unauthenticated callers using many approaches, including, but not limited t!
o: Always use a single distinguished principal. Use a different distinguished principal per server, or per session, or per application. Allow the deployer or system administrator to choose which principal to use through the Run As capability of the web and enterprise bean containers. J2EE:SPEC:30 Propagated Caller Identities. It must be possible to configure a J2EE product so that a propagated caller identity is used in all authorization decisions. With this configuration, for all calls to all enterprise beans from a single application within a single J2EE product, the principal name returned by the EJBContext method getCallerPrincipal must be the same as that returned by the first enterprise bean in the call chain. If the first enterprise bean in the call chain is called by a servlet or JSP page, the principal name must be the same as that returned by the HttpServletRequest method getUserPrincipal in the calling servlet or JSP page. (However, if the HttpServletRequest met!
hod getUserPrincipal returns null, the principal used in calls to ente
rprise beans is not specified by this specification, although it must still be possible to configure enterprise beans to be callable by such components.) Note that this does not require delegation of credentials, only identification of the caller. A single principal must be the principal used in authorization decisions for access to all enterprise beans in the call chain. The requirements in this section apply only when a J2EE product has been configured to propagate caller identity.</desc>
+ <test name="test_web_to_ejb_noauth">
+ <desc>1. Send request for web_to_ejb_noauth.jsp, a jsp page that
+ is set up with no authentication.
+ 2. web_to_ejb_noauth.jsp looks up Bean1, a stateless
+ session bean.
+ 3. web_to_ejb_noauth.jsp calls
+ bean1.getCallerPrincipalName(), which returns
+ the caller principal.
+ 4. web_to_ejb_noauth.jsp returns the caller principal as
+ the contents of the web page as follows:
+ value of getUserPrincipal().getName()
+ call is successful or not
+ value of second call to getUserPrincipal()
+ 5. Receive response from web_to_ejb_noauth.jsp and ensure
+ the principal output is null for both calls in the jsp
+ and the call to the ejb is successful.
+
+ Note: The value returned for an unauthenticated caller from a
+ call to getRemoteUserPrincipal() in a servlet must
+ be null, and an unauthenticated caller can call an ejb
+ successfully.
+ </desc>
<TSFI>tsfi.http</TSFI>
- <TSFI>tsfi.rmi.jrmp</TSFI>
</test>
- <test name="J2EE:SPEC:31">
- <desc> Propagated Caller Identities. It must be possible to configure a J2EE product so that a propagated caller identity is used in all authorization decisions. With this configuration, for all calls to all enterprise beans from a single application within a single J2EE product, the principal name returned by the EJBContext method getCallerPrincipal must be the same as that returned by the first enterprise bean in the call chain. If the first enterprise bean in the call chain is called by a servlet or JSP page, the principal name must be the same as that returned by the HttpServletRequest method getUserPrincipal in the calling servlet or JSP page. (However, if the HttpServletRequest method getUserPrincipal returns null, the principal used in calls to enterprise beans is not specified by this specification, although it must still be possible to configure enterprise beans to be callable by such components.) Note that this does not require delegation of credentials, o!
nly identification of the caller. A single principal must be the principal used in authorization decisions for access to all enterprise beans in the call chain. The requirements in this section apply only when a J2EE product has been configured to propagate caller identity</desc>
+ <test name="test_web_to_ejb_auth">
+ <desc> 1. Send request for web_to_ejb_auth.jsp, a jsp page that
+ is set up for BASIC authentication. Pass in j2ee as
+ username and password.
+ 2. web_to_ejb_auth.jsp looks up Bean1, a stateless session
+ bean.
+ 3. web_to_ejb_auth.jsp calls
+ bean1.getCallerPrincipalName(), which returns
+ the caller principal.
+ 4. web_to_ejb_auth.jsp returns the caller principal as the
+ contents of the web page as follows.
+ value of getUserPrincipal().getName()
+ value of ejb.getCallerPrincipal().getName()
+ value of second call to getUserPrincipal()
+ 5. Receive response from web_to_ejb_auth.jsp and ensure
+ the principal output is "j2ee" for both the jsp and
+ the ejb.
+ </desc>
<TSFI>tsfi.http</TSFI>
</test>
- <test name="J2EE:SPEC:33">
- <desc> All J2EE products must implement the access control semantics described in the EJB, JSP, and servlet specifications, and provide a means of mapping the deployment descriptor security roles to the actual roles exposed by a J2EE product </desc>
+ </testCase>
+ <testCase name="com.sun.ts.tests.integration.sec.secbasicssl.Client">
+ <desc>J2EE:SPEC:22 All J2EE products are required to support HTTP basic authentication (RFC2068). Platform Providers are also required to support basic authentication over SSL.</desc>
+ <test name="test_login_basic_over_ssl">
+ <desc> This assertion ensures that HTTP Basic authentication over SSL is supported by the J2EE server. It first calls request.isSecure() to ensure it returns true, indicating that a secure connection is in place. Next, the fully qualified URL for the page being viewed is received via the HttpUtils.getRequestURL( request ) method. This url is checked to make sure it begins with https, indicating HTTPS is in use.</desc>
<TSFI>tsfi.http</TSFI>
+ <TSFI>tsfi.https</TSFI>
</test>
- <test name="">
- <desc></desc>
- <TSFI></TSFI>
- </test>
</testCase>
<!-- template -->
@@ -1808,6 +1855,6 @@
<TSFI></TSFI>
</test>
</testCase>
+
</testSuite>
-
-</cc:testCaseMapping>
\ No newline at end of file
+</cc:testCaseMapping>
More information about the jboss-cvs-commits
mailing list