1  Introduction

ObMimic™ from OpenBrace is a library of fully-configurable plain-Java™ implementations of the Servlet API’s interfaces and abstract classes, for use as test doubles in “out-of-container” testing of servlets, filters, listeners and any other code that uses the Servlet API (including, for example JSF pages).

We call these implementations of the Servlet API classes “mimics”, because they accurately mimic the behaviour of the corresponding real Servlet API objects in normal servlet-container implementations.

With ObMimic, your tests can use normal Java code to create and configure instances of HttpServletRequest, HttpServletResponse, ServletContext, HttpSession, and other Servlet API interfaces and classes for use in your tests. At its simplest, you can (for example) use new HttpServletRequestMimic() to obtain a complete, ready-to-use HttpServletRequest with reasonable default/example content (including a suitable default ServletContext).

Each mimic instance contains a mimicState object that encapsulates the logical state of the instance, and provides comprehensive facilities for configuring and examining the instance’s logical state. This includes direct control over everything that affects the behaviour and return values of the instance’s Servlet API methods (whilst maintaining consistency between related Servlet API methods, and with these state-manipulation facilities being quite distinct and separate from the Servlet API methods themselves).

You can thus construct “mimic” instances, configure them to have any required internal state, pass them to the servlets or other components that you want to test, and then check their resulting state — all within normal Java code (for example, within a normal JUnit or TestNG test case), without any need for packaging and deployment into a servlet container, without any need for complex “in-container” testing tools, and without any networking overheads.

You can also freely configure differing “deployment descriptor” values within your tests without having to manipulate web.xml files and without having to redeploy or restart anything (for example, to test a Servlet or Filter with a variety of different “init parameter” values). Similarly, you can programmatically control the behaviour of container-dependent features (such as whether or not the use of the HttpServletRequest.getHeaderNames method to access HTTP header names is supported). In addition, ObMimic can detect and report API calls that make incorrect or ambiguous use of the Servlet API. With a “Professional” or “Enterprise” licence you can configure how ObMimic handles such calls.

With a “Professional” or “Enterprise” licence, you can also use the mimicHistory object contained in each mimic instance to optionally record the details and results of a sequence of calls to the instance’s Servlet API methods for subsequent examination; or you can use the mimicListeners object contained in each mimic instance to intercept and examine (and optionally even modify) the details and results of each call to the instance’s Servlet API methods as each call occurs. You can also explicitly test your code against different versions of the Servlet API.

Unlike traditional “mocks” and “stubs”, ObMimic’s “mimic” classes provide complete, ready-made implementations that fully implement all of the behaviour defined by the Servlet API (including, for example, RequestDispatcher “forward”s and “include”s, filter chains, cross-context session-handling, notification of listeners etc), and correctly handle even complex sequences of Servlet API calls. As a result, tests that use ObMimic do not depend on your own expectations of how the Servlet API methods should behave. Nor do you need to know the precise sequence of Servlet API calls that will result from your code and the responses that are required from each of these calls.

As well as making your tests more meaningful and less fragile, this also means that with suitable configuration you can use ObMimic to test the overall operation of multiple components and “framework” code. You can even use it where your code involves third-party libraries and frameworks that make their own internal calls to the Servlet API. For example, you can use ObMimic for out-of-container testing of JSF pages, as described in the “How To” guide How to test JSF pages.

Note that whilst ObMimic provides implementations of the Servlet API interfaces and classes as defined by their Javadoc, it is not itself a servlet container, nor is it an implementation of the “Servlet Specification”, nor is any of its code intended for use inside a servlet container.

For further details, refer to the accompanying Getting Started (Short Version) or Getting Started (Detailed Version) documents and the other resources listed in Further Information below.

2  Supported Servlet API Versions

By default, this release of ObMimic simulates the Servlet 2.5 API as defined by the Servlet 2.5 MR2 Javadoc.

With a “Professional” or “Enterprise” licence, ObMimic can be configured to simulate any of the following versions of the Servlet API (either globally for all tests or programmatically within individual tests, as described in the accompanying document “How to configure the Servlet API version to be simulated”):

However, Servlet 3.0 and Servlet 3.1 are not yet supported. The current plan is for support for these to be introduced progressively in subsequent releases of ObMimic. More specifically:

  • This release of ObMimic is compatible with Servlet 3.0 and 3.1 API libraries but does not yet provide support for any of the features or changes introduced in Servlet 3.0 and 3.1, and cannot be configured to simulate Servlet 3.0 or 3.1.
  • Any attempt to call a Servlet API method that is only present in Servlet 3.0 or 3.1 will fail with an exception. This will be an ObMimic “ApiElementAbsentException” if the method is not present in the Servlet API library being used. Otherwise it will be an ObMimic “ApiElementUnavailableException” to indicate that the relevant method is not available in the Servlet API version being simulated, unless ObMimic is configured to allow such calls to “unavailable” methods. In the latter case, ObMimic’s current implementation of the method will be called, with this implementation throwing an UnsupportedOperationException.
  • Note, however, that in the latter case the call to ObMimic’s current implementation of the relevant API method remains subject to the usual MimicListeners facilities (as described in the “How To” guide How to Intercept, Examine and Modify the Servlet API Calls to a Mimic). It is therefore possible to use the MimicListeners facilities to override the normal ObMimic behaviour of throwing an UnsupportedOperationException, and to instead explicitly provide any desired processing and outcome for the call.
  • Our current plan for Servlet 3.0 and 3.1 is to progressively add support for their new methods, interfaces and classes into future releases of ObMimic, under the guise of artificial “3.0-Partial” and “3.1-Partial” version numbers. Once they are fully implemented, official support for simulating them using their normal 3.0 and 3.1 version numbers will be enabled, with 3.1 as the default version. The “3.0-Partial” and “3.1-Partial” version numbers will then be retained for compatibility but treated as identical to “3.0” and “3.1” respectively.

Please feel free to contact us if you need further details of this, or if you have any specific requirements or priorities for Servlet 3.0 and 3.1 facilities.

3  Installation Instructions

For a simple, typical installation of ObMimic:

  • Unzip the ObMimic-1.2.001.zip archive into the location where you wish to install ObMimic. This will result in an “ObMimic-1.2.001” directory at that location, with contents as described in 5 Directory Structure below.
  • Create an OBMIMIC_HOME environment variable and set it to the path of the root of the ObMimic installation (its “ObMimic-1.2.001” directory).
  • If you have a “Professional” or “Enterprise” licence for ObMimic, place the licence file into the ObMimic installation’s /licence subdirectory.

For more complete details and alternative options, refer to the installation instructions given in the accompanying Getting Started (Detailed Version) document and the “How To” guides How to enable “Professional” and “Enterprise” edition features and How to set an ObMimic configuration property.

4  System Requirements

An installation of ObMimic occupies less than 50 MB of disk space.

Compiling and running tests that make use of ObMimic requires a JDK or JRE for Java™ SE 5 or higher (with Java SE 8 recommended).

In addition, any code that makes use of ObMimic will require the following to be on its classpath:

  • ObMimic’s obmimic.jar archive (as supplied in ObMimic’s /lib directory).
  • A Servlet API or Java EE API library that is suitable for use at run-time. That is, a “servlet.jar”, “servlet-api.jar”, “javax.servlet.jar”, “javax.servlet-api.jar”, “javaee.jar” or other such library that provides the Servlet API and is not one of the Java EE API jars that are deliberately restricted to compile-time use only (such as the “javaee-api-7.0.jar” and “javaee-web-api-7.0.jar” archives from the java.net website and elsewhere, as described below). For this release of ObMimic, this must be for version 2.4, 2.5, 3.0 or 3.1 of the Servlet API.
  • If running on Java SE 5 and not using a full Java EE API library for Java EE 5 or higher, a suitable “Common Annotations” library will also be required to provide the javax.annotation package (note that this is automatically present when running on Java SE 6 or higher, or if using a full Java EE API for Java EE 5 or higher). Refer to the notes below for further details, including where to obtain such a library if you need one.

Note that:

  • Whilst ObMimic remains compatible with Java SE 5 onwards, any other libraries that you are using may impose higher requirements (for example, if you are using a Servlet 3.1 or Java EE 7 API library this will itself require the use of Java SE 7 or higher). In addition, once Java SE 9 is released it is likely that compatibility with Java SE 5 will be dropped and Java SE 6 or higher will be required.
  • Any code being tested using ObMimic will, almost by definition, already be dependent on the Servlet API. It will therefore already need a suitable Servlet API library to be present in its compilation classpath, regardless of whether or not ObMimic is being used. The only additional requirement introduced by the use of ObMimic is that the Servlet API library will be needed for the ObMimic-based tests of the code as well as for compiling the code (and such tests will need a Servlet API library for Servlet 2.4 or higher even if an earlier Servlet API version is being used for other purposes). However, note that some Java EE API jars are deliberately restricted to compile-time use only, and are therefore not suitable for use with ObMimic — if one of these libraries is already being used, then a different or additional library will be needed on the classpath used for running any ObMimic-based tests (see below for further details).
  • As of late 2013, some Java EE API jars are deliberately restricted to compile-time use only, and cannot be used at run-time (for example, when running tests using ObMimic). These Java EE API jars deliberately omit various classes and resources that their own internal code makes use of. Some of the classes in these jars may therefore fail with various exceptions (typically “ClassNotFoundException”, “NoClassDefFoundError” or “ExceptionInInitializerError”) if these classes are loaded for run-time use (for example, when running ObMimic-based tests). In particular, this is true of the “javaee-api-7.0.jar” and “javaee-web-api-7.0.jar” libraries provided by the java.net website, and the copies of these jars available from various Maven™ repositories. ObMimic attempts to detect the presence of such a library as soon as possible during any run and throws an “UnacceptableApiJarException” if such a library is detected, so as to provide a clearer indication of this than would otherwise result from the library's own internal failure. If your project is using such a library, you will need to replace or supplement it with a different Java EE API or Servlet API library for your ObMimic-based test runs. For more complete details and explanation, see the FAQ entry “Why do I get an UnacceptableApiJarException?”.
  • If you do not otherwise have a suitable Servlet API or Java EE API library, you can obtain a suitable library for Servlet 3.1 from any of the following locations (for example): Alternatively:
    • You can obtain a “servlet-api.jar” for earlier versions of the Servlet API from the /lib directory of the relevant Apache Tomcat™ binary distribution (which can be downloaded from the Tomcat 6 download page for Servlet 2.5 or from the Tomcat 7 download page for Servlet 3.0).
    • Similarly, equivalent files for various versions of the Servlet API or Java EE are typically bundled in other such servlet containers and application servers and in relevant development tools, and can similarly be downloaded from appropriate Maven repositories and other such sources.
  • The javax.annotation “Common Annotations” package is a standard feature of both Java SE 6 onwards and Java EE 5 onwards, and is thus automatically present when running on Java SE 6 or higher or using a suitable Java EE 5 or higher “javaee.jar”. However, if running on Java SE 5 and not using a Java EE 5 or higher library, this package will need to be provided by a separate library. Also note that the version of this package provided by Java EE 6 requires Java SE 6 or higher, so if using a Java EE 6 library but running on Java SE 5 this package will need to be provided separately and placed ahead of the Java EE 6 library on your classpath. If you do need to obtain a separate library for this, one example is the “annotations-api.jar” from the /lib directory of an Apache Tomcat 6 binary distribution.
  • In general, ObMimic requires a Servlet API library for the highest version of the Servlet API that you wish to simulate, and will throw an “ApiElementAbsentException” if an attempt is made to invoke a Servlet API method that does not exist in the Servlet API library being used. (However, as there are only minimal differences between Servlet 2.4 and Servlet 2.5, ObMimic accommodates the differences between these two particular versions and can simulate Servlet 2.5 even when using a Servlet 2.4 library).

5  Directory Structure

The directory structure and contents of an ObMimic installation are as follows.

Root directory

The root directory of the ObMimic installation contains:

  • This README.html file.
  • LICENCE.html: The ObMimic “Community/Professional Edition” licence agreement.

Note that these README.html and LICENCE.html files make use of stylesheets, images and other resources from within the main ObMimic documentation in the /docs directory.

/config

This is the default location for ObMimic’s configuration file, with contents:

  • config.properties: The default properties file that specifies configuration settings for ObMimic. Refer to the accompanying “How To” guide How to set an ObMimic configuration property for details of how to this file and various other mechanisms can be used to set ObMimic configuration properties (and for details on how to use a different configuration file instead of this one).

/docs

This directory consists of a number of subdirectories containing ObMimic’s documentation and its various accompanying stylesheets, images and other resources.

/docs/api

ObMimic’s Javadoc.

Note that the ObMimic Javadoc is currently supplied in the Javadoc style generated by Java SE 7.

/docs/css

This directory contains the various CSS stylesheets that are used by the ObMimic documentation (for both the README.html and LICENCE.html files in the root of the directory structure and the main ObMimic documentation within the /docs/pages directory and its subdirectories).

This includes copies of CSS stylesheets obtained from the open-source Twitter Bootstrap framework (refer to the Legal Notices page for copyright and licensing details).

/docs/images

This directory contains the various icons, logos and other images used within the ObMimic documentation (for both the README.html and LICENCE.html files in the root of the directory structure and the main ObMimic documentation within the /docs/pages directory and its subdirectories).

/docs/js

This directory contains any Javascript files that are used within the ObMimic documentation (for both the README.html and LICENCE.html files in the root of the directory structure and the main ObMimic documentation within the /docs/pages directory and its subdirectories), and contains:

  • A copy of the PIE.htc file from the open-source CSS3 PIE project, which is used to improve the appearance of the documentation’s pages when viewed in versions of Microsoft Internet Explorer® prior to MSIE 9.
  • A copy of the IE7.js file and its accompanying blank.gif file from the open-source ie7-js project, which is used to improve the appearance of the documentation’s pages when viewed in versions of Microsoft Internet Explorer® prior to MSIE 7.
  • A MimicStateSummary.js script which is used to support expanding/collapsing of various sections within the /docs/pages/MimicStateSummary.html page.
  • A respond.min.js file from Scott Jehl’s Respond.js script, which is used to improve the appearance of the documentation’s pages when viewed in versions of Microsoft Internet Explorer® prior to MSIE 9.

Refer to the Legal Notices page for copyright and licensing details for the PIE.htc, IE7.js and respond.min.js files.

/docs/pages

ObMimic’s main documentation, consisting of:

  • index.html: Index page for the ObMimic documentation with links to the other documents.
  • GettingStartedShort.html: A short (one page) summary of how to install and start using ObMimic, including some simple example code.
  • GettingStartedDetailed.html: A guide to installing, configuring and starting to use ObMimic, including an overview of ObMimic and its key features, some example code, and notes regarding the design of ObMimic and its possible use. Note that this expands on the brief summary given in the shorter “GettingStartedShort.html” document.
  • MimicStateSummary.html: A summary of the properties and methods each of ObMimic’s MimicState classes (which encapsulate the logical internal state of ObMimic’s implementations of the Servlet API classes). This provides a high-level guide to these classes as a supplement to the more detailed and extensive information given by each MimicState’s Javadoc.
  • DesignPrinciples.html: A detailed explanation of some of the main principles and decisions that have shaped the analysis, design and implementation of ObMimic, in the context of its aims, overall approach and intended features.
  • Changes.html: An index to the various separate pages within the /docs/pages/changes directory that document the changes between ObMimic releases.
  • FAQ.html: ObMimic frequently-asked questions.
  • LegalNotices.html: Various legal and trademark notices, and details of any third-party components distributed within ObMimic (currently limited to some open-source Javascript components used to within its documentation to provide improved compatibility with older versions of Microsoft Internet Explorer).
  • Support.html: Details on how to obtain support and report bugs.

/docs/pages/changes

This directory contains an HTML page for each release of ObMimic that documents its changes from the preceding release (as indexed by the /docs/pages/Changes.html page).

/docs/pages/howto

A set of guides on how to tackle a variety of specific tasks when using ObMimic and how to use particular features of ObMimic, consisting of:

  • An index.html page that lists the various “How To” guides grouped into a number of categories.
  • An separate HTML page for each individual guide.

/etc

Miscellaneous files, consisting of:

  • obmimic.policy: An example Java security policy file that documents the permissions that ObMimic’s own code may require when run with a security manager.
  • obmimic.pom.xml: A Maven POM file that can be used to install the obmimic.jar library into a local Maven repository if desired.

Note that:

  • The obmimic.pom.xml file is provided to support optional installation of the obmimic.jar library into a Maven respository (with a groupId of “com.openbrace” and an artifactId of “obmimic”). This can be used, for example, to install the ObMimic library into the user’s local Maven repository by means of the following command (where “...path....” is the path of the ObMimic installation, as typically specified by an OBMIMIC_HOME environment variable):
    mvn install:install-file -Dfile=...path.../lib/obmimic.jar -DpomFile=...path.../etc/obmimic.pom.xml
  • For users of version 2.5 or higher of the Maven “Install” plugin, the “-DpomFile” argument can be omitted from the Maven install-file command shown above, as an equivalent pom.xml file is also included within the obmimic.jar itself at the appropriate location, and Maven can find and use this automatically when given the obmimic.jar archive to install.

/lib

ObMimic libraries, with contents:

  • obmimic.jar: The java archive containing ObMimic’s classes and supporting files.

Note that:

  • The obmimic.jar archive contains both a set of com.openbrace.obmimic.* packages that provide the ObMimic-specific functionality, and a set of com.openbrace.obcommon.* packages that provide various supporting facilities and utility classes that are not ObMimic-specific and may potentially be of more general use.
  • A Maven “pom” file is provided both within the obmimic.jar and separately in the /etc directory to support optional installation of the obmimic.jar library (as described above for the /etc/obmimic.pom.xml file).

/licence

This is the default location in which ObMimic looks for an ObMimic licence properties file to be used (failing which the “Community” edition is assumed).

Refer to the accompanying “How To” guide How to enable “Professional” and “Enterprise” edition features for details of how ObMimic locates the licence file and how to specify the use of a licence file in a different location.

6  Getting Started

Once ObMimic is installed, you can use it by adding its /lib/obmimic.jar archive to your code’s classpath (together with a suitable Servlet API library if not already present). You can then write code to create mimic instances for use in your tests as necessary, and can configure and inspect the internal state of these mimic instances via their mimicState properties.

For a short (one page) guide to installing and using ObMimic, see the Getting Started (Short Version) document.

For a more extensive guide, including additional details and explanations and an outline of ObMimic’s design and features, see the Getting Started (Detailed Version) document.

In addition, note that:

  • For projects using Maven, ObMimic includes a Maven “pom” file that can be used to install its obmimic.jar library into your local Maven repository for use in your projects. For details, see the accompanying “How To” guide How to add ObMimic to a Maven-based project.
  • ObMimic’s How To guides provide guidance on how to use ObMimic for specific commonly-encountered tasks.
  • The Overview of MimicState Classes document summarizes the contents of each of ObMimic’s “MimicState” classes so as to help you find your way around the internal state of each mimic class when configuring and inspecting mimic instances.
  • ObMimic’s Javadoc provides full details for all of ObMimic’s classes and methods.

7  Current Limitations

The following issues are known limitations and omissions in this release of ObMimic. It is hoped that many of these issues can be addressed in future releases.

If any of these issues are a particular problem for you, or are otherwise of specific interest to you, please let us know via the ObMimic feature requests forum at https://www.openbrace.com/forums/obmimic/features.html.

7.1  ObMimic is not designed for use within servlet containers

ObMimic is intended solely to enable “out-of-container” testing, and is neither designed nor intended for use within a servlet container. In particular it is neither designed nor intended for use within “live” systems.

Any use of ObMimic code within a servlet container is likely to encounter thread-safety issues (as per 7.3 below); is unlikely to interact correctly with the internal operation of the servlet container’s own Servlet API objects (which in general will interact with each other using implementation-specific mechanisms); could potentially be used to bypass or interfere with the servlet container’s own mechanisms; could potentially introduce security risks; and may be subject to other arbitrary issues and limitations.

Any attempt to use ObMimic code within a servlet container or “live” system is entirely at your own risk.

7.2  JSP pages are not yet supported

ObMimic does not currently provide any explicit support for JSP. For example, its servlet definitions allow a servlet-class to be specified but not a jsp-file, and any “.jsp” resources are treated as normal text resources with no special processing.

Mimic classes or other support for JSPs (for example, facilities for configuring the use of an external JSP translator/processor) may be introduced in future versions.

In the meantime, any “forward”s or other such routing to URLs that would normally invoke JSP pages can be configured to invoke a suitable servlet instead (for example, a simple HttpServletMimic instance). Refer to the How to cater for JSP pages document for further details and examples.

7.3  Mimics and their MimicStates are not thread-safe

ObMimic is intended for single-threaded testing of the functionality of code that uses the Servlet API, and in general it is not specifically intended to be thread-safe.

Some particular Mimic classes are designed to be thread-safe if used appropriately (as explained in their Javadoc), on the basis that they simulate Servlet API interfaces and classes that are required to be thread-safe. This applies to the Mimic classes for javax.servlet.Filter, javax.servlet.Servlet, javax.servlet.GenericServlet, javax.servlet.http.HttpServlet, and the various Servlet API “listener” interfaces.

In addition:

  • Some of the supporting classes and methods within the ObMimic library happen to be thread-safe, or are thread-safe when used in an appropriate manner, as defined in their Javadoc.
  • ObMimic’s built-in in-memory JNDI simulation treats each thread as having an associated ServletContext so that it can maintain separate sets of JNDI bindings for each ServletContext and use the appropriate set of bindings when a thread issues a JNDI look-up, and all of the operations involved in providing this behaviour are thread-safe.

However, in general the thread-safety of ObMimic classes is largely undefined and is not currently guaranteed, and ObMimic should be treated as not being thread-safe.

Note that whilst this prevents the use of ObMimic for testing the thread-safety of application code, it should not otherwise be an issue for normal use of ObMimic. At worst, if tests really must be run concurrently by multiple threads for any reason, each test or each thread can use its own set of Mimics and other objects so as to ensure that they are not subject to concurrent calls from multiple threads, or alternatively the tests can provide their own synchronization to control access to the relevant objects.

Future versions of ObMimic may provide more fully-specified multi-threaded behaviour. Potentially this might even include mechanisms to provide some degree of checking that application code is using the Servlet API in a thread-safe manner.

7.4  Application-wide error handling is not yet supported

Although ObMimic’s support for the error-page deployment descriptor element does include an exception-type sub-element, ObMimic as a whole does not currently support the automatic trapping of exceptions within a web-application and the corresponding use of such error-page elements when handling such an exception.

Support for more complete handling of exceptions and error-page definitions with exception-type elements may be added in future releases.

7.5  Welcome pages and directory indexes are not supported

ObMimic’s support for mapping URLs to target resources does not currently cater for “welcome” pages, nor for the generation of directory indexes for URLs that map to directory names within a web-application’s static resources.

Support for such facilities may be added in future releases.

7.6  Deployment-descriptor limitations

ObMimic’s support for web.xml deployment descriptors and their constituent elements is currently subject to a number of general limitations:

  • ObMimic does not currently provide any mechanism for populating a ServletContextMimic’s deployment-descriptor settings from a web.xml file. Current intention is to introduce a suitable mechanism for this in a future release. In the meantime, all required deployment-descriptor settings must instead be explicitly configured on the relevant ServletContextMimic’s mimicState and its sub-components (primarily its mimicState.webAppConfig).
  • In general, ObMimic does not currently provide any support for deployment descriptor elements that do not affect the current ObMimic facilities (for example, there is no support for the run-as and security-role-ref elements of a servlet-definition).

7.7  Built-in JNDI simulation supports only basic JNDI facilities

ObMimic’s built-in JNDI simulation does not currently support JNDI federation, composite names, “references” or “links”. If you need to use such facilities within ObMimic tests, you will need to make use of some other JNDI implementation instead of (or in addition to) ObMimic’s built-in JNDI simulation.

7.8  Resource injection in Servlet 2.5 onwards is only partially supported

When simulating Servlet API 2.5 and higher, this version of ObMimic honours @PostConstruct and @PreDestroy annotations, and @Resource annotations for fields and methods. However, it does not currently process any class-level @Resource annotations or any resource-injection annotations other than @Resource.

In addition, the processing of @Resource annotations is subject to a somewhat arbitrary interpretation of how such annotations should be processed on overridden and overriding methods, as the documentation for the @Resource annotation, “Common Annotations” in general, and Java annotations in general are somewhat unclear and contradictory on this. For further details and explanation, refer to the Javadoc of the com.openbrace.obcommon.lifecycle.AbstractObjectLifecycleManager class.

Note that explicit “manual” injection of the necessary resources should usually be possible even if the built-in processing of resource-injection annotations proves to be inadequate for any particular scenario.

More comprehensive handling of resource-injection annotations may be provided in future releases.

7.9  Temporary directories are not automatically provided

This version of ObMimic does not automatically provide each servlet context with a javax.servlet.context.tempdir context attribute pointing to a “temporary” directory. Any tests of code that requires such an attribute and temporary directory must explicitly configure this themselves.

7.10  Mimics are not Serializable

ObMimic’s Mimic classes are not serializable even where the interface or abstract class that they implement is Serializable. This is because the MimicState classes used within the Mimic classes are not themselves Serializable (and in some cases contain objects that are not easily serializable, such as java.io.OutputStream).

In this release of of ObMimic this only affects the GenericServletMimic and HttpServletMimic classes, as these are the only Mimic classes for Serializable classes. This is not expected to present any problems during normal use of ObMimic.

8  Bugs

An up-to-date official list of currently-known ObMimic bugs can be found at https://openbrace.16bugs.com/projects/3203/bugs.

To report a suspected bug or discuss an existing bug report, please use the “ObMimic Bugs” discussion forum at https://www.openbrace.com/forums/obmimic/bugs.html. OpenBrace will investigate and respond as appropriate, and raise or update a formal bug report where necessary.

9  Support

For technical queries, feature requests and other such support, please use the relevant ObMimic discussion forum at https://www.openbrace.com/forums/list.html. We monitor and participate in these forums, and they are normally the fastest and most effective way to contact us (and they also include “Private Messaging” facilities if you wish to contact us without posting a message in public).

Additional support and downloads are available for “Enterprise Edition” customers. Please see http://www.openbrace.com/main/pages/support/enterprise-support.html for details.

For any business-related queries, or to raise any other more general enquiries, or to make a complaint, please contact us directly at enquiries@openbrace.com or management@openbrace.com.

Further contact details can be found on our website’s “Contact Us” page at http://www.openbrace.com/main/pages/company/contact.html.

10  Uninstalling

To uninstall ObMimic:

  • Remove the OBMIMIC_HOME environment variable that you set up during installation (if any).
  • Delete the directory into which you installed ObMimic.

11  Further Information

For further information, please refer to: