Hibernate SVN: r17609 - in validator/trunk/hibernate-validator/src: main/java/org/hibernate/validator/metadata and 2 other directories.
by hibernate-commits＠lists.jboss.org
Author: hardy.ferentschik
Date: 2009-10-01 12:08:48 -0400 (Thu, 01 Oct 2009)
New Revision: 17609
Added:
validator/trunk/hibernate-validator/src/test/java/org/hibernate/validator/engine/serialization/
validator/trunk/hibernate-validator/src/test/java/org/hibernate/validator/engine/serialization/ConstraintViolationSerializationTest.java
validator/trunk/hibernate-validator/src/test/java/org/hibernate/validator/engine/serialization/SerializableClass.java
validator/trunk/hibernate-validator/src/test/java/org/hibernate/validator/engine/serialization/UnSerializableClass.java
Modified:
validator/trunk/hibernate-validator/src/main/java/org/hibernate/validator/engine/ConstraintViolationImpl.java
validator/trunk/hibernate-validator/src/main/java/org/hibernate/validator/engine/NodeImpl.java
validator/trunk/hibernate-validator/src/main/java/org/hibernate/validator/engine/PathImpl.java
validator/trunk/hibernate-validator/src/main/java/org/hibernate/validator/metadata/ConstraintDescriptorImpl.java
Log:
HV-245 Made ConstraintViolationImpl Serializable.
Modified: validator/trunk/hibernate-validator/src/main/java/org/hibernate/validator/engine/ConstraintViolationImpl.java
===================================================================
--- validator/trunk/hibernate-validator/src/main/java/org/hibernate/validator/engine/ConstraintViolationImpl.java 2009-10-01 14:07:23 UTC (rev 17608)
+++ validator/trunk/hibernate-validator/src/main/java/org/hibernate/validator/engine/ConstraintViolationImpl.java 2009-10-01 16:08:48 UTC (rev 17609)
@@ -26,7 +26,7 @@
* @author Emmanuel Bernard
* @author Hardy Ferentschik
*/
-public class ConstraintViolationImpl<T> implements ConstraintViolation<T> {
+public class ConstraintViolationImpl<T> implements ConstraintViolation<T>, java.io.Serializable {
private final String interpolatedMessage;
private final T rootBean;
private final Object value;
Modified: validator/trunk/hibernate-validator/src/main/java/org/hibernate/validator/engine/NodeImpl.java
===================================================================
--- validator/trunk/hibernate-validator/src/main/java/org/hibernate/validator/engine/NodeImpl.java 2009-10-01 14:07:23 UTC (rev 17608)
+++ validator/trunk/hibernate-validator/src/main/java/org/hibernate/validator/engine/NodeImpl.java 2009-10-01 16:08:48 UTC (rev 17609)
@@ -17,12 +17,13 @@
*/
package org.hibernate.validator.engine;
+import java.io.Serializable;
import javax.validation.Path;
/**
* @author Hardy Ferentschik
*/
-public class NodeImpl implements Path.Node {
+public class NodeImpl implements Path.Node, Serializable {
private static final String INDEX_OPEN = "[";
private static final String INDEX_CLOSE = "]";
Modified: validator/trunk/hibernate-validator/src/main/java/org/hibernate/validator/engine/PathImpl.java
===================================================================
--- validator/trunk/hibernate-validator/src/main/java/org/hibernate/validator/engine/PathImpl.java 2009-10-01 14:07:23 UTC (rev 17608)
+++ validator/trunk/hibernate-validator/src/main/java/org/hibernate/validator/engine/PathImpl.java 2009-10-01 16:08:48 UTC (rev 17609)
@@ -22,12 +22,13 @@
import java.util.List;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
+import java.io.Serializable;
import javax.validation.Path;
/**
* @author Hardy Ferentschik
*/
-public class PathImpl implements Path {
+public class PathImpl implements Path, Serializable {
/**
* Regular expression used to split a string path into its elements.
Modified: validator/trunk/hibernate-validator/src/main/java/org/hibernate/validator/metadata/ConstraintDescriptorImpl.java
===================================================================
--- validator/trunk/hibernate-validator/src/main/java/org/hibernate/validator/metadata/ConstraintDescriptorImpl.java 2009-10-01 14:07:23 UTC (rev 17608)
+++ validator/trunk/hibernate-validator/src/main/java/org/hibernate/validator/metadata/ConstraintDescriptorImpl.java 2009-10-01 16:08:48 UTC (rev 17609)
@@ -17,6 +17,7 @@
*/
package org.hibernate.validator.metadata;
+import java.io.Serializable;
import java.lang.annotation.Annotation;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
@@ -31,9 +32,9 @@
import java.util.Set;
import javax.validation.Constraint;
import javax.validation.ConstraintDefinitionException;
-import javax.validation.Payload;
import javax.validation.ConstraintValidator;
import javax.validation.OverridesAttribute;
+import javax.validation.Payload;
import javax.validation.ReportAsSingleViolation;
import javax.validation.ValidationException;
import javax.validation.groups.Default;
@@ -55,7 +56,7 @@
* @author Emmanuel Bernard
* @author Hardy Ferentschik
*/
-public class ConstraintDescriptorImpl<T extends Annotation> implements ConstraintDescriptor<T> {
+public class ConstraintDescriptorImpl<T extends Annotation> implements ConstraintDescriptor<T>, Serializable {
private static final Logger log = LoggerFactory.make();
private static final int OVERRIDES_PARAMETER_DEFAULT_INDEX = -1;
private static final String GROUPS = "groups";
@@ -98,7 +99,7 @@
/**
* Handle to the built-in constraint implementations.
*/
- private final ConstraintHelper constraintHelper;
+ private transient final ConstraintHelper constraintHelper;
public ConstraintDescriptorImpl(T annotation, ConstraintHelper constraintHelper, Class<?> implicitGroup) {
this.annotation = annotation;
@@ -216,7 +217,7 @@
return groups;
}
- public Set<Class< ? extends Payload>> getPayload() {
+ public Set<Class<? extends Payload>> getPayload() {
return payloads;
}
@@ -418,7 +419,7 @@
// groups get inherited from the parent
annotationDescriptor.setValue( GROUPS, groups.toArray( new Class<?>[groups.size()] ) );
- // HV-183 - payloads are propagated to composing constraints
+ // HV-183 - payloads are propagated to composing constraints
annotationDescriptor.setValue( PAYLOAD, payloads.toArray( new Class<?>[payloads.size()] ) );
U annotationProxy = AnnotationFactory.create( annotationDescriptor );
Copied: validator/trunk/hibernate-validator/src/test/java/org/hibernate/validator/engine/serialization/ConstraintViolationSerializationTest.java (from rev 17597, validator/trunk/hibernate-validator/src/test/java/org/hibernate/validator/engine/ValidatorTest.java)
===================================================================
--- validator/trunk/hibernate-validator/src/test/java/org/hibernate/validator/engine/serialization/ConstraintViolationSerializationTest.java (rev 0)
+++ validator/trunk/hibernate-validator/src/test/java/org/hibernate/validator/engine/serialization/ConstraintViolationSerializationTest.java 2009-10-01 16:08:48 UTC (rev 17609)
@@ -0,0 +1,85 @@
+// $Id$
+/*
+* JBoss, Home of Professional Open Source
+* Copyright 2008, Red Hat, Inc. and/or its affiliates, and individual contributors
+* by the @authors tag. See the copyright.txt in the distribution for a
+* full listing of individual contributors.
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+* http://www.apache.org/licenses/LICENSE-2.0
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+package org.hibernate.validator.engine.serialization;
+
+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.io.ObjectInputStream;
+import java.io.ObjectOutput;
+import java.io.ObjectOutputStream;
+import java.io.NotSerializableException;
+import java.util.Set;
+import javax.validation.ConstraintViolation;
+import javax.validation.Validator;
+
+import org.testng.annotations.Test;
+
+import org.hibernate.validator.util.TestUtil;
+import static org.hibernate.validator.util.TestUtil.assertNumberOfViolations;
+
+/**
+ * @author Hardy Ferentschik
+ */
+public class ConstraintViolationSerializationTest {
+
+ /**
+ * HV-245
+ */
+ @Test
+ public void testSuccessfulSerialization() throws Exception {
+ Validator validator = TestUtil.getValidator();
+ SerializableClass testInstance = new SerializableClass();
+ Set<ConstraintViolation<SerializableClass>> constraintViolations = validator.validate( testInstance );
+
+ byte[] bytes = serialize( constraintViolations );
+ Set<ConstraintViolation<?>> deserializedViolations = deserialize( bytes );
+ assertNumberOfViolations( deserializedViolations, 1 );
+ }
+
+ /**
+ * HV-245
+ */
+ @Test(expectedExceptions = NotSerializableException.class)
+ public void testUnSuccessfulSerialization() throws Exception {
+ Validator validator = TestUtil.getValidator();
+ UnSerializableClass testInstance = new UnSerializableClass();
+ Set<ConstraintViolation<UnSerializableClass>> constraintViolations = validator.validate( testInstance );
+
+ serialize( constraintViolations );
+ }
+
+ private byte[] serialize(Object o) throws Exception {
+ ByteArrayOutputStream stream = new ByteArrayOutputStream();
+ ObjectOutput out = new ObjectOutputStream( stream );
+ out.writeObject( o );
+ out.close();
+ byte[] serialized = stream.toByteArray();
+ stream.close();
+ return serialized;
+
+ }
+
+ private Set<ConstraintViolation<?>> deserialize(byte[] byteData) throws Exception {
+ ByteArrayInputStream byteIn = new ByteArrayInputStream( byteData );
+ ObjectInputStream in = new ObjectInputStream( byteIn );
+ Set<ConstraintViolation<?>> deserializedViolations = ( Set<ConstraintViolation<?>> ) in.readObject();
+ in.close();
+ byteIn.close();
+ return deserializedViolations;
+ }
+}
\ No newline at end of file
Added: validator/trunk/hibernate-validator/src/test/java/org/hibernate/validator/engine/serialization/SerializableClass.java
===================================================================
--- validator/trunk/hibernate-validator/src/test/java/org/hibernate/validator/engine/serialization/SerializableClass.java (rev 0)
+++ validator/trunk/hibernate-validator/src/test/java/org/hibernate/validator/engine/serialization/SerializableClass.java 2009-10-01 16:08:48 UTC (rev 17609)
@@ -0,0 +1,29 @@
+// $Id:$
+/*
+* JBoss, Home of Professional Open Source
+* Copyright 2008, Red Hat Middleware LLC, and individual contributors
+* by the @authors tag. See the copyright.txt in the distribution for a
+* full listing of individual contributors.
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+* http://www.apache.org/licenses/LICENSE-2.0
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+package org.hibernate.validator.engine.serialization;
+
+import java.io.Serializable;
+import javax.validation.constraints.NotNull;
+
+/**
+ * @author Hardy Ferentschik
+ */
+public class SerializableClass implements Serializable {
+ @NotNull
+ private String foo;
+}
Added: validator/trunk/hibernate-validator/src/test/java/org/hibernate/validator/engine/serialization/UnSerializableClass.java
===================================================================
--- validator/trunk/hibernate-validator/src/test/java/org/hibernate/validator/engine/serialization/UnSerializableClass.java (rev 0)
+++ validator/trunk/hibernate-validator/src/test/java/org/hibernate/validator/engine/serialization/UnSerializableClass.java 2009-10-01 16:08:48 UTC (rev 17609)
@@ -0,0 +1,28 @@
+// $Id:$
+/*
+* JBoss, Home of Professional Open Source
+* Copyright 2008, Red Hat Middleware LLC, and individual contributors
+* by the @authors tag. See the copyright.txt in the distribution for a
+* full listing of individual contributors.
+*
+* Licensed under the Apache License, Version 2.0 (the "License");
+* you may not use this file except in compliance with the License.
+* You may obtain a copy of the License at
+* http://www.apache.org/licenses/LICENSE-2.0
+* Unless required by applicable law or agreed to in writing, software
+* distributed under the License is distributed on an "AS IS" BASIS,
+* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+* See the License for the specific language governing permissions and
+* limitations under the License.
+*/
+package org.hibernate.validator.engine.serialization;
+
+import javax.validation.constraints.NotNull;
+
+/**
+ * @author Hardy Ferentschik
+ */
+public class UnSerializableClass {
+ @NotNull
+ private String foo;
+}
\ No newline at end of file
14 years, 7 months
- 1
- 0
Hibernate SVN: r17608 - beanvalidation/tck/trunk/src/main/docbook/en-US.
by hibernate-commits＠lists.jboss.org
Author: hardy.ferentschik
Date: 2009-10-01 10:07:23 -0400 (Thu, 01 Oct 2009)
New Revision: 17608
Modified:
beanvalidation/tck/trunk/src/main/docbook/en-US/Book_Info.xml
Log:
changed copyright info
Modified: beanvalidation/tck/trunk/src/main/docbook/en-US/Book_Info.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/docbook/en-US/Book_Info.xml 2009-10-01 14:03:53 UTC (rev 17607)
+++ beanvalidation/tck/trunk/src/main/docbook/en-US/Book_Info.xml 2009-10-01 14:07:23 UTC (rev 17608)
@@ -12,30 +12,38 @@
See the License for the specific language governing permissions and
limitations under the License.</literallayout></releaseinfo>
- <title>Technology Compatibility Kit Reference Guide for JSR-303: Bean Validation</title>
+ <title>Technology Compatibility Kit Reference Guide for JSR-303: Bean
+ Validation</title>
<subtitle>Specification Lead: Red Hat Inc.</subtitle>
<copyright>
<year>2009</year>
- <holder>Red Hat Middleware, LCC.</holder>
+ <holder>Red Hat, Inc.</holder>
</copyright>
<authorgroup>
<author>
<firstname>Emmanuel</firstname>
+
<surname>Bernard</surname>
+
<affiliation>
<jobtitle>JSR-303: Bean Validation specification lead</jobtitle>
+
<orgname>Red Hat Inc.</orgname>
</affiliation>
</author>
+
<author>
<firstname>Hardy</firstname>
+
<surname>Ferentschik</surname>
+
<affiliation>
<jobtitle>Bean Validation TCK Developer</jobtitle>
+
<orgname>Red Hat Inc.</orgname>
</affiliation>
</author>
14 years, 7 months
- 1
- 0
Hibernate SVN: r17607 - in beanvalidation/tck/trunk/src/main/docbook/en-US: harness and 1 other directory.
by hibernate-commits＠lists.jboss.org
Author: hardy.ferentschik
Date: 2009-10-01 10:03:53 -0400 (Thu, 01 Oct 2009)
New Revision: 17607
Modified:
beanvalidation/tck/trunk/src/main/docbook/en-US/executing.xml
beanvalidation/tck/trunk/src/main/docbook/en-US/harness/introduction.xml
beanvalidation/tck/trunk/src/main/docbook/en-US/installation.xml
beanvalidation/tck/trunk/src/main/docbook/en-US/introduction.xml
Log:
tck docs
Modified: beanvalidation/tck/trunk/src/main/docbook/en-US/executing.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/docbook/en-US/executing.xml 2009-10-01 13:08:50 UTC (rev 17606)
+++ beanvalidation/tck/trunk/src/main/docbook/en-US/executing.xml 2009-10-01 14:03:53 UTC (rev 17607)
@@ -21,7 +21,17 @@
JBoss AS 5.1. To execute the Bean Validation TCK on your own Bean
Validation implementation, you could modify the TCK runner project
included with Hibernate Validator to use your Bean Validation
- implementation as described in <xref linkend="configuration" />.</para>
+ implementation as described in <xref linkend="configuration" />. </para>
+
+ <note>
+ <para>For the Bean Validation TCK to run the system property
+ <property>validation.provider</property> has to be specified as system
+ property. The value has to be the fully specified class name of the
+ <classname>ValidationProvider</classname> of your Bean Validation
+ Implementation. In the case of Hibernate Validator this is
+ <classname>org.hibernate.validator.HibernateValidator</classname>. This
+ applies for standalone as well as in-container mode.</para>
+ </note>
</section>
<section>
Modified: beanvalidation/tck/trunk/src/main/docbook/en-US/harness/introduction.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/docbook/en-US/harness/introduction.xml 2009-10-01 13:08:50 UTC (rev 17606)
+++ beanvalidation/tck/trunk/src/main/docbook/en-US/harness/introduction.xml 2009-10-01 14:03:53 UTC (rev 17607)
@@ -2,7 +2,7 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
<chapter id="test-harness-introduction">
- <title>Introduction (JBoss Test Harness)</title>
+ <title>Introduction</title>
<para>This chapter explains the purpose of the test harness and describes
its key features.</para>
@@ -132,7 +132,8 @@
same test objects and tests.</para>
<section id="in-container-communication">
- <title>Negotiating the execution of an in-container test</title>
+ <title id="incontainer-communication">Negotiating the execution of an
+ in-container test</title>
<para>The basic procedure of an in-container test is as follows. The JBoss
Test Harness produces a deployable artifact from an
Modified: beanvalidation/tck/trunk/src/main/docbook/en-US/installation.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/docbook/en-US/installation.xml 2009-10-01 13:08:50 UTC (rev 17606)
+++ beanvalidation/tck/trunk/src/main/docbook/en-US/installation.xml 2009-10-01 14:03:53 UTC (rev 17607)
@@ -19,7 +19,7 @@
report), the TCK library dependencies in <code>/lib</code> and
documentation in <code>/doc</code>.</para>
- <para>You can also download the currnet source code from <ulink
+ <para>You can also download the current source code from <ulink
url="http://anonsvn.jboss.org/repos/hibernate/beanvalidation/tck/trunk/">JBoss
SVN repository</ulink>.</para>
Modified: beanvalidation/tck/trunk/src/main/docbook/en-US/introduction.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/docbook/en-US/introduction.xml 2009-10-01 13:08:50 UTC (rev 17606)
+++ beanvalidation/tck/trunk/src/main/docbook/en-US/introduction.xml 2009-10-01 14:03:53 UTC (rev 17607)
@@ -131,9 +131,9 @@
<listitem>
<para><emphasis role="bold">JBoss Test Harness</emphasis> - The Bean
Validation TCK requires version 1.0.0 of the JBoss Test Harness. The
- Harness is based on TestNG 5.x (<ulink
- url="http://testng.org">http://testng.org</ulink>). You can read
- more about the harness in <xref linkend="test-harness" />.</para>
+ Harness is based on <ulink url="http://testng.org">TestNG
+ 5.x</ulink>. You can read more about the harness in <xref
+ linkend="test-harness" />.</para>
</listitem>
<listitem>
@@ -148,8 +148,8 @@
designated reference runtimes for compatibility testing of the Bean
Validation specification is the Sun Java Platform, Enterprise
Edition (Java EE) 6 reference implementation (RI). See details at
- Java EE 6 (<ulink
- url="http://java.sun.com/javaee/6/docs/api/">http://java.sun.com/javaee/6/docs/api/</ulink>).</para>
+ <ulink url="http://java.sun.com/javaee/6/docs/api/">Java EE
+ 6</ulink></para>
</listitem>
</itemizedlist>
</section>
14 years, 7 months
- 1
- 0
Hibernate SVN: r17606 - beanvalidation/tck/trunk/src/main/docbook/en-US/harness.
by hibernate-commits＠lists.jboss.org
Author: hardy.ferentschik
Date: 2009-10-01 09:08:50 -0400 (Thu, 01 Oct 2009)
New Revision: 17606
Modified:
beanvalidation/tck/trunk/src/main/docbook/en-US/harness/executing.xml
beanvalidation/tck/trunk/src/main/docbook/en-US/harness/introduction.xml
Log:
tck docs
Modified: beanvalidation/tck/trunk/src/main/docbook/en-US/harness/executing.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/docbook/en-US/harness/executing.xml 2009-10-01 12:25:36 UTC (rev 17605)
+++ beanvalidation/tck/trunk/src/main/docbook/en-US/harness/executing.xml 2009-10-01 13:08:50 UTC (rev 17606)
@@ -1,228 +1,214 @@
-<?xml version='1.0' encoding='UTF-8'?>
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]>
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
<chapter id="executing-test-harness">
- <title>Executing a Test Suite</title>
- <para>
- This chapter explains how to execute and debug a test suite built using
- the JBoss Test Harness.
- </para>
- <section id="test-suite-runner">
- <title>Building a test suite runner using Maven 2</title>
- <para>
- The test suite runner project is the magic that makes everything come
- together and allows you to execute the test suite. If you fully
- understand how the JBoss Test Harness functions, and have a good grasp
- on Maven 2, then it's not to difficult to understand how the test suite
- runner project works. Regardless of your background, this guide covers
- what you need to know to get up and running by studying the test suite
- runner used to run the CDI TCK against the CDI RI, Web Beans.
- </para>
- <para>
- The TCK runner for the Web Beans can be found in the jboss-tck-runner
- directory in the Web Beans distribution. The dependencies of the TCK
- runner project for Web Beans are listed in
- <xref linkend="tck-runner-dependencies" />.
- </para>
- <table frame="all" id="tck-runner-dependencies" title="CDI TCK Runner dependencies">
- <title>Web Beans JBoss TCK Runner Dependencies</title>
- <tgroup cols="3">
- <colspec colname="c1" />
- <colspec colname="c2" />
- <colspec colname="c3" />
- <thead>
- <row>
- <entry>Group ID</entry>
- <entry>Artifact ID</entry>
- <entry>Version</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>org.jboss.webbeans</entry>
- <entry>jsr299-api</entry>
- <entry>1.0.0-SNAPSHOT</entry>
- </row>
- <row>
- <entry>org.jboss.jsr299.tck</entry>
- <entry>jsr299-tck-api</entry>
- <entry>1.0.0-SNAPSHOT</entry>
- </row>
- <row>
- <entry>org.jboss.jsr299.tck</entry>
- <entry>jsr299-tck-impl</entry>
- <entry>1.0.0-SNAPSHOT</entry>
- </row>
- <row>
- <entry>org.jboss.webbeans</entry>
- <entry>webbeans-core</entry>
- <entry>1.0.0-SNAPSHOT</entry>
- </row>
- <row>
- <entry>org.jboss.webbeans</entry>
- <entry>webbeans-porting-package</entry>
- <entry>1.0.0-SNAPSHOT</entry>
- </row>
- <row>
- <entry>org.testng</entry>
- <entry>testng (classifier: jdk15)</entry>
- <entry>5.8</entry>
- </row>
- <row>
- <entry>org.jboss.test-harness</entry>
- <entry>jboss-test-harness-jboss-as-51</entry>
- <entry>1.0.0.BETA3</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
- <para>
- You can find all of these artifacts in the <ulink
- url="http://repository.jboss.org/maven2">JBoss Maven
- repository</ulink>.
- </para>
- <para>
- You should substituate the webbeans-core and webbeans-porting-package
- artifacts from table 2.2.3 with your own artifacts. You'll also need to
- replace the jboss-test-harness-jboss-as-51 artifact if you are not
- testing your implementation on JBoss AS 5.1. The
- jboss-test-harness-jboss-as-51 artifact contains implementations of the
- <literal>Containers</literal>
- SPI for the JBoss Test Harness for JBoss AS 5.1.
- </para>
- <note>
- <para>
- When running the test suite in the in-container mode, the tests
- will run against libraries installed into the container. In this
- project, Web Beans is only declared as a Maven dependency for when
- the TCK test suite is being executed in standalone mode.
- </para>
- </note>
+ <title>Executing a Test Suite</title>
- <programlisting role="xml"><![CDATA[<plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-dependency-plugin</artifactId>
- <executions>
- <execution>
- <id>copy</id>
- <phase>process-resources</phase>
- <goals>
- <goal>copy</goal>
- </goals>
- <configuration>
- <stripVersion>true</stripVersion>
- <artifactItems>
- <artifactItem>
- <groupId>org.jboss.jsr299.tck</groupId>
- <artifactId>jsr299-tck-impl</artifactId>
- <type>xml</type>
- <classifier>suite</classifier>
- <overWrite>true</overWrite>
- </artifactItem>
- <artifactItem>
- <groupId>org.jboss.webbeans</groupId>
- <artifactId>
- webbeans-porting-package
- </artifactId>
- <overWrite>true</overWrite>
- <outputDirectory>
- ${project.build.directory}/dependency/lib
- </outputDirectory>
- </artifactItem>
- <artifactItem>
- <groupId>org.jboss.webbeans</groupId>
- <artifactId>webbeans-core-test</artifactId>
- <overWrite>true</overWrite>
- <outputDirectory>
- ${project.build.directory}/dependency/lib
- </outputDirectory>
- </artifactItem>
- <artifactItem>
- <groupId>javax.el</groupId>
- <artifactId>el-ri</artifactId>
- <overWrite>true</overWrite>
- <outputDirectory>
- ${project.build.directory}/dependency/lib
- </outputDirectory>
- </artifactItem>
- </artifactItems>
- </configuration>
- </execution>
- </executions>
-</plugin>]]></programlisting>
- <para>
- The target folder for the copies of the dependencies (i.e., the JAR
- files) is declared as the JBoss Test Harness library directory; this
- results in these libraries being added to the test artifact using the
- following property assignment:
- </para>
- <programlisting>org.jboss.testharness.libraryDirectory=target/dependency/lib</programlisting>
- <para>
- We also copy the test suite configuration from the
- local Maven
- repository (groupId=org.jboss.jsr299.tck,
- artifactId=jsr299-tck-impl,
- classifier=suite, type=xml,
- version=1.0.0-SNAPSHOT) to a local
- repository as the TestNG Maven
- plugin expects a local file.
- </para>
- <para>
- The TCK is executed using the Maven TestNG plugin. Maven 2 profiles are
- used to control the properties that are set at the time of the
- execution. For instance, the
- <literal>incontainer</literal>
- profile enables integration tests and disables standalone mode,
- changing the default settings.
- </para>
- <para>
- The jboss-tck-runner project also defines the JBoss Test Harness
- extra configuration directory using the following property:
- </para>
- <programlisting>org.jboss.testharness.container.extraConfigurationDir=../jboss-as</programlisting>
- <para>
- The JBoss Test Harness looks in this directory for either a
- build.properties or local.build.properties file that declares
- additional configuration properties. In particular, the JBoss AS
- Containers implementation looks here to find the
- <literal>jboss.home</literal> property so it knows where the scripts
- are located to start and stop JBoss AS.
- </para>
- </section>
+ <para>This chapter explains how to execute and debug a test suite built
+ using the JBoss Test Harness.</para>
- <section id="dumping-test-artifacts">
- <title>Dumping the Test Artifacts to Disk</title>
- <para>
- As you have learned, when the test suite is executing using
- in-container mode, each test class is packaged as a deployable artifact
- and deployed to the container. The test is then executed within the
- context of the deployed application. This leaves room for errors in
- packaging. When investigating a test failure, it's helpful to be able
- to inspect the artifact after it is generated. The JBoss Test Harness
- can accommodate this type of inspection by "dumping" the generated
- artifact to disk.
- </para>
- <para>
- If you want to write the artifacts to disk, and avoid executing the
- test suite, you can simply execute the main method of the class
- <literal>org.jboss.testharness.api.TCK</literal>.
- For example you could use a Maven profile that is activated when the
- <literal>dumpArtifacts</literal>
- command line property is defined:
- </para>
- <programlisting>mvn test-compile -DdumpArtifacts</programlisting>
- <para>
- The output directory where the artifacts are written is defined by the
- property
- <literal>org.jboss.testharness.outputDirectory</literal>.
- </para>
- <para>
- Once the artifact is written to disk, you have an option of manually
- deploying it to the container. You can execute the tests in the artfact
- by requesting the context path of the application in the browser. If
- you want to execute an individual test method, specify the method name
- in the
- <literal>methodName</literal>
- request parameter (e.g., ?methodName=testMethodName).
- </para>
- </section>
+ <section id="test-suite-runner">
+ <title>Building a test suite runner using Maven 2</title>
+
+ <para>The test suite runner project is the magic that makes everything
+ come together and allows you to execute the test suite. If you fully
+ understand how the JBoss Test Harness functions, and have a good grasp on
+ Maven 2, then it's not to difficult to understand how the test suite
+ runner project works. Regardless of your background, this guide covers
+ what you need to know to get up and running by studying the test suite
+ runner used to run the Bean Validation TCK against the Bean Validation RI,
+ Hibernate Validator.</para>
+
+ <para>The TCK runner for the Hibernate Validator can be found in the
+ <filename>hibernate-validator-tck-runner</filename> directory in the
+ Hibernate Validator checkout. The dependencies of the TCK runner project
+ for Hibernate Validator are listed in <xref
+ linkend="tck-runner-dependencies" />.</para>
+
+ <table frame="all" id="tck-runner-dependencies"
+ title="CDI TCK Runner dependencies">
+ <title>Web Beans JBoss TCK Runner Dependencies</title>
+
+ <tgroup cols="3">
+ <colspec colname="c1" />
+
+ <colspec colname="c2" />
+
+ <colspec colname="c3" />
+
+ <thead>
+ <row>
+ <entry>Group ID</entry>
+
+ <entry>Artifact ID</entry>
+
+ <entry>Version</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry>javax.validation</entry>
+
+ <entry>validation-api</entry>
+
+ <entry>1.0.0.GA</entry>
+ </row>
+
+ <row>
+ <entry>org.hibernate</entry>
+
+ <entry>hibernate-validator</entry>
+
+ <entry>4.0.0.GA</entry>
+ </row>
+
+ <row>
+ <entry>org.hibernate.jsr303.tck</entry>
+
+ <entry>jsr303-tck</entry>
+
+ <entry>1.0.0.GA</entry>
+ </row>
+
+ <row>
+ <entry>org.sl4j</entry>
+
+ <entry>slf4j-log4j12</entry>
+
+ <entry>1.5.6</entry>
+ </row>
+
+ <row>
+ <entry>org.testng</entry>
+
+ <entry>testng (classifier: jdk15)</entry>
+
+ <entry>5.8</entry>
+ </row>
+
+ <row>
+ <entry>org.jboss.test-harness</entry>
+
+ <entry>jboss-test-harness-jboss-as-51</entry>
+
+ <entry>1.0.0</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>You can find all of these artifacts in the <ulink
+ url="http://repository.jboss.org/maven2">JBoss Maven
+ repository</ulink>.</para>
+
+ <para>You should substituate the hibernate-validator artifact from <xref
+ linkend="tck-runner-dependencies" /> with your own artifact. You'll also
+ need to replace the jboss-test-harness-jboss-as-51 artifact if you are not
+ testing your implementation on JBoss AS 5.1. The
+ jboss-test-harness-jboss-as-51 artifact contains implementations of the
+ <literal>Containers</literal> SPI for the JBoss Test Harness for JBoss AS
+ 5.1.</para>
+
+ <note>
+ <para>When running the test suite in the in-container mode, the tests
+ will run against libraries installed into the container. In this
+ project, Hibernate Validator is only declared as a Maven dependency for
+ when the TCK test suite is being executed in standalone mode.</para>
+ </note>
+
+ <programlisting role="xml"><plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-dependency-plugin</artifactId>
+ <executions>
+ <execution>
+ <id>copy</id>
+ <phase>generate-test-sources</phase>
+ <goals>
+ <goal>copy</goal>
+ </goals>
+ <configuration>
+ <stripVersion>true</stripVersion>
+ <artifactItems>
+ <artifactItem>
+ <groupId>org.hibernate.jsr303.tck</groupId>
+ <artifactId>jsr303-tck</artifactId>
+ <type>xml</type>
+ <classifier>suite</classifier>
+ <overWrite>false</overWrite>
+ </artifactItem>
+ <artifactItem>
+ <groupId>javax.validation</groupId>
+ <artifactId>validation-api</artifactId>
+ <overWrite>true</overWrite>
+ <outputDirectory>${project.build.directory}/dependency/lib</outputDirectory>
+ </artifactItem>
+ <artifactItem>
+ <groupId>org.hibernate</groupId>
+ <artifactId>hibernate-validator</artifactId>
+ <overWrite>true</overWrite>
+ <outputDirectory>${project.build.directory}/dependency/lib</outputDirectory>
+ </artifactItem>
+ <artifactItem>
+ <groupId>org.slf4j</groupId>
+ <artifactId>slf4j-log4j12</artifactId>
+ <overWrite>true</overWrite>
+ <outputDirectory>${project.build.directory}/dependency/lib</outputDirectory>
+ </artifactItem>
+ </artifactItems>
+ </configuration>
+ </execution>
+ </executions>
+</plugin></programlisting>
+
+ <para>The target folder for the copies of the dependencies (i.e., the JAR
+ files) is declared as the JBoss Test Harness library directory; this
+ results in these libraries being added to the test artifact using the
+ following property assignment:</para>
+
+ <programlisting>org.jboss.testharness.libraryDirectory=target/dependency/lib</programlisting>
+
+ <para>We also copy the test suite configuration from the local Maven
+ repository (groupId=org.hibernate.jsr303.tck, artifactId=jsr303-tck,
+ classifier=suite, type=xml, version=1.0.0) to a local repository as the
+ TestNG Maven plugin expects a local file.</para>
+
+ <para>The TCK is executed using the Maven TestNG plugin. Maven 2 profiles
+ are used to control the properties that are set at the time of the
+ execution. For instance, the <literal>incontainer</literal> profile
+ enables integration tests and disables standalone mode, changing the
+ default settings.</para>
+ </section>
+
+ <section id="dumping-test-artifacts">
+ <title>Dumping the Test Artifacts to Disk</title>
+
+ <para>As you have learned, when the test suite is executing using
+ in-container mode, each test class is packaged as a deployable artifact
+ and deployed to the container. The test is then executed within the
+ context of the deployed application. This leaves room for errors in
+ packaging. When investigating a test failure, it's helpful to be able to
+ inspect the artifact after it is generated. The JBoss Test Harness can
+ accommodate this type of inspection by "dumping" the generated artifact to
+ disk.</para>
+
+ <para>If you want to write the artifacts to disk, and avoid executing the
+ test suite, you can simply execute the main method of the class
+ <literal>org.jboss.testharness.api.TCK</literal>. For example you could
+ use a Maven profile that is activated when the
+ <literal>dumpArtifacts</literal> command line property is defined:</para>
+
+ <programlisting>mvn test-compile -DdumpArtifacts</programlisting>
+
+ <para>The output directory where the artifacts are written is defined by
+ the property
+ <literal>org.jboss.testharness.outputDirectory</literal>.</para>
+
+ <para>Once the artifact is written to disk, you have an option of manually
+ deploying it to the container. You can execute the tests in the artfact by
+ requesting the context path of the application in the browser. If you want
+ to execute an individual test method, specify the method name in the
+ <literal>methodName</literal> request parameter (e.g.,
+ ?methodName=testMethodName).</para>
+ </section>
</chapter>
Modified: beanvalidation/tck/trunk/src/main/docbook/en-US/harness/introduction.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/docbook/en-US/harness/introduction.xml 2009-10-01 12:25:36 UTC (rev 17605)
+++ beanvalidation/tck/trunk/src/main/docbook/en-US/harness/introduction.xml 2009-10-01 13:08:50 UTC (rev 17606)
@@ -1,286 +1,226 @@
-<?xml version='1.0' encoding='UTF-8'?>
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]>
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
<chapter id="test-harness-introduction">
- <title>Introduction (JBoss Test Harness)</title>
+ <title>Introduction (JBoss Test Harness)</title>
- <para>
- This chapter explains the purpose of the test harness and describes
- its key features.
- </para>
- <para>
- The JBoss Test Harness is a testing framework based on TestNG that
- provides a series of extensions that allow runtime packaging and
- deployment of Java EE artifacts (EAR or WAR) for in-container testing.
- It's important to note that the JBoss Test Harness has no relation with,
- or dependency on, the JBoss Application Server (JBoss AS).
- </para>
- <note>
- <para>
- You'll often see the term
- <emphasis role="italic">in-container</emphasis>
- used in this reference guide. This term refers to running the test
- suite in any of the aforementioned environments, whilst
- <emphasis role="italic">standalone</emphasis>
- refers to running the tests outside the container via an
- implementation-specific standalone bootstrap. The standalone mode only
- runs those tests which the CDI RI can run without deployment in a Java
- EE container.
- </para>
- </note>
- <para>
- The last thing Java developers want is yet another testing framework to
- make their life more complicated. That's why the JBoss Test Harness is
- built entirely upon TestNG. TestNG is one of two prominent test
- frameworks for Java (the other being JUnit). Furthermore, what developers
- want is a good integration with their Integrated Development Environment
- (IDE). These days, if a tool doesn't have an IDE plugin, then it won't
- get the attention it deserves. TestNG plugins are available for all major
- IDEs and build tools (Ant and Maven 2). Again, a motivating factor for
- extending TestNG.
- </para>
- <para>
- Because it leverages the existing TestNG ecosystem, there is no need for
- a special test launcher for the JBoss Test Harness. You simply use the
- IDE or build tool of your choice (so long as it has TestNG support). You
- also get reporting and debugging for free (various reporting plugins are
- provided for TestNG).
- </para>
- <para>
- You can read more about TestNG at
- <ulink url="http://testng.org/doc/documentation-main.html">testng.org</ulink>.
- </para>
- <para>
- The JBoss Test Harness supports the following features:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- Test activation via any method supported by the TestNG
- configuration descriptor (package, group, class)
- </para>
- </listitem>
- <listitem>
- <para>
- Exclusion of in-container tests in standalone mode
- </para>
- </listitem>
- <listitem>
- <para>
- Exclusion of individual tests labeled as under investigation
- </para>
- </listitem>
- <listitem>
- <para>
- Integration with any TestNG plugin (Eclipse, IntelliJ, Ant, Maven)
- </para>
- </listitem>
- <listitem>
- <para>
- Automated reporting capability as provided by TestNG
- </para>
- </listitem>
- <listitem>
- <para>
- Standalone and in-container test mode
- </para>
- </listitem>
- <listitem>
- <para>
- Container pluggability
- </para>
- </listitem>
- <listitem>
- <para>
- Declarative packaging of additional resources and classes in
- artifact
- </para>
- </listitem>
- <listitem>
- <para>
- Declarative deployment exception trapping
- </para>
- </listitem>
- <listitem>
- <para>
- Artifact dumping for failure and packaging analysis
- </para>
- </listitem>
- </itemizedlist>
- <para>
- A test is designated by a method annotated with
- <literal>@org.testng.annotations.Test</literal>
- in a class which extends
- <literal>org.jboss.testharness.AbstractTest</literal>
- and is annotated with
- <literal>@org.jboss.testharness.impl.packaging.Artifact</literal>.
- </para>
- <note>
- <para>
- Test suites may often choose to extend <literal>AbstractTest</literal>
- and require tests to extend that base class. In fact, both the CDI TCK
- and the Bean Validation TCK provide base classes that extend
- <literal>AbstractTest</literal> to provide functionality specific to
- the needs of the TCK.
- </para>
- </note>
- <para>
- The
- <literal>@Test</literal>
- annotation is provided by TestNG, the
- <literal>@Artifact</literal>
- annotation is provided by the JBoss Test Harness and the
- <literal>AbstractTest</literal>
- is part of the JBoss Test Harness. There is a one-to-one mapping between a
- TestNG test class and an artifact. The packaging type is defined by the
- <literal>@org.jboss.testharness.impl.packaging.Packaging</literal>
- annotation on the test class, defaulting to a WAR if not specified.
- </para>
- <para>
- Prior to executing the tests for a given class, the JBoss Test Harness
- packages the class as a deployable artifact (EAR or WAR), along with any
- extra resources specified, and deploys the artifact to the container. The
- harness provides test execution and result reporting via HTTP
- communication to a simple Servlet using a thin layer over the TestNG test
- launcher. The test harness can also catch and enforce expected deployment
- exceptions. This setup and tear down activity is provided by the super
- class
- <literal>org.jboss.testharness.AbstractTest</literal>,
- which all test classes must extend (directly or indirectly).
- </para>
- <para>
- If the annotation
- <literal>@org.jboss.testharness.impl.packaging.IntegrationTest
- </literal>
- is not present on the test class, then it means the test class can be
- executed in standalone mode. In standalone mode, the deployable artifact
- is assembled on the local classpath and the tests execute in the same JVM
- as the launcher, just as though it were a regular TestNG test case. The
- standalone mode is provided for convenience and efficiency, allowing you
- the speed of mock-based testing and the confidence of an in-container test,
- using the same test objects and tests.
- </para>
-
- <section id="in-container-communication">
- <title>Negotiating the execution of an in-container test</title>
- <para>
- The basic procedure of an in-container test is as follows. The JBoss
- Test Harness produces a deployable artifact from an
- <literal>@Artifact</literal>
- test class and any declared dependent classes, descriptors or other
- resources. Then it deploys the artifact to the container using the
- <literal>Containers</literal>
- SPI, negotiates with the container to execute the test and return the
- result and, finally, undeploys the artifact. TestNG collects the results
- of all the tests run in the typical way and produces a report.
- </para>
- <graphic fileref="images/in-container-execution.png" align="center" />
- <para>
- The question is, how does the JBoss Test Harness negotiate with the
- container to execute the test when TestNG is being invoked locally?
- Technially the mechanism is pluggable, but JBoss Test Harness provides
- a default implementation that uses HTTP communication that you will
- likely use. Here's how the default implementation works.
- </para>
- <para>
- The artifact generator bundles and registers (in the web.xml
- descriptor) an
- <literal>HttpServlet</literal>,
- <literal>org.jboss.testharness.impl.runner.servlet.ServletTestRunner</literal>,
- that responds to test execution GET requests. TestNG running on the
- client side delegates to a test launcher (more on that in a moment)
- which originates these text execution requests to transfer control to
- the container JVM. The name of the test method to be executed is
- specified in a request query parameter named
- <literal>methodName</literal>.
- </para>
- <para>
- When the test execution request is received, the servlet delegates to
- an instance of
- <literal>org.jboss.testharness.impl.runner.TestRunner</literal>,
- passing it the name of the test method.
- <literal>TestRunner</literal>
- reads the name of the test class from the resource
- META-INF/jboss-test-harness.properties, which is bundled in the
- artifact by the artifact generator. It then combines the class name
- and the method name to produce a TestNG test suite and runs the suite
- (within the context of the container).
- </para>
- <para>
- TestNG returns the results of the run as an
- <literal>ITestResult</literal>
- object.
- <literal>ServletTestRunner</literal>
- translates this object into a
- <literal>org.jboss.testharness.api.TestResult</literal>
- and passes it back to the test launcher on the client side by encoding
- the translated object into the response. The object gets encoded as
- either html or a serialized object, depending on the value of the
- <literal>outputMode</literal>
- request parameter that was passed to the servlet. Once the result has
- been transfered to the client-side TestNG, TestNG wraps up the run of
- the test as though it had been executed in the same JVM.
- </para>
- <para>
- There's one piece missing. How does TestNG on the client side know to
- submit a request to the
- <literal>ServletTestRunner</literal>
- servlet to get TestNG to execute the test in the container JVM? That's
- the role of the test launcher.
- </para>
- <para>
- The test launcher is the API that allows test suite to launch the test
- in a pluggable fashion.
- <literal>AbstractTest</literal>,
- the super class of
- <literal>AbtractJSR299Test</literal>,
- implements
- <literal>IHookable</literal>,
- a TestNG interface which allows the execution of the test method to
- be intercepted. Using that mechanism, <literal>AbstractTest</literal> delegates execution
- of the test method (a method annotated with
- <literal>@Test</literal>
- in an
- <literal>@Artifact</literal>
- class) to an implementation of
- <literal>org.jboss.testharness.api.TestLauncher</literal>
- if the tests are being executed in-container. As you might anticipate,
- the implementation is specified using a property with the same name as
- the interface in a META-INF/jboss-test-launcher.properties resource.
- The JBoss Test Harness provides a default implementation,
- <literal>org.jboss.testharness.impl.runner.servlet.ServletTestLauncher</literal>,
- that hooks into the HTTP communication infrastructure described
- above. It invokes the
- <literal>ServletTestRunner</literal>
- servlet for each method annotated with
- <literal>@Test</literal>
- in the
- <literal>@Artifact</literal>
- that is not otherwise disabled.
- </para>
- <para>
- If you wish to implement the runner yourself, you must return a
- <literal>TestResult</literal> as a result of executing the method in
- the container. You must also ensure that any exception which occurs
- during deployment is wrapped as a
- <literal>org.jboss.testharness.api.DeploymentException</literal>, and
- that any communication problem is rethrown as an
- <literal>IOException</literal>. The deployment exception may be
- transformed by an implementation of the
- <literal>org.jboss.testharness.api.DeploymentExceptionTransformer
- </literal> interface, which is specified using the
- <literal>org.jboss.testharness.container.deploymentExceptionTransformer
- </literal> property. The default implementation passes on the original
- exception unchanged. The implementation for JBoss AS used with the CDI
- TCK, on the other hand, deciphers the exception thrown by the JBoss
- deployer and converts it to one of the catagory exceptions defined in
- the CDI TCK API.
- </para>
- <para>
- So in short, JBoss Test Harness takes care of all the interfaces you
- need to execute tests in-container except for the implementation of
- the <literal>Containers</literal> SPI. That is, unless you are
- deploying to one of the containers supported by the JBoss Test Harness
- (TODO we need a table showing supported containers).
- </para>
- </section>
+ <para>This chapter explains the purpose of the test harness and describes
+ its key features.</para>
+
+ <para>The JBoss Test Harness is a testing framework based on TestNG that
+ provides a series of extensions that allow runtime packaging and deployment
+ of Java EE artifacts (EAR or WAR) for in-container testing. It's important
+ to note that the JBoss Test Harness has no relation with, or dependency on,
+ the JBoss Application Server (JBoss AS).</para>
+
+ <note>
+ <para>You'll often see the term <emphasis
+ role="italic">in-container</emphasis> used in this reference guide. This
+ term refers to running the test suite in any of the aforementioned
+ environments, whilst <emphasis role="italic">standalone</emphasis> refers
+ to running the tests outside the container via an implementation-specific
+ standalone bootstrap. The standalone mode only runs those tests which the
+ Bean Validation RI can run without deployment in a Java EE
+ container.</para>
+ </note>
+
+ <para>The last thing Java developers want is yet another testing framework
+ to make their life more complicated. That's why the JBoss Test Harness is
+ built entirely upon TestNG. TestNG is one of two prominent test frameworks
+ for Java (the other being JUnit). Furthermore, what developers want is a
+ good integration with their Integrated Development Environment (IDE). These
+ days, if a tool doesn't have an IDE plugin, then it won't get the attention
+ it deserves. TestNG plugins are available for all major IDEs and build tools
+ (Ant and Maven 2). Again, a motivating factor for extending TestNG.</para>
+
+ <para>Because it leverages the existing TestNG ecosystem, there is no need
+ for a special test launcher for the JBoss Test Harness. You simply use the
+ IDE or build tool of your choice (so long as it has TestNG support). You
+ also get reporting and debugging for free (various reporting plugins are
+ provided for TestNG).</para>
+
+ <para>You can read more about TestNG at <ulink
+ url="http://testng.org/doc/documentation-main.html">testng.org</ulink>.</para>
+
+ <para>The JBoss Test Harness supports the following features:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>Test activation via any method supported by the TestNG
+ configuration descriptor (package, group, class)</para>
+ </listitem>
+
+ <listitem>
+ <para>Exclusion of in-container tests in standalone mode</para>
+ </listitem>
+
+ <listitem>
+ <para>Exclusion of individual tests labeled as under
+ investigation</para>
+ </listitem>
+
+ <listitem>
+ <para>Integration with any TestNG plugin (Eclipse, IntelliJ, Ant,
+ Maven)</para>
+ </listitem>
+
+ <listitem>
+ <para>Automated reporting capability as provided by TestNG</para>
+ </listitem>
+
+ <listitem>
+ <para>Standalone and in-container test mode</para>
+ </listitem>
+
+ <listitem>
+ <para>Container pluggability</para>
+ </listitem>
+
+ <listitem>
+ <para>Declarative packaging of additional resources and classes in
+ artifact</para>
+ </listitem>
+
+ <listitem>
+ <para>Declarative deployment exception trapping</para>
+ </listitem>
+
+ <listitem>
+ <para>Artifact dumping for failure and packaging analysis</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>A test is designated by a method annotated with
+ <literal>@org.testng.annotations.Test</literal> in a class which extends
+ <literal>org.jboss.testharness.AbstractTest</literal> and is annotated with
+ <literal>@org.jboss.testharness.impl.packaging.Artifact</literal>.</para>
+
+ <note>
+ <para>Test suites may often choose to extend
+ <literal>AbstractTest</literal> and require tests to extend that base
+ class. In fact, both the CDI TCK and the Bean Validation TCK provide base
+ classes that extend <literal>AbstractTest</literal> to provide
+ functionality specific to the needs of the TCK.</para>
+ </note>
+
+ <para>The <literal>@Test</literal> annotation is provided by TestNG, the
+ <literal>@Artifact</literal> annotation is provided by the JBoss Test
+ Harness and the <literal>AbstractTest</literal> is part of the JBoss Test
+ Harness. There is a one-to-one mapping between a TestNG test class and an
+ artifact. The packaging type is defined by the
+ <literal>@org.jboss.testharness.impl.packaging.Packaging</literal>
+ annotation on the test class, defaulting to a WAR if not specified.</para>
+
+ <para>Prior to executing the tests for a given class, the JBoss Test Harness
+ packages the class as a deployable artifact (EAR or WAR), along with any
+ extra resources specified, and deploys the artifact to the container. The
+ harness provides test execution and result reporting via HTTP communication
+ to a simple Servlet using a thin layer over the TestNG test launcher. The
+ test harness can also catch and enforce expected deployment exceptions. This
+ setup and tear down activity is provided by the super class
+ <literal>org.jboss.testharness.AbstractTest</literal>, which all test
+ classes must extend (directly or indirectly).</para>
+
+ <para>If the annotation
+ <literal>@org.jboss.testharness.impl.packaging.IntegrationTest </literal> is
+ not present on the test class, then it means the test class can be executed
+ in standalone mode. In standalone mode, the deployable artifact is assembled
+ on the local classpath and the tests execute in the same JVM as the
+ launcher, just as though it were a regular TestNG test case. The standalone
+ mode is provided for convenience and efficiency, allowing you the speed of
+ mock-based testing and the confidence of an in-container test, using the
+ same test objects and tests.</para>
+
+ <section id="in-container-communication">
+ <title>Negotiating the execution of an in-container test</title>
+
+ <para>The basic procedure of an in-container test is as follows. The JBoss
+ Test Harness produces a deployable artifact from an
+ <literal>@Artifact</literal> test class and any declared dependent
+ classes, descriptors or other resources. Then it deploys the artifact to
+ the container using the <literal>Containers</literal> SPI, negotiates with
+ the container to execute the test and return the result and, finally,
+ undeploys the artifact. TestNG collects the results of all the tests run
+ in the typical way and produces a report.</para>
+
+ <graphic align="center" fileref="images/in-container-execution.png" />
+
+ <para>The question is, how does the JBoss Test Harness negotiate with the
+ container to execute the test when TestNG is being invoked locally?
+ Technially the mechanism is pluggable, but JBoss Test Harness provides a
+ default implementation that uses HTTP communication that you will likely
+ use. Here's how the default implementation works.</para>
+
+ <para>The artifact generator bundles and registers (in the web.xml
+ descriptor) an <literal>HttpServlet</literal>,
+ <literal>org.jboss.testharness.impl.runner.servlet.ServletTestRunner</literal>,
+ that responds to test execution GET requests. TestNG running on the client
+ side delegates to a test launcher (more on that in a moment) which
+ originates these text execution requests to transfer control to the
+ container JVM. The name of the test method to be executed is specified in
+ a request query parameter named <literal>methodName</literal>.</para>
+
+ <para>When the test execution request is received, the servlet delegates
+ to an instance of
+ <literal>org.jboss.testharness.impl.runner.TestRunner</literal>, passing
+ it the name of the test method. <literal>TestRunner</literal> reads the
+ name of the test class from the resource
+ META-INF/jboss-test-harness.properties, which is bundled in the artifact
+ by the artifact generator. It then combines the class name and the method
+ name to produce a TestNG test suite and runs the suite (within the context
+ of the container).</para>
+
+ <para>TestNG returns the results of the run as an
+ <literal>ITestResult</literal> object.
+ <literal>ServletTestRunner</literal> translates this object into a
+ <literal>org.jboss.testharness.api.TestResult</literal> and passes it back
+ to the test launcher on the client side by encoding the translated object
+ into the response. The object gets encoded as either html or a serialized
+ object, depending on the value of the <literal>outputMode</literal>
+ request parameter that was passed to the servlet. Once the result has been
+ transfered to the client-side TestNG, TestNG wraps up the run of the test
+ as though it had been executed in the same JVM.</para>
+
+ <para>There's one piece missing. How does TestNG on the client side know
+ to submit a request to the <literal>ServletTestRunner</literal> servlet to
+ get TestNG to execute the test in the container JVM? That's the role of
+ the test launcher.</para>
+
+ <para>The test launcher is the API that allows test suite to launch the
+ test in a pluggable fashion. <literal>AbstractTest</literal> implements
+ <literal>IHookable</literal>, a TestNG interface which allows the
+ execution of the test method to be intercepted. Using that mechanism,
+ <literal>AbstractTest</literal> delegates execution of the test method (a
+ method annotated with <literal>@Test</literal> in an
+ <literal>@Artifact</literal> class) to an implementation of
+ <literal>org.jboss.testharness.api.TestLauncher</literal> if the tests are
+ being executed in-container. As you might anticipate, the implementation
+ is specified using a property with the same name as the interface in a
+ META-INF/jboss-test-launcher.properties resource. The JBoss Test Harness
+ provides a default implementation,
+ <literal>org.jboss.testharness.impl.runner.servlet.ServletTestLauncher</literal>,
+ that hooks into the HTTP communication infrastructure described above. It
+ invokes the <literal>ServletTestRunner</literal> servlet for each method
+ annotated with <literal>@Test</literal> in the
+ <literal>@Artifact</literal> that is not otherwise disabled.</para>
+
+ <para>If you wish to implement the runner yourself, you must return a
+ <literal>TestResult</literal> as a result of executing the method in the
+ container. You must also ensure that any exception which occurs during
+ deployment is wrapped as a
+ <literal>org.jboss.testharness.api.DeploymentException</literal>, and that
+ any communication problem is rethrown as an
+ <literal>IOException</literal>. The deployment exception may be
+ transformed by an implementation of the
+ <literal>org.jboss.testharness.api.DeploymentExceptionTransformer
+ </literal> interface, which is specified using the
+ <literal>org.jboss.testharness.container.deploymentExceptionTransformer
+ </literal> property. The default implementation passes on the original
+ exception unchanged. </para>
+
+ <para>So in short, JBoss Test Harness takes care of all the interfaces you
+ need to execute tests in-container except for the implementation of the
+ <literal>Containers</literal> SPI. That is, unless you are deploying to
+ one of the containers supported by the JBoss Test Harness.</para>
+ </section>
</chapter>
14 years, 7 months
- 1
- 0
Hibernate SVN: r17605 - in beanvalidation/tck/trunk: src/main/assembly and 1 other directories.
by hibernate-commits＠lists.jboss.org
Author: hardy.ferentschik
Date: 2009-10-01 08:25:36 -0400 (Thu, 01 Oct 2009)
New Revision: 17605
Removed:
beanvalidation/tck/trunk/src/main/docbook/en-US/eclipse-debugging.xml
beanvalidation/tck/trunk/src/main/docbook/en-US/eclipse-running.xml
beanvalidation/tck/trunk/src/main/docbook/en-US/images/
Modified:
beanvalidation/tck/trunk/pom.xml
beanvalidation/tck/trunk/src/main/assembly/assembly.xml
beanvalidation/tck/trunk/src/main/docbook/en-US/Author_Group.xml
beanvalidation/tck/trunk/src/main/docbook/en-US/Book_Info.xml
beanvalidation/tck/trunk/src/main/docbook/en-US/Book_Preface.xml
beanvalidation/tck/trunk/src/main/docbook/en-US/appeals-process.xml
beanvalidation/tck/trunk/src/main/docbook/en-US/configuration.xml
beanvalidation/tck/trunk/src/main/docbook/en-US/executing.xml
beanvalidation/tck/trunk/src/main/docbook/en-US/installation.xml
beanvalidation/tck/trunk/src/main/docbook/en-US/introduction.xml
beanvalidation/tck/trunk/src/main/docbook/en-US/part-execution.xml
beanvalidation/tck/trunk/src/main/docbook/en-US/part-test-harness.xml
beanvalidation/tck/trunk/src/main/docbook/en-US/reporting.xml
Log:
updated to the tck docs
Modified: beanvalidation/tck/trunk/pom.xml
===================================================================
--- beanvalidation/tck/trunk/pom.xml 2009-10-01 08:14:40 UTC (rev 17604)
+++ beanvalidation/tck/trunk/pom.xml 2009-10-01 12:25:36 UTC (rev 17605)
@@ -91,7 +91,6 @@
<sourceDirectory>${basedir}/src/main/docbook</sourceDirectory>
<masterTranslation>en-US</masterTranslation>
<imageResource>
- <directory>${basedir}/src/main/docbook/en-US/images</directory>
<directory>${basedir}/src/main/docbook/en-US/harness</directory>
</imageResource>
<formats>
Modified: beanvalidation/tck/trunk/src/main/assembly/assembly.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/assembly/assembly.xml 2009-10-01 08:14:40 UTC (rev 17604)
+++ beanvalidation/tck/trunk/src/main/assembly/assembly.xml 2009-10-01 12:25:36 UTC (rev 17605)
@@ -10,16 +10,28 @@
</formats>
<dependencySets>
<dependencySet>
- <useProjectArtifact>true</useProjectArtifact>
+ <useProjectArtifact>false</useProjectArtifact>
<outputDirectory>lib</outputDirectory>
<scope>runtime</scope>
- <excludes>
- <exclude>com.googlecode.jtype:jtype</exclude>
- </excludes>
</dependencySet>
</dependencySets>
<fileSets>
<fileSet>
+ <directory>target</directory>
+ <outputDirectory/>
+ <excludes>
+ <exclude>*-javadoc.jar</exclude>
+ <exclude>*-sources.jar</exclude>
+ </excludes>
+ <includes>
+ <include>jsr303-tck-*.jar</include>
+ </includes>
+ </fileSet>
+ <fileSet>
+ <directory>target/docbook/publish/en-US</directory>
+ <outputDirectory>docs/manual</outputDirectory>
+ </fileSet>
+ <fileSet>
<directory>${project.basedir}</directory>
<outputDirectory>src</outputDirectory>
<includes>
@@ -34,12 +46,19 @@
</fileSet>
<fileSet>
<directory>${project.basedir}/src/main/resources</directory>
- <outputDirectory>lib</outputDirectory>
+ <outputDirectory>/</outputDirectory>
<includes>
<include>tck-tests.xml</include>
</includes>
</fileSet>
<fileSet>
+ <directory>${project.basedir}/src/main/resources</directory>
+ <outputDirectory>/</outputDirectory>
+ <includes>
+ <include>tck-audit.xml</include>
+ </includes>
+ </fileSet>
+ <fileSet>
<directory>${project.basedir}/target</directory>
<outputDirectory>/</outputDirectory>
<includes>
Modified: beanvalidation/tck/trunk/src/main/docbook/en-US/Author_Group.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/docbook/en-US/Author_Group.xml 2009-10-01 08:14:40 UTC (rev 17604)
+++ beanvalidation/tck/trunk/src/main/docbook/en-US/Author_Group.xml 2009-10-01 12:25:36 UTC (rev 17605)
@@ -2,31 +2,19 @@
<!DOCTYPE authorgroup PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]>
<authorgroup>
<author>
- <firstname>Gavin</firstname>
- <surname>King</surname>
+ <firstname>Emmanuel</firstname>
+ <surname>Bernard</surname>
<affiliation>
- <jobtitle>JSR-299: Contexts and Dependency Injection (CDI) for Java EE
- specification lead</jobtitle>
+ <jobtitle>JSR-303: Bean Validation specification lead</jobtitle>
<orgname>Red Hat Inc.</orgname>
</affiliation>
</author>
<author>
- <firstname>Pete</firstname>
- <surname>Muir</surname>
+ <firstname>Hardy</firstname>
+ <surname>Ferentschik</surname>
<affiliation>
- <jobtitle>CDI TCK lead</jobtitle>
+ <jobtitle>Bean Validation TCK Developer</jobtitle>
<orgname>Red Hat Inc.</orgname>
</affiliation>
</author>
- <author>
- <firstname>Dan</firstname>
- <surname>Allen</surname>
- <affiliation>
- <jobtitle>CDI TCK developer</jobtitle>
- <orgname>Red Hat Inc.</orgname>
- </affiliation>
- </author>
-<!--
-vim: ts=3:sw=3:tw=80:set expandtab
--->
</authorgroup>
Modified: beanvalidation/tck/trunk/src/main/docbook/en-US/Book_Info.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/docbook/en-US/Book_Info.xml 2009-10-01 08:14:40 UTC (rev 17604)
+++ beanvalidation/tck/trunk/src/main/docbook/en-US/Book_Info.xml 2009-10-01 12:25:36 UTC (rev 17605)
@@ -12,18 +12,32 @@
See the License for the specific language governing permissions and
limitations under the License.</literallayout></releaseinfo>
- <title>Technology Compatibility Kit Reference Guide for JSR-303: Bean
- Validation</title>
+ <title>Technology Compatibility Kit Reference Guide for JSR-303: Bean Validation</title>
<subtitle>Specification Lead: Red Hat Inc.</subtitle>
<copyright>
- <year>2009 </year>
+ <year>2009</year>
<holder>Red Hat Middleware, LCC.</holder>
</copyright>
- <!--
-vim: ts=3:sw=3:tw=80:set expandtab
--->
+ <authorgroup>
+ <author>
+ <firstname>Emmanuel</firstname>
+ <surname>Bernard</surname>
+ <affiliation>
+ <jobtitle>JSR-303: Bean Validation specification lead</jobtitle>
+ <orgname>Red Hat Inc.</orgname>
+ </affiliation>
+ </author>
+ <author>
+ <firstname>Hardy</firstname>
+ <surname>Ferentschik</surname>
+ <affiliation>
+ <jobtitle>Bean Validation TCK Developer</jobtitle>
+ <orgname>Red Hat Inc.</orgname>
+ </affiliation>
+ </author>
+ </authorgroup>
</bookinfo>
Modified: beanvalidation/tck/trunk/src/main/docbook/en-US/Book_Preface.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/docbook/en-US/Book_Preface.xml 2009-10-01 08:14:40 UTC (rev 17604)
+++ beanvalidation/tck/trunk/src/main/docbook/en-US/Book_Preface.xml 2009-10-01 12:25:36 UTC (rev 17605)
@@ -6,7 +6,7 @@
<para>This guide describes how to download, install, configure, and run the
Technology Compatibility Kit (TCK) used to verify the compatibility of an
- implementation of the JSR-303: Bean Validation specification.</para>
+ implementation of JSR-303: Bean Validation specification.</para>
<para>The Bean Validation TCK is built atop the JBoss Test Harness, a
portable and configurable automated test suite for authoring unit and
@@ -18,7 +18,7 @@
2.0</ulink>.</para>
<section id="target-audience">
- <title>Who Should Use This Book</title>
+ <title>Who Should Use This Guide</title>
<para>This guide is for implementors of the Bean Validation specification
to assist in running the test suite that verifies the compatibility of
@@ -26,12 +26,12 @@
</section>
<section id="before-reading">
- <title>Before You Read This Book</title>
+ <title>Before You Read This Guide</title>
<para>The Bean Validation TCK is based on the Bean Validation
specification 1.0 (JSR-303). Information about the specification,
including links to the specification documents, can be found on the <ulink
- url="http://jcp.org/en/jsr/detail?id=299">JSR-303 JCP page</ulink>.</para>
+ url="http://jcp.org/en/jsr/detail?id=303">JSR-303 JCP page</ulink>.</para>
<para>Before running the tests in the Bean Validation TCK, read and become
familiar with the JBoss Test Harness Reference Guide (pending), which
@@ -39,7 +39,7 @@
</section>
<section id="book-organization">
- <title>How This Book Is Organized</title>
+ <title>How This Guide Is Organized</title>
<para>If you are running the Bean Validation TCK for the first time, read
<xref linkend="introduction" /> and <xref
@@ -94,18 +94,6 @@
</listitem>
<listitem>
- <para><xref linkend="eclipse-running" /> shows how to run individual
- tests in Eclipse and advises the best way to setup your Eclipse
- workspace for running the tests.</para>
- </listitem>
-
- <listitem>
- <para><xref linkend="eclipse-debugging" /> builds on <xref
- linkend="eclipse-running" /> by detailing how to debug individual
- tests in Eclipse.</para>
- </listitem>
-
- <listitem>
<para><xref linkend="test-harness" /> includes excerpts from the JBoss
Test Harness Reference Guide. How to configure the JBoss Test Harness
as it relates to the Bean Validation TCK is presented in <xref
Modified: beanvalidation/tck/trunk/src/main/docbook/en-US/appeals-process.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/docbook/en-US/appeals-process.xml 2009-10-01 08:14:40 UTC (rev 17604)
+++ beanvalidation/tck/trunk/src/main/docbook/en-US/appeals-process.xml 2009-10-01 12:25:36 UTC (rev 17605)
@@ -52,7 +52,7 @@
<title>How these challenges are submitted?</title>
<para>To submit a challenge, a new issue should be created in the <ulink
- url="https://jira.jboss.org/jira/browse/WBTCK">HV project</ulink> of the
+ url="https://jira.jboss.org/jira/browse/HV">HV project</ulink> of the
JBoss JIRA using the Issue Type: Bug. The appellant should complete the
Summary, Component (TCK Appeal), Environment and Description Field only.
Any communication regarding the issue should be pursed in the comments of
@@ -75,11 +75,11 @@
Validation TCK Project Lead, as designated by Specification Lead, Red Hat
Middleware LLC. or his/her designate. The appellant can also monitor the
process by following the issue report filed in the <ulink
- url="https://jira.jboss.org/jira/browse/WBTCK">HV project</ulink> of the
+ url="https://jira.jboss.org/jira/browse/HV">HV project</ulink> of the
JBoss JIRA.</para>
<para>The current TCK Project Lead is listed on the <ulink type=""
- url="https://jira.jboss.org/jira/browse/WBTCK" userlevel="">HV Project
+ url="https://jira.jboss.org/jira/browse/HV" userlevel="">HV Project
Summary Page</ulink> on the JBoss JIRA.</para>
</section>
Modified: beanvalidation/tck/trunk/src/main/docbook/en-US/configuration.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/docbook/en-US/configuration.xml 2009-10-01 08:14:40 UTC (rev 17604)
+++ beanvalidation/tck/trunk/src/main/docbook/en-US/configuration.xml 2009-10-01 12:25:36 UTC (rev 17605)
@@ -53,8 +53,7 @@
</literal></entry>
<entry>Directory containing extra JARs you want placed in artifact
- library directory such as the porting package
- implementation.</entry>
+ library directory.</entry>
</row>
<row>
@@ -94,14 +93,13 @@
<literal>org.jboss.testharness.spi.Containers</literal>, which handles
deploying the test artifact to the container. An implementations of this
API is already available for JBoss AS 5.1. Therefore, you only need to
- implement this part of the porting package if you wish to use another
- container.</para>
+ implement this if you wish to use another container.</para>
<note id="deployment-api-contributions">
- <para>Red Hat Middleware LLC encourages CDI implementators to contribute
- JBoss Test Harness Deployment API implementations for other containers
- under the ASL license. Please contact the Bean Validation TCK
- lead.</para>
+ <para>Red Hat Middleware LLC encourages Bean Validation implementators
+ to contribute JBoss Test Harness Deployment API implementations for
+ other containers under the ASL license. Please contact the Bean
+ Validation TCK lead.</para>
</note>
</section>
@@ -120,13 +118,13 @@
for an implementation to pass the TCK. This file also allows tests to be
excluded from a run:</para>
- <programlisting><suite name="JSR-299 TCK" verbose="2">
- <test name="JSR-299 TCK">
+ <programlisting><suite name="JSR-303 TCK" verbose="2">
+ <test name="JSR-303 TCK">
...
<classes>
- <class name="org.jboss.jsr299.tck.tests.context.application.ApplicationContextTest">
+ <class name="org.hibernate.jsr303.tck.tests.bootstrap.ValidationProviderTest">
<methods>
- <exclude name="testApplicationScopeActiveDuringServiceMethod"/>
+ <exclude name="testFirstMatchingValidationProviderResolverIsReturned"/>
</methods>
</class>
</classes>
@@ -145,8 +143,8 @@
<para>It's beyond the scope of this guide to describe in how to set up
your build environment to run the TCK. The JBoss Test Harness guide
- describes how Web Beans uses Maven 2 to execute the Bean Validation TCK.
- See <xref linkend="test-suite-runner" />. The TestNG documentation
+ describes how Bean Validation uses Maven 2 to execute the Bean Validation
+ TCK. See <xref linkend="test-suite-runner" />. The TestNG documentation
provides extensive information on launching TestNG using the Java, Ant,
Eclipse or IntellJ IDEA.</para>
</section>
Deleted: beanvalidation/tck/trunk/src/main/docbook/en-US/eclipse-debugging.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/docbook/en-US/eclipse-debugging.xml 2009-10-01 08:14:40 UTC (rev 17604)
+++ beanvalidation/tck/trunk/src/main/docbook/en-US/eclipse-debugging.xml 2009-10-01 12:25:36 UTC (rev 17605)
@@ -1,146 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]>
-<chapter id="eclipse-debugging">
- <title>Debugging Tests in Eclipse</title>
- <para>
- This chapter explains how to debug standalone and integration tests from
- the TCK test suite in Eclipse. You should be able to use the lessons
- learned here to debug tests in an alternate IDE as well.
- </para>
- <section>
- <title>Debugging a standalone test</title>
- <para>
- There is almost no difference in how you debug a standalone test
- from how you run it. With the test class open in the Eclipse editor,
- simply right click in the editor view and select Debug As > TestNG
- Test. Eclipse will stop at any breakpoints you set just like it would
- with any other local debug process.
- </para>
- <para>
- If you plan to step into a class in a Web Beans implementation (or any
- other dependent library), you must ensure that the source is properly
- associated with the library. Below are the steps to follow to associate
- the source of Web Beans with the TestNG debug configuration:
- </para>
- <orderedlist>
- <listitem>
- <para>
- Select the Run > Debug Configurations... menu from the main
- menubar
- </para>
- </listitem>
- <listitem>
- <para>
- Select the name of the test class in the TestNG category
- </para>
- </listitem>
- <listitem>
- <para>
- Select the Source tab
- </para>
- </listitem>
- <listitem>
- <para>
- Click the Add... button on the right
- </para>
- </listitem>
- <listitem>
- <para>
- Select Java Project
- </para>
- </listitem>
- <listitem>
- <para>
- Check the project the contains the class you want to debug
- (e.g., webbeans-core)
- </para>
- </listitem>
- <listitem>
- <para>
- Click OK on the Project Selection window
- </para>
- </listitem>
- <listitem>
- <para>
- Click Close on the Debug Configurations window
- </para>
- </listitem>
- </orderedlist>
- <para>
- You'll have to complete those steps for any test class you are
- debugging, though you only have to do it once (the debug configuration
- hangs around indefinitely).
- </para>
- <para>
- Again, running a test in standalone isn't enough to pass the TCK and
- cannot be used to run or debug an integration test. Let's look at how
- to debug a test running in the context of the container.
- </para>
- </section>
- <section>
- <title>Debugging an integration test</title>
- <para>
- In order to debug an integration test, or any test run using in-container
- mode, the test must be configured to run in-container, as described in
- <xref linkend="eclipse-in-container" />,
- and you must attach the IDE debugger to the container. That puts the
- debugger on both sides of the fence, so to speak.
- </para>
- <para>
- Since setting up a test to run in-container has already been
- covered, we'll look at how to attach the IDE debugger to the container,
- and then move on launching the test in debug mode.
- </para>
- <section>
- <title>Attaching the IDE debugger to the container</title>
- <para>
- There are two ways to attach the IDE debugger to the container.
- You can either start the container in debug mode from within the
- IDE, or you can attach the debugger over a socket connection to a
- standalone container running with JPDA enabled.
- </para>
- <para>
- The Eclipse Server Tools, a subproject of the Eclipse Web Tools
- Project (WTP), has support for launching most major application
- servers, including JBoss AS 5. However, if you are using JBoss AS,
- you should consider using JBoss Tools instead, which offers tighter
- integration with JBoss technologies. See either the
- <ulink url="http://www.eclipse.org/webtools/server/server.php">Server Tools documentation</ulink>
- or the
- <ulink url="http://docs.jboss.org/tools/3.0.1.GA/en/as/html/index.html">JBoss Tools documentation</ulink>
- for how to setup a container and start it in debug mode.
- </para>
- <para>
- See
- <ulink
- url="http://maverikpro.wordpress.com/2007/11/26/remote-debug-a-web-application...">this blog entry</ulink>
- to learn how to start JBoss AS with JPDA enabled and how to get the
- Eclipse debugger to connect to the remote process.
- </para>
- </section>
- <section>
- <title>Launching the test in the debugger</title>
- <para>
- Once Eclipse is debugging the container, you can set a breakpoint in
- the test and debug it just like a standalone test. Let's give it a
- try.
- </para>
- <para>
- Open a test annotated with <literal>@IntegrationTest</literal> in
- the Eclipse editor, right click in the editor view, and select Debug
- As > TestNG Test. This time when the IDE hits the breakpoint, it
- halts the JVM thread of the container rather than the thread that
- launched the test.
- </para>
- <para>
- Remember that if you need to debug into dependent libraries, the
- source code for those libraries will need to be registered with the
- TestNG debug configuration as described in the first section in this
- chapter.
- </para>
- </section>
- </section>
-<!--
-vim: ts=3:sw=3:tw=80:set expandtab
--->
-</chapter>
Deleted: beanvalidation/tck/trunk/src/main/docbook/en-US/eclipse-running.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/docbook/en-US/eclipse-running.xml 2009-10-01 08:14:40 UTC (rev 17604)
+++ beanvalidation/tck/trunk/src/main/docbook/en-US/eclipse-running.xml 2009-10-01 12:25:36 UTC (rev 17605)
@@ -1,447 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]>
-<chapter id="eclipse-running">
- <title>Running Tests in Eclipse</title>
- <para>
- This chapter explains how to run individual tests using the Eclipse
- TestNG plugin. It covers running non-integration tests in standalone mode
- and integration tests (as well as non-integration tests) in in-container
- mode. You should be able to use the lessons learned here to debug tests in
- an alternate IDE as well.
- </para>
- <section>
- <title>Leveraging Eclipse's plugin ecosystem</title>
- <para>
- Using an existing test harness (TestNG) allows the tests to be executed
- and debugged in an Integrated Development Environment (IDE) using
- available plugins. Using an IDE is also the easiest way to execute a
- test class in isolation.
-
- </para>
- <para>
- The TCK can be executed in any IDE for which there is a TestNG plugin
- available. Running a test from the CDI TCK test suite using the Eclipse
- TestNG plugin is almost as simple as running any other TestNG test. You
- can also use the plugin to debug a test, which is described in the next
- chapter.
- </para>
- <para>
- Before running a test from the TCK test suite in Eclipse, you must have
- the Eclipse <ulink url="http://testng.org">TestNG plugin</ulink> and
- either the m2eclipse plugin or an Eclipse project generated use the
- Maven 2 Eclipse plugin (<literal>maven-eclipse-plugin</literal>). Refer
- to <xref linkend="eclipse-plugins" /> for more information on these
- plugins.
- </para>
-
- <para>
- With the m2eclipse plugin installed, Eclipse should recognize the
- CDI TCK projects as valid Eclipse projects (or any Web Beans project
- for that matter). Import them into the Eclipse workspace at this time.
- You should also import the Web Beans projects if you want to debug into
- that code, which is covered later.
- </para>
- <tip>
- <para>
- If you choose to use the Maven 2 Eclipse plugin
- (<literal>maven-eclipse-plugin</literal>), you should execute the
- plugin in both the tck and webbeans projects:
- </para>
- <programlisting><![CDATA[cd tck
-mvn clean eclipse:clean eclipse:eclipse -DdownloadSources -DdownloadJavadocs
-cd ../webbeans
-mvn clean eclipse:clean eclipse:eclipse -DdownloadSources -DdownloadJavadocs]]></programlisting>
- </tip>
- </section>
- <section>
- <title>Readying the Eclipse workspace</title>
- <para>
- When setting up your Ecilpse workspace, we recommended creating three
- workings sets:
- </para>
- <orderedlist>
- <listitem>
- <para>
- <emphasis role="bold">Web Beans</emphasis> - Groups the CDI API
- and the CDI RI (i.e., Web Beans) projects
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis role="bold">CDI TCK</emphasis> - Groups the CDI TCK
- API and the test suite projects
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis role="bold">Web Beans JBoss TCK Runner</emphasis> -
- Groups the porting package implementation and TCK runner projects
- that are configured to certify Web Beans deployed on JBoss AS 5.1
- </para>
- </listitem>
- </orderedlist>
- <para>
- The dependencies between the projects will either be established
- automatically by the m2eclipse plugin, based on the dependency
- information in the pom.xml files, or as generated by the <literal>mvn
- eclipse:eclipse</literal> command.
- </para>
- <para>
- Your workspace should appear as follows:
- </para>
- <programlisting><![CDATA[Web Beans
- jsr299-api
- webbeans-api
- webbeans-core
- webbeans-core-test
- webbeans-logging
- webbeans-parent
- webbeans-spi
- webbeans-version-matrix
-CDI TCK
- jsr299-tck-api
- jsr299-tck-impl
- jsr299-tck-parent
-Web Beans JBoss TCK Runner
- webbeans-jboss-tck-runner
- webbeans-porting-package]]></programlisting>
- <para>
- The tests in the TCK test suite are located in the jsr299-tck-impl
- project. You'll be working within this project in Eclipse when you are
- developing tests. However, as you learned earlier, there are no references
- to a CDI implementation in the TCK. So how can you execute an
- individual test in Eclipse? The secret is that you need to establish a
- link in Eclipse (not in Maven) between the jsr299-tck-impl project and
- your TCK runner project, which in this case is
- webbeans-jboss-tck-runner (the project in the jboss-tck-runner
- directory).
- </para>
- <para>
- Here are the steps to establish the link:
- </para>
- <orderedlist>
- <listitem>
- <para>
- Right click on the jsr299-tck-impl project
- </para>
- </listitem>
- <listitem>
- <para>
- Select Build Path > Configure Build Path...
- </para>
- </listitem>
- <listitem>
- <para>
- Click on the Projects tab
- </para>
- </listitem>
- <listitem>
- <para>
- Click the Add... button on the right
- </para>
- </listitem>
- <listitem>
- <para>
- Check the TCK runner project (e.g., webbeans-jboss-tck-runner)
- </para>
- </listitem>
- <listitem>
- <para>
- Click the OK button on the Required Project Selection dialog
- window
- </para>
- </listitem>
- <listitem>
- <para>
- Click the OK button on the Java Build Path window
- </para>
- </listitem>
- </orderedlist>
- <para>
- Of course, the webbeans-jboss-tck-runner also depends on the
- jsr299-tck-impl at runtime (so it can actually find the tests to
- execute). But Eclipse doesn't distinguish between build-time and
- runtime dependencies. As a result, we've created a circular dependency
- between the projects. In all likelihood, Eclipse will struggle (if not
- fail) to compile one or more projects. How can we break this cycle?
- </para>
- <para>
- As it turns out, the TCK runner doesn't need to access the tests to
- build. It only needs its classes, configurations and other dependenices
- at runtime (when the TestNG plugin executes). Therefore, we can remove
- the TCK runner's dependence on the jsr299-tck-impl project by following
- these steps:
- </para>
- <orderedlist>
- <listitem>
- <para>
- Right click on the webbeans-jboss-tck-runner project
- </para>
- </listitem>
- <listitem>
- <para>
- Select Build Path > Configure Build Path...
- </para>
- </listitem>
- <listitem>
- <para>
- Click on the Projects tab
- </para>
- </listitem>
- <listitem>
- <para>
- Select the TCK tests project (jsr299-tck-impl)
- </para>
- </listitem>
- <listitem>
- <para>
- Click the Remove button on the right
- </para>
- </listitem>
- <listitem>
- <para>
- Click the OK button on the Java Build Path window
- </para>
- </listitem>
- </orderedlist>
- <para>
- You are now ready to execute an individual test class (or artifact).
- Let's start with a test artifact capable of running in standalone mode.
- </para>
- </section>
- <section id="eclipse-standalone">
- <title>Running a test in standalone mode</title>
- <para>
- A standalone test artifact is a class which extends
- <literal>AbstractJSR299Test</literal>, is annotated with
- <literal>@Artifact</literal>, but is <emphasis
- role="italic">not</emphasis> annotated with
- <literal>@IntegrationTest</literal>. Select a standalone test artifact
- and open it in the Eclipse editor. Now right click in the editor view
- and select Run As > TestNG Test. The TestNG view should pop out and
- you should see all the tests in that artifact pass (if all goes well).
- </para>
- <note>
- <para>
- If the TCK complains that there is a property missing, close all
- the projects, open them again, and rebuild. The m2eclipse plugin can
- be finicky getting everything built correctly the first time.
- </para>
- </note>
- <para>
- So far you have executed a test in standalone mode. That's not
- sufficient to pass the TCK. The test must be executed using
- in-container mode. Using in-container mode is also the only way to
- execute a test annotated with <literal>@IntegrationTest</literal>
- (that's what the annotation means) as it requires container resources.
- </para>
- <para>
- Let's see what has to be done to execute an integration test. This
- will result in the artifact being deployed to the container, which is
- JBoss AS 5.1 if you are using the JBoss TCK runner.
- </para>
- </section>
- <section id="eclipse-in-container">
- <title>Running integration tests</title>
- <para>
- As you have learned, the JBoss test harness determines how to behave
- based on the values of numerous system properties or properties defined
- in META-INF/jboss-test-harness.properties classpath resources. If the
- property named
- <literal>org.jboss.testharness.standalone</literal>
- is not defined, the harness assumes that the test is to be run in
- standalone mode. In order to run the tests in the container, you need
- to add a properties file to the classpath that sets the standalone
- property to false and provides values for other properties required to
- run an in-container test.
- </para>
- <para>
- The JBoss TCK runner project conveniently provides the properties file
- src/test/debug-resources/META-INF/jboss-test-harness.properties that
- contains all of the necessary properties for in-container testing in
- Eclipse. Assuming you followed the directory structure recommended in
- <xref linkend="tck-environment"/>, you are good to go. Otherwise, you
- may have to tune the
- <literal>org.jboss.testharness.container.extraConfigurationDir</literal> and
- <literal>org.jboss.testharness.libraryDirectory</literal> properties to
- point to the relative location of the related projects. The properties
- should be defined as follows:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <literal>org.jboss.testharness.container.extraConfigurationDir
- </literal>
- - the relative path from the jboss-tck-impl project to a
- directory that contains a build.properties or
- local.build.properties file defining the location of a JBoss AS
- 5.1 installation in the
- <literal>jboss.home</literal>
- property
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>org.jboss.testharness.libraryDirectory</literal>
- - the relative path from the jboss-tck-impl project to the
- target/dependency/lib directory in the TCK runner project.
- </para>
- </listitem>
- </itemizedlist>
- <para>
- The other properties in that file are defined as follows:
- </para>
- <programlisting>org.jboss.testharness.standalone=false
-orjboss.testharness.container.forceRestart=false
-orjboss.testharness.runIntegrationTests=true</programlisting>
- <para>
- You're now ready to execute an integration test. Select an integration
- test (a class that extends <literal>AbstractJSR299Test</literal> and is
- annotated with both <literal>@Artifact</literal> and
- <literal>@IntegrationTest</literal>) and open it in your Eclipse
- editor. Follow these steps to execute the class with the TestNG plugin:
- </para>
- <orderedlist>
- <listitem>
- <para>
- Right click in the editor view and select Run As > TestNG Test
- </para>
- </listitem>
- <listitem>
- <para>
- Observe the test fail because of missing dependencies
- </para>
- </listitem>
- <listitem>
- <para>
- Select the Run > Run Configurations... menu from the main
- menubar
- </para>
- </listitem>
- <listitem>
- <para>
- Select the name of the test class under the TestNG category
- </para>
- </listitem>
- <listitem>
- <para>
- Select the Classpath tab
- </para>
- </listitem>
- <listitem>
- <para>
- Select User Entries in the tree
- </para>
- </listitem>
- <listitem>
- <para>
- Click the Advanced... button on the right
- </para>
- </listitem>
- <listitem>
- <para>
- Select Add Folders and click the OK button
- </para>
- </listitem>
- <listitem>
- <para>
- Select the webbeans-jboss-tck-runner/src/test/debug-resources
- folder
- </para>
- </listitem>
- <listitem>
- <para>
- Click the OK button on the Folder Selection dialog window
- </para>
- </listitem>
- <listitem>
- <para>
- Click on the webbeans-jboss-tck-runner entry
- </para>
- </listitem>
- <listitem>
- <para>
- Move the webbeans-jboss-tck-runner to the first entry using
- the Up button
- </para>
- </listitem>
- <listitem>
- <para>
- Click the Run button on the Run Configurations dialog window
- </para>
- </listitem>
- </orderedlist>
- <para>
- When you run the test this time, it should pass. If you get a
- failure that the container (e.g., JBoss AS 5.1) must be run with
- assertions enabled, you need to stop the container and start it with
- the -ea flag (or just leave it stopped and the test will start it
- appropriately).
- </para>
- <para>
- You can simply right click and select Run As > TestNG Test for
- all subsequent runs for the reason cited earlier, the run configuration
- for a class is retained indefinitely.
- </para>
- <para>
- Alternatively, you can configure TestNG to execute all tests
- in-container by default by adding the properties file in the
- debug-resources folder to the project's classpath as follows:
- </para>
- <orderedlist>
- <listitem>
- <para>
- Right click on the jsr299-tck-impl project
- </para>
- </listitem>
- <listitem>
- <para>
- Select Build Path > Configure Build Path...
- </para>
- </listitem>
- <listitem>
- <para>
- Click on the Libraries tab
- </para>
- </listitem>
- <listitem>
- <para>
- Click the Add Class Folder... button on the right
- </para>
- </listitem>
- <listitem>
- <para>
- Check the webbeans-jboss-tck-runner/src/test/debug-resources
- folder
- </para>
- </listitem>
- <listitem>
- <para>
- Click the OK button on the Class Folder Selection dialog
- window
- </para>
- </listitem>
- <listitem>
- <para>
- Click the OK button on the Java Build Path window
- </para>
- </listitem>
- </orderedlist>
- <para>
- Now you don't have to do any special configuration per test class.
- </para>
- <para>
- You can stop the individual tests from running in-container by
- reversing the steps above to remove the debug-resources folder from the
- Eclipse classpath.
- </para>
- <para>
- You have now mastered running the CDI TCK against Web Beans using
- both Maven 2 and within Eclipse. Now you're likely interested in how to
- debug a test so that you can efficiently investigate test failures.
- </para>
- </section>
-<!--
-vim: ts=3:sw=3:tw=80:set expandtab
--->
-</chapter>
Modified: beanvalidation/tck/trunk/src/main/docbook/en-US/executing.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/docbook/en-US/executing.xml 2009-10-01 08:14:40 UTC (rev 17604)
+++ beanvalidation/tck/trunk/src/main/docbook/en-US/executing.xml 2009-10-01 12:25:36 UTC (rev 17605)
@@ -16,25 +16,26 @@
<para>The test suite is executed by the Maven 2 TestNG plugin during the
test phase of the Maven 2 life cycle. The execution happens within a TCK
runner project (as opposed to the TCK project itself). Hibernate Validator
- includes a TCK runner project that executes the Bean Validation TCK on
- Hibernate Validator running inside JBoss AS 5.1. To execute the Bean
- Validation TCK on your own Bean Validation implementation, you could
- modify the TCK runner project included with Hibernate Validator to use
- your Bean Validation implementation as described in <xref
- linkend="configuration" />.</para>
+ includes a TCK runner project (hibernate-validator-tck-runner) that
+ executes the Bean Validation TCK on Hibernate Validator running inside
+ JBoss AS 5.1. To execute the Bean Validation TCK on your own Bean
+ Validation implementation, you could modify the TCK runner project
+ included with Hibernate Validator to use your Bean Validation
+ implementation as described in <xref linkend="configuration" />.</para>
</section>
<section>
<title>Running the Tests In Standalone Mode</title>
- <para>To execute the TCK test suite against Web Beans, first switch to the
- jboss-tck-runner directory in the extracted Web Beans distribution:</para>
+ <para>To execute the TCK test suite against Bean Validation, first switch
+ to the <filename>hibernate-validator-tck-runner </filename>directory in
+ the checked out Hibernate Validator distribution:</para>
<programlisting>cd ri/hibernate-validator-tck-runner</programlisting>
<note>
- <para>These instructions assume you have extracted the CDI-related
- software according to the recommendation given in <xref
+ <para>These instructions assume you have extracted the Bean Validation
+ related software according to the recommendation given in <xref
linkend="tck-environment" />.</para>
</note>
Modified: beanvalidation/tck/trunk/src/main/docbook/en-US/installation.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/docbook/en-US/installation.xml 2009-10-01 08:14:40 UTC (rev 17604)
+++ beanvalidation/tck/trunk/src/main/docbook/en-US/installation.xml 2009-10-01 12:25:36 UTC (rev 17605)
@@ -12,13 +12,12 @@
<title>Obtaining the Software</title>
<para>You can obtain a release of the Bean Validation TCK project from the
- from the <ulink url="http://seamframework.org/Download">download
+ from the <ulink url="https://www.hibernate.org/6.html">download
page</ulink> on the Hibernate Validator website. The Bean Validation TCK
is distributed as a ZIP file, which contains the TCK artifacts (the test
- suite binary and source, porting package API binary and source, the test
- suite descriptor, the audit source and report) in <code>/artifacts</code>,
- the TCK library dependencies in <code>/lib</code> and documentation in
- <code>/lib</code>.</para>
+ suite binary and source, the test suite descriptor, the audit source and
+ report), the TCK library dependencies in <code>/lib</code> and
+ documentation in <code>/doc</code>.</para>
<para>You can also download the currnet source code from <ulink
url="http://anonsvn.jboss.org/repos/hibernate/beanvalidation/tck/trunk/">JBoss
@@ -45,10 +44,6 @@
yourself with the TCK before testing your own Bean Validation
implementation.</para>
</note>
-
- <para>Naturally, to execute Java programs, you must have a Java SE runtime
- environment. The TCK requires Java 5 or better, which you can obtain from
- the <ulink url="http://java.sun.com">Java Software</ulink> website.</para>
</section>
<section id="tck-environment">
@@ -72,10 +67,16 @@
<para>The rest of the TCK software can simply be extracted. It's
recommended that you create a folder named jsr303 to hold all of the
jsr303-related projects. Then, extract the TCK distribution into a
- subfolder named tck. If you have downloaded the Hibernate Validator
- distribution, extract it into a sibling folder named ri. The resulting
- folder structure is shown here:</para>
+ subfolder named tck. You can also check out the full Hibernate Validator
+ source into a subfolder ri. This will allow you to run the TCK against
+ Hibernate Validator.</para>
+ <programlisting>svn co http://anonsvn.jboss.org/repos/hibernate/validator/tags/v_4_0_0_GA ri</programlisting>
+
+ <para>If you have downloaded the Hibernate Validator distribution, extract
+ it into a sibling folder named hibernate-validator. The resulting folder
+ structure is shown here:</para>
+
<note>
<para>This layout is assumed through all descriptions in this reference
guide.</para>
@@ -96,15 +97,6 @@
<title>Running the TCK against the Bean Validation RI (Hibernate
Validator) and JBoss AS</title>
- <para>Web Beans is built as a modular library, and as such can be
- retro-fitted to Java EE 5 products as required. JBoss AS 5.0 and above
- releases bundle Web Beans. JBoss AS 5.0 also allows you to upgrade the
- Web Beans module to the current release (though some functionality may
- be disabled).</para>
-
- <para>To install JBoss AS 5.1 and update to the latest Web Beans
- release:</para>
-
<itemizedlist>
<listitem>
<para>First, you should download JBoss AS 5.1 from the JBoss AS
@@ -118,34 +110,18 @@
</listitem>
<listitem>
- <para>Change to the webbeans directory.</para>
+ <para>Change to the
+ <filename>ri/hibernate-validator-tck-runner</filename>
+ directory.</para>
</listitem>
<listitem>
<para>Make sure the <literal>jboss.home</literal> property in the
- local.build.properties file in the jboss-as directory references a
- JBoss AS 5.1 installation:</para>
-
- <programlisting>jboss.home=/path/to/jboss-as-5.1</programlisting>
+ <filename>pom.xml</filename> file references a JBoss AS 5.1
+ installation.</para>
</listitem>
<listitem>
- <para>Then, run Ant from the jboss-as directory to install the
- deployer:</para>
-
- <programlisting>ant update</programlisting>
-
- <para>The libraries needed by the deployer are fetched from the
- Maven 2 repository on demand.</para>
- </listitem>
- </itemizedlist>
-
- <para>Web Beans includes a TCK runner that executes the TCK using Web
- Beans as the CDI implementation and JBoss AS as the Java EE runtime. To
- run the tck:</para>
-
- <itemizedlist>
- <listitem>
<para>You need to install Maven. You can find documention on how to
install Maven 2 in the <ulink
url="http://www.sonatype.com/books/maven-book/reference/installation-sect-mave...">Maven:
@@ -157,8 +133,7 @@
<listitem>
<para>Next, instruct Maven to run the TCK:</para>
- <programlisting>cd jboss-tck-runner
-mvn test -Dincontainer</programlisting>
+ <programlisting>mvn test -Dincontainer</programlisting>
</listitem>
<listitem>
@@ -170,58 +145,6 @@
</tip>
</section>
- <section id="eclipse-plugins">
- <title>Eclipse Plugins</title>
-
- <para>Eclipse, or any other IDE, is not required to execute or pass the
- TCK. However an implementor may wish to execute tests in an IDE to aid
- debugging the tests. This section introduces two essential Eclipse
- plugins, TestNG and Maven 2, and points you to resources explaining how to
- install them.</para>
-
- <section id="eclipse-testng-plugin">
- <title>TestNG Plugin</title>
-
- <para>The TCK is built on the JBoss Test Harness, which is in turn built
- on TestNG. Therefore, having the TestNG plugin installed in Eclipse is
- essential. Instructions for using the TestNG update site to add the
- TestNG plugin to Eclipse are provided on the TestNG <ulink
- url="http://testng.org/doc/download.html">download page</ulink>. You can
- find a tutorial that explains how to use the TestNG plugin on the TestNG
- <ulink url="http://testng.org/doc/eclipse.html">Eclipse
- page</ulink>.</para>
- </section>
-
- <section id="m2eclipse-plugin">
- <title>Maven 2 Plugin (m2eclipse)</title>
-
- <para>Another useful plugin is m2eclipse. Both the TCK project and Web
- Beans are use Maven 2. Therefore, to work with these projects in
- Eclipse, you may wish to have native support for Maven 2 projects, which
- the m2eclipse plugin provides. Instructions for using the m2eclipse
- update site to add the m2eclipse plugin to Eclipse are provided on the
- m2eclipse home page. For more, read the m2eclipse <ulink
- url="http://www.sonatype.com/books/m2eclipse-book/reference">reference
- guide</ulink>.</para>
-
- <para>m2eclipse is still a rather young project dealing with a complex
- domain and you may run into problems using it. If that is the case, you
- can alternatively use the Eclipse plugin for Maven 2 to generate native
- Eclipse projects from Maven 2 projects.</para>
-
- <para>If you have Maven 2 installed, you have everything you need. Just
- execute the following command from any Maven 2 project to produce the
- Eclipse project files.</para>
-
- <programlisting>mvn eclipse:eclipse</programlisting>
- </section>
-
- <para>Again, the Eclipse plugins are not required to execute the TCK, but
- can be very helpful when validating an implementation against the TCK test
- suite and especially when using the modules from the Hibernate Validator
- project.</para>
- </section>
-
<!--
vim: ts=3:sw=3:tw=80:set expandtab
-->
Modified: beanvalidation/tck/trunk/src/main/docbook/en-US/introduction.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/docbook/en-US/introduction.xml 2009-10-01 08:14:40 UTC (rev 17604)
+++ beanvalidation/tck/trunk/src/main/docbook/en-US/introduction.xml 2009-10-01 12:25:36 UTC (rev 17605)
@@ -2,7 +2,7 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
<chapter id="introduction">
- <title>Introduction (Bean Validation TCK)</title>
+ <title>Introduction</title>
<para>This chapter explains the purpose of a TCK and identifies the
foundation elements of the Bean Validation TCK.</para>
@@ -28,7 +28,7 @@
unmodified).</para>
<para>A TCK is entirely implementation agnostic. It should validate
- assertions by consulting the specficiation's public API. </para>
+ assertions by consulting the specficiation's public API.</para>
</section>
<section>
@@ -95,10 +95,10 @@
<para>The Bean Validation TCK is designed as a portable, configurable and
automated test suite for verifying the compatibility of an implementation
- of the JSR-303: Bean Validation specification. The test suite is built
- atop TestNG and provides a series of extensions that allow runtime
- packaging and deployment of JEE artifacts for in-container testing (JBoss
- Test Harness).</para>
+ of JSR-303: Bean Validation specification. The test suite is built atop
+ TestNG and provides a series of extensions that allow runtime packaging
+ and deployment of JEE artifacts for in-container testing (JBoss Test
+ Harness).</para>
<note>
<para>The Bean Validation TCK harness is based on the JBoss Test
@@ -107,7 +107,7 @@
<para>Each test class in the suite acts as a deployable unit. The
deployable units, or artifacts, are defined declaratively using
- annotations. The artifact produced can be either a WAR or an EAR.</para>
+ annotations. </para>
<para>The declarative approach allows many of the tests to be executed in
a standalone implementation of Bean Validation, accounting for a boast in
@@ -175,15 +175,15 @@
<listitem>
<para><emphasis role="bold">The test suite</emphasis>, which is a
collection of TestNG tests, the TestNG test suite descriptor and
- supplemental resources that configure CDI and other software
- components.</para>
+ supplemental resources that configure Bean Validation and other
+ software components.</para>
</listitem>
<listitem>
<para><emphasis role="bold">The TCK audit</emphasis> is used to list
- out the assertions identified in the CDI specification. It matches
- the assertions to testcases in the test suite by unique identifier
- and produces a coverage report.</para>
+ out the assertions identified in the Bean Validation specification.
+ It matches the assertions to testcases in the test suite by unique
+ identifier and produces a coverage report.</para>
<para>The audit document is provided along with the TCK. Each
assertion is defined with a reference to a chapter, section and
@@ -203,7 +203,7 @@
<itemizedlist>
<listitem>
- <para>JBoss AS 5.0.0.GA using Sun Java SE 6 on Red Hat Enterprise
+ <para>JBoss AS 5.1.0.GA using Sun Java SE 6 on Red Hat Enterprise
Linux 5.2</para>
</listitem>
</itemizedlist>
Modified: beanvalidation/tck/trunk/src/main/docbook/en-US/part-execution.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/docbook/en-US/part-execution.xml 2009-10-01 08:14:40 UTC (rev 17604)
+++ beanvalidation/tck/trunk/src/main/docbook/en-US/part-execution.xml 2009-10-01 12:25:36 UTC (rev 17605)
@@ -9,19 +9,8 @@
Bean validation reference implementation (Hibernate Validator). First, you
are walked through the steps necessary to execute the test suite on
Hibernate Validator. Then you discover how to modify the TCK runner to
- execute the test suite on your own implementation. Finally, you learn how
- to debug tests from the test suite in Eclipse.</para>
+ execute the test suite on your own implementation. </para>
</partintro>
<xi:include href="executing.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
-
- <xi:include href="eclipse-running.xml"
- xmlns:xi="http://www.w3.org/2001/XInclude" />
-
- <xi:include href="eclipse-debugging.xml"
- xmlns:xi="http://www.w3.org/2001/XInclude" />
-
- <!--
-vim: ts=3:sw=3:tw=80:set expandtab
--->
</part>
Modified: beanvalidation/tck/trunk/src/main/docbook/en-US/part-test-harness.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/docbook/en-US/part-test-harness.xml 2009-10-01 08:14:40 UTC (rev 17604)
+++ beanvalidation/tck/trunk/src/main/docbook/en-US/part-test-harness.xml 2009-10-01 12:25:36 UTC (rev 17605)
@@ -1,18 +1,24 @@
<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]>
+<!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
<part id="test-harness">
- <title>JBoss Test Harness</title>
- <partintro>
- <para>
- In this part you learn about the JBoss Test Harness through selected
- chapters from the JBoss Test Harness Reference Guide. You can view the
- entire JBoss Test Harness Reference Guide at <ulink url="">TODO</ulink>.
- </para>
- </partintro>
- <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="harness/introduction.xml" />
- <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="harness/configuration.xml" />
- <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="harness/executing.xml" />
-<!--
+ <title>JBoss Test Harness</title>
+
+ <partintro>
+ <para>In this part you learn about the JBoss Test Harness through selected
+ chapters from the JBoss Test Harness Reference Guide. </para>
+ </partintro>
+
+ <xi:include href="harness/introduction.xml"
+ xmlns:xi="http://www.w3.org/2001/XInclude" />
+
+ <xi:include href="harness/configuration.xml"
+ xmlns:xi="http://www.w3.org/2001/XInclude" />
+
+ <xi:include href="harness/executing.xml"
+ xmlns:xi="http://www.w3.org/2001/XInclude" />
+
+ <!--
vim: ts=3:sw=3:tw=80:set expandtab
-->
</part>
Modified: beanvalidation/tck/trunk/src/main/docbook/en-US/reporting.xml
===================================================================
--- beanvalidation/tck/trunk/src/main/docbook/en-US/reporting.xml 2009-10-01 08:14:40 UTC (rev 17604)
+++ beanvalidation/tck/trunk/src/main/docbook/en-US/reporting.xml 2009-10-01 12:25:36 UTC (rev 17605)
@@ -20,8 +20,8 @@
<para><emphasis role="bold">Assertion Breadth
Coverage</emphasis></para>
- <para>The CDI TCK provides at least 75% coverage of identified
- assertions with test cases.</para>
+ <para>The BEan Validation TCK provides at least 100% coverage of
+ identified assertions with test cases.</para>
</listitem>
<listitem>
@@ -50,8 +50,8 @@
<listitem>
<para><emphasis role="bold">API Signature Coverage</emphasis></para>
- <para>The CDI TCK covers 100% of all API public methods using the Java
- CTT Sig Test tool.</para>
+ <para>The Bean Validation TCK covers 100% of all API public methods
+ using the Java CTT Sig Test tool.</para>
</listitem>
</itemizedlist>
</section>
@@ -77,11 +77,11 @@
2.1:</para>
<blockquote>
- Every constraint annotation must define a message element of type String
+ Every constraint annotation must define a message element of type String
</blockquote>
<para>The assertions are listed in the XML file
- src/main/resources/tck-audit.xml in the Bean Validation TCK
+ <filename>tck-audit.xml</filename> in the Bean Validation TCK
distribution. Each assertion is identified by the section of the
specification document in which it resides and assigned a unique
paragraph identifier to narrow down the location of the assertion
@@ -130,8 +130,9 @@
project build. Specifically, it is generated by an annotation processor
that attaches to the compilation of the classes in the TCK test suite,
another tool from the JBoss Test Utils project. You can enable this
- report by setting the commandline property tck-audit to true when
- running the Maven 2 build in the tck directory.</para>
+ report by setting the commandline property
+ <property>tck-audit</property> to true when running the Maven 2 build in
+ the tck directory.</para>
<programlisting>mvn clean install -Dtck-audit=true</programlisting>
@@ -215,19 +216,20 @@
<section>
<title>TestNG Reports</title>
- <para>As you by now, the CDI TCK test suite is really just a TestNG test
- suite. That means an execution of the CDI TCK test suite produces all
- the same reports that TestNG produces. This section will go over those
- reports and show you were to go to find each of them.</para>
+ <para>As you by now, the Bean Validation TCK test suite is really just a
+ TestNG test suite. That means an execution of the Bean Validation TCK
+ test suite produces all the same reports that TestNG produces. This
+ section will go over those reports and show you were to go to find each
+ of them.</para>
<section>
<title>Maven 2, Surefire and TestNG</title>
- <para>When the CDI TCK test suite is executed during the Maven 2 test
- phase of the TCK runner project, TestNG is invoked indirectly through
- the Maven Surefire plugin. Surefire is a test execution abstraction
- layer capable of executing a mix of tests written for JUnit, TestNG,
- and other supported test frameworks.</para>
+ <para>When the Bean Validation TCK test suite is executed during the
+ Maven 2 test phase of the TCK runner project, TestNG is invoked
+ indirectly through the Maven Surefire plugin. Surefire is a test
+ execution abstraction layer capable of executing a mix of tests
+ written for JUnit, TestNG, and other supported test frameworks.</para>
<para>Why is this relevant? It means two things. First, it means that
you are going to get a summary of the test run on the commandline.
@@ -248,7 +250,7 @@
<note>
<para>The number of tests executed, the execution time, and the
output will differ when you run the tests using in-container mode as
- the CDI TCK requires.</para>
+ the Bean Validation TCK requires.</para>
</note>
<para>If the Maven reporting plugin that compliments Surefire is
@@ -295,33 +297,20 @@
</listitem>
</itemizedlist>
- <para>The first report, the test summary report, show below, is
- written to the file index.html. It produces the same information as
- the generic Surefire report.</para>
-
- <graphic align="center" fileref="images/testng-summary-report.png" />
-
- <para>The summary report links to the test suite detail report, which
+ <para>The first report, the test summary report is written to the file
+ index.html. It produces the same information as the generic Surefire
+ report.The summary report links to the test suite detail report, which
has a wealth of information. It shows a complete list of test groups
along with the classes in each group, which groups were included and
excluded, and any exceptions that were raised, whether from a passed
or failed test. A partial view of the test suite detail report is
shown below.</para>
- <graphic align="center"
- fileref="images/testng-suite-detail-report.png" />
-
<para>The test suite detail report is very useful, but it borderlines
on complex. As an alternative, you can have a look at the emailable
report, which is a single HTML document that shows much of the same
information as the test suite detail report in a more compact layout.
- A partial view of the emailable report is shown below.</para>
-
- <graphic align="center" fileref="images/testng-emailable-report.png" />
-
- <para>Now that you have seen two ways to get test results from the
- Maven test execution, let's switch over to the IDE, specifically
- Eclipse, and see how it presents TestNG test results.</para>
+ </para>
</section>
</section>
</section>
14 years, 7 months
- 1
- 0
Thank you for setting the order No.475456
by Gina Wesley
Dear Customer!
Thank you for ordering at our online store.
Your order: Sony VAIO A1133651A, was sent at your address.
The tracking number of your postal parcel is indicated in the document attached to this letter.
Please, print out the postal label for receiving the parcel.
Internet Store.
14 years, 7 months
- 1
- 0
Hibernate SVN: r17604 - validator/trunk.
by hibernate-commits＠lists.jboss.org
Author: hardy.ferentschik
Date: 2009-10-01 04:14:40 -0400 (Thu, 01 Oct 2009)
New Revision: 17604
Modified:
validator/trunk/pom.xml
Log:
updated the bv api version
Modified: validator/trunk/pom.xml
===================================================================
--- validator/trunk/pom.xml 2009-10-01 08:04:45 UTC (rev 17603)
+++ validator/trunk/pom.xml 2009-10-01 08:14:40 UTC (rev 17604)
@@ -47,7 +47,7 @@
<dependency>
<groupId>javax.validation</groupId>
<artifactId>validation-api</artifactId>
- <version>1.0.CR6-SNAPSHOT</version>
+ <version>1.0.0.GA</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
14 years, 7 months
- 1
- 0
Hibernate SVN: r17603 - beanvalidation/tck/trunk.
by hibernate-commits＠lists.jboss.org
Author: hardy.ferentschik
Date: 2009-10-01 04:04:45 -0400 (Thu, 01 Oct 2009)
New Revision: 17603
Modified:
beanvalidation/tck/trunk/pom.xml
Log:
updated the bv api version
Modified: beanvalidation/tck/trunk/pom.xml
===================================================================
--- beanvalidation/tck/trunk/pom.xml 2009-10-01 07:44:06 UTC (rev 17602)
+++ beanvalidation/tck/trunk/pom.xml 2009-10-01 08:04:45 UTC (rev 17603)
@@ -44,7 +44,7 @@
<dependency>
<groupId>javax.validation</groupId>
<artifactId>validation-api</artifactId>
- <version>1.0.CR6-SNAPSHOT</version>
+ <version>1.0.0.GA</version>
</dependency>
<dependency>
<groupId>org.jboss.test-audit</groupId>
14 years, 7 months
- 1
- 0
Hibernate SVN: r17602 - beanvalidation/api/trunk.
by hibernate-commits＠lists.jboss.org
Author: hardy.ferentschik
Date: 2009-10-01 03:44:06 -0400 (Thu, 01 Oct 2009)
New Revision: 17602
Modified:
beanvalidation/api/trunk/pom.xml
Log:
[maven-release-plugin] prepare for next development iteration
Modified: beanvalidation/api/trunk/pom.xml
===================================================================
--- beanvalidation/api/trunk/pom.xml 2009-10-01 07:43:59 UTC (rev 17601)
+++ beanvalidation/api/trunk/pom.xml 2009-10-01 07:44:06 UTC (rev 17602)
@@ -4,7 +4,7 @@
<groupId>javax.validation</groupId>
<artifactId>validation-api</artifactId>
- <version>1.0.0.GA</version>
+ <version>1.1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<name>Bean Validation API</name>
@@ -88,8 +88,8 @@
</licenses>
<scm>
- <connection>scm:svn:https://svn.jboss.org/repos/hibernate/beanvalidation/api/tags/v1_...</connection>
- <url>http://fisheye.jboss.org/browse/Hibernate/beanvalidation/api/tags/v1_0_0_GA</url>
+ <connection>scm:svn:https://svn.jboss.org/repos/hibernate/beanvalidation/api/trunk</connection>
+ <url>http://fisheye.jboss.org/browse/Hibernate/beanvalidation/api/trunk</url>
</scm>
<distributionManagement>
14 years, 7 months
- 1
- 0