Follow the steps outlined in the Fedora Installation Guide. If you plan to migrate digital objects from a repository that is a previous version of Fedora, be sure to configure the new Fedora 1.2 installation to run in parallel to the existing installation. After the new Fedora 1.2 is installed, you will run a migration utility that will unload all objects from your old repository and ingest them into your new repository. If you are installing Fedora 1.2 on the same machine as a previous version, make sure to set the following configurations for the Fedora 1.2 installation:

Follow the instructions in the Fedora Migration Utility Guide. to migrate digital objects from your previous Fedora installation to the new Fedora 1.2 repository. The new repository migration utility is provided with Fedora 1.2 to easily perform a mass export and mass ingest of objects from the old repository to the new repository. The repository migration utility can copy or move objects among Fedora 1.1, Fedora 1.1.1, and Fedora 1.2 repositories. If you are upgrading from Fedora 1.0, please first upgrade to Fedora 1.1 before installing Fedora 1.2 since the migration utility does not work with Fedora 1.0.

In Fedora 1.2 all operations of the Fedora management interface (API-M) are implemented. Operations for creating, modifying, inactivating, and deleting components of digital objects (i.e., Datastreams and Disseminators) are now available in the management web service via SOAP bindings.

The Fedora content versioning system is enabled with the release of Fedora 1.2. Now, any modifications made to a Datastream or Disseminator through the Fedora management interface (API-M) will automatically result in a new version of that Datastream or Disseminator being created by Fedora. The Fedora repository maintains all versions of all Datastreams and Disseminators, thereby creating a history of how objects change over time. Additionally, Fedora maintains an audit trail record of the nature of the object change events (e.g., who, what, when, why).

The new content versioning features can be easily accessed via new menu items in the Fedora Administrator client. The new object editor features (i.e., File/New, File/Open) provide the ability to create and maintain digital objects through a graphical user interface. Using these menu items, the user can create a new digital object, as well as add/modify/delete Datastreams and Disseminators, and view the different versions of these components. For details see the Fedora Administrator Client documentation and the Fedora Content Versioning documentation.

Building on the capabilities of the new content versioning features, the Fedora repository will now support time-stamped disseminations and API-A requests. This enables a client accessing Fedora to be able to request a view of a digital object as it looked at a particular point in time. The syntax for using date-time in access requests is documented in the Client Documentation for API-A and API-A-Lite as well as in the WSDL API documents.

The algorithm Fedora uses to evaluate date-time-stamped requests is an “as of date” approach, meaning that the repository will return a view of content as it looked “as of” a particular date-time. The date-time stamp provided by the client is interpreted by Fedora as a “ceiling” threshold. As such, the repository will evaluate the version dates on Datastreams and Disseminators and return the view of content that is as close to the requested date-time without being greater than the requested date-time.

A new migration utility is provided to perform mass export and mass ingest of objects. At the core, the migration utility is built upon two newly enhanced command-line functions: fedora-export and fedora-ingest. Used together, these two command line functions can support a variety of scenarios involving moving or copying objects between repositories. The utility is general-purpose in that it can be used to copy or move objects among repositories for many reasons including upgrading from previous releases of Fedora. Client access to the migration comes in two forms: (1) run fedora-export and fedora-ingest at the command line, or (2) use the Fedora Administrator client to invoke these functions (see menu items File/Ingest and File/Export). Please consult the Fedora Migration Utility Guide. to learn how to use the new migration functionality.

A Fedora repository will now accept PIDs that are externally generated. To enable this feature, the repository administrator must modify the “retainPIDs” configuration variable in the Fedora repository configuration file (fedora.fcfg). The “retainPIDs” variable is a configurable parameter on the DOManager module. It defines the set of PID namespaces that the repository will retain during digital object ingest. If the repository receives an ingest request for a digital object, and a PID is provided (i.e., in the ingest XML), the PID will be accepted by the repository as the official PID of the digital object if the namespace of the PID is listed in the retainPIDs configuration variable. If the namespace is not found in the retainPIDs variable, the repository will generate a new PID for the digital object (and disregard any PID that may have been provided).

In Fedora 1.2 the PID generation module has been exposed in the Fedora Management web service. Formerly, the PID generator was an internal module accessible only by other modules in the Fedora code base. Now, client can use the getNextID operation to request new PIDs from the repository. This is helpful in certain workflows where it is necessary to know ahead of time the PIDs of digital objects that are yet to be ingested into the repository, and there is a desire to have Fedora generate these PIDs. The getNextPID operation is part of the Fedora Management interface. At this time, the operation is exposed exclusively as a REST-oriented binding, meaning there is a specific URL syntax for requesting PIDs. See the WSDL API Documentation for API-M-Lite.

A number of enhancements have been made to the Behavior Definition and Behavior Mechanism builders that are found within the Fedora Administrator client application (see the Builders menu).

A log file is now produced for all output of the batch processing. Formerly, the results of batch processing initiated through Fedora Administrator were sent to the screen and could not be saved. Log files are deposited in a new directory at FEDORA_HOME/client/logs.

A minor enhancement has been made to the Repository Search/Browse tool that allows multiple objects to be selected from search results and to be purged without the user being required to enter a log message for each object. Now a single message can be entered for the whole set of objects, and the purge is activated over the whole selected set.

All XML formats that are used as to encode the results of Fedora API-A-LITE requests are now expressed as XML Schema. These schema files are located in the FEDORA_HOME\dist\server\xsd directory, and are also referenced in the schemaLocation attribute on the root element of Fedora XML responses.

Under rare conditions in some Windows XP installations, an obscure exception is thrown during object ingest that reports “unknown protocol c.” This bug was traced to the digital object validation module, specifically in the Schematron validation phase (see DOValidatorSchematron.java). The problem had to do with instantiation of stylesheets. In previous versions of Fedora, the Schematron preprocessing stylesheet was configured in the repository using a local file path to a location in the Fedora server (see fedora.fcfg). In some of the XP installations of Fedora, the XSLT processor had problems instantiating an XSLT stylesheet whose input location was defined with a file path. The problem was fixed by ensuring that all stylesheets are instantiated in a StreamSource object via a URL instead of file path.

In particular older versions of MySQL on the Windows platform there is a problem related to case sensitivity in database names that prevents database connections. Specifically, if a database is configured (e.g., via the Fedora mysql-config script) with a database name that is mixed upper and lower case characters, the database will not be recognizable at runtime. In these older versions of MySQL, the mixed case database name is accepted at configuration time, and loaded into the MySQL system tables. However, MySQL then creates the actual database directory on the filesystem with all lower case. Thus, at runtime, there is a mismatch between what’s listed in the MySQL system table and what’s on the file system. In these offending versions of MySQL, the database is not found due to this case sensitivity problem. The work-around for this is to use all lower case characters in the database name (e.g., "fedoraobjects" ) when performing the database configurations. However, since the problem is fixed in Windows MySQL 4.x and later, it is recommended that Fedora administrators install the latest production version of MySQL (currently 4.0.16).

Access to Datastreams via the Default Disseminator methods could fail for very large Datastreams in repositories running with limited memory. The problem was traced to sections of code in DefaultBehaviorImpl where the Datastream content was being passed as a byte array instead of as an InputStream. All code now streams content via InputStream classes.

When two clients were simultaneously ingesting objects into a repository, an ingest failure would occur if the ingest requests hit the repository at exactly the same time. The exception reported by Fedora was that “temp-ingest already exists” which means that the temporary PID named “temp-ingest” was already in use. The problem was fixed by having all temporary PIDS appended with a date-time stamp, rendering them unique within a running repository instance. Now multiple concurrent client processes can run ingests against the repository.

This has shown up periodically when clients are running searches via API-A-LITE. The problem was traced to a part of the code that was cleaning up stale search sessions. Java throws a ConcurrentModificationException exception when you are iterating over something and trying to change it at the same time. The solution was to build a separate list of to-be-deleted items while iterating through the session list, and then, when finished, remove the appropriate items from the session list.

Fedora OAI provider service was not escaping internal entities (e.g., ampersands). For example, if the Dublin Core record contains an ampersand, the OAI output only produced a single ampersand character instead of the escaped encoding. This is now fixed and entities are properly escaped.

If a datastream had a non-active state, it was still able to be disseminated via API-A and API-A-Lite. Inactive or deleted datastreams are not intended to be exposed via the Fedora Access interfaces. However, inactive datastreams are always discoverable via the Fedora Management interface. In this new release, only active (state=”A”) datastreams will be exposed via API-A and API-A-Lite. If a dissemination is run that involves a non-active datastream, the repository will throw an exception and provide a meaningful message.

Due to the way the relational database for the object cache was normalized, there was the potential for database corruption to occur in certain cases of purging objects. During purge, rows in the datastream binding map table could be inadvertently deleted during a purge object operation when there were still other objects depending on those rows. New referential integrity checks have been put into the database replication module to ensure that this will not occur.

The format being used to initialize the DateTimeStamp was using the 12-hour clock setting instead of the 24-hour clock setting. This is fixed now and all DateTimeStamp values use the 24-hour clock format.

If the example soap client was installed on a different host than the Fedora server, API-A requests would fail to display the transformed xml-to-html results. This was caused by a typographical error in the name of the stylesheet parameter in soapclient properties file that conveyed the Fedora server hostname. This is fixed now and example soap client can be run on any host.

Mckoi-stop.sh script was ignoring environment variable for FEDORA_JAVA_HOME. This is fixed now.

Attempts to disseminate datastreams that are of type "R' caused the soap client servlet to throw ServletException. This was caused by a ServletOutputStream being closed prematurely in FedoraAccessSOAPServlet. This is fixed now and Redirected datastreams can be disseminated using the soap client.

Reworked bmech builder class action listeners to keep bmech template object update in memory for every change to tabpane. This fixes bug where ds binding keys don't stay updated properly in pre-load of dsinput pane. Also, various other improvements in validation. Fixed bug where methodURL fields for the method being created did not property clean out when change among radio buttons occured (to change the URL from service base, to local service, to multiserver). Previously if you started things off with a service baseURL, then entered the baseURL, then changed to a LOCAL service or multi-server, the baseURL would still be hanging out in the method URL fields.

A Datastream data type was being erroneously cast as a String which caused the Exception. This has now been fixed so that ListDatastreamIDs returns the appropriate list of datastream IDs.

In a METS XML file used for ingest, object state is encoded on the RECORDSTATUS attribute of the METS header element. If this value is populated on the ingest file, the Fedora repository will accept it as is. Therefore, if the value of RECORDSTATUS is set to anything other than “A” (Active), the object will NOT be accessible via the Fedora Access interface. In other words, the object will not be considered active, and it will not be able to be disseminated. If objects are ingested in the inactive state, the state can be modified via the new object editor in the Fedora Administrator client (see menu item File/Open Object).

The problem shows up only in Linux when running MySQL v4.0.12. Specifically, if a purgeDisseminator operation is run in the Fedora repository the problem is provoked. Normally, the purgeDisseminator operation removes a disseminator from a Fedora object XML store, and also initiates a replication process to make sure the disseminator is removed from the relational database object cache. Internal to the Fedora code, an SQL delete query is run via JDBC. The bug occurred when a the delete query was run. The query uses a where clause that should dependably evaluate to FALSE (i.e., “WHERE 1=2”), but in this particular version of MySQL under Linux, the query curiously and erroneously evaluates to TRUE. This particular query is intended to prevent certain rows from being deleted from the database. Instead rows are deleted resulting in referential integrity problems in the database. The solution to this problem is to upgrade to MySQL v4.0.14 or higher which does not have this bug!

Due to a type definition change in the WSDL for API-A, the SOAP binding for the field search operation (i.e., findObjects) in not backward compatible across prior releases of Fedora. Thus, a search initiated via API-A (using SOAP) from a Fedora 1.2 client can not be fulfilled by a Fedora 1.1 or 1.0 server. In the WSDL for API-A, the findObjects operation defined a return type of fedora-types:FieldSearchResult (which is an array of fedora-types:ObjectFields). Formerly, fedora-types:ObjectFields defined an element named “locker.” In Fedora 1.2, that element is now defined as “owner.” Such interface changes are not accommodated by the Apache Axis library used to process SOAP requests. Fedora does not currently maintain different versions of its WSDL, so the change occurs in the “official” WSDL for the Fedora Access service. The problem can be bypassed by clients using the REST-oriented binding for the findObjects operation (see API-A-Lite in Fedora 1.2). The REST-oriented binding provides for a looser method binding, and allows the XML result be returned without type checking.

(see release notes for Fedora 1.1).

The bug was an errant update query for the SQL database that when modifying a datastream it had the potential for corrupting the SQL database dsBind table. It only got introduced when attempting to modify a Datastream using the View/EditDatastream menu option in the admin GUI. With this fix, the modifyDatastream command is safe to use.

OAI-PMH interface was not sending the correct HTTP Content-type header value to indicate the character encoding of the XML, and as a result, the Servlet that provides OAI-PMH functionality was not properly encoding the output in UTF-8.

It is now possible to change a managed content datastream's label without changing its content. Previously, the API-M method, modifyDatastreamByReference required that something was provided for the DSLocation. Now, if DSLocation is passed in a null or empty, the original datastream content will be used (no change).

The API-A and API-A-LITE interfaces now define and implement the “describeRepository” request. This request will provide information about the repository server including repository name, version, base URL, and other attributes. The repository information can be obtained in either XML or HTML formats.

The API-A-LITE syntax is: http://yourhost:yourport/fedora/describe

The Fedora server now has internal support for avoiding breakage of self-referential URLs (i.e., URLs that contain the hostname and port of the Fedora server itself). This change allows the Fedora server host and port to be re-configured without breaking digital objects that contained URLs that referred to a previous host and port configuration. There are two places where self-referential URLs may exist: (1) in Behavior Mechanism Objects, where service bindings refer to a “local service” that runs within the repository server, and (2) in objects that contain a Datastream that references a dissemination of a digital object that is stored in the local repository.

Java Docs will now show the revision number generated from the Fedora CVS repository. These will not reflect the current Fedora software release number, but the actual version of the particular java source file. This will make it easier to determine whether a particular piece of code has changed from one Fedora release to another. For example, the source file FedoraAccessServlet.java has a release number of 1.58 as distributed within the Fedora 1.1 software.

All non-essential debugging and logging messages were removed from standard out. All meaningful server messages are now sent to the Fedora server log file.

The Fedora server now has support for Oracle 9i. See Fedora system documentation for details..

Specifically, a failure in running the Batch Build and Batch Build and Ingest menu items in the AdminGUI client when running the client in X-Windows. The batch utility could not correctly resolve file locations of object-specific files.

REPORTED ERROR: Recoverable error. java.net.UnknownHostException

FIX: The problem was traced to line 196 of fedora.client.batch.BatchXforms and has to do with the number of slashes in the file path (i.e., file:///). Solaris (and perhaps UNIX in general) wants only 2-trailing slashes instead of three. Places in the code where this has been a problem have been modified to ensure that any such URL strings are instantiated as a java.io.File object, then converted to a java.net.URI object. The URL string is finally obtained via the toString() method of the java.net.URI class. The strings generated in this manner are acceptable on both Windows and UNIX platforms.

The problem occurs because the METS xml files for the demo digital objects contain URLs that assume that the repository is running on port 8080. The URLs point to the location of the demo content that is served up by the local repository server.

REPORTED ERROR: [DefaultExternalContentManager] returned an error. The underlying error was a fedora.server.errors.StreamIOException The message was "Server returned a non-200 response code (404) from GET request of URL: http://localhost:8080/demo/batch-demo/thumb/americanacademy.jpg"

FIX: There are two kinds of demos that are affected: “batch demos” that are loaded via the batch tool and “local server demos.” The content for the batch demos has been moved to www.fedora.info where it will always be available. The METS xml files for the batch demo objects now have URLs that point to the demo content at this stable location. The “local server demos” are intended to be run completely within the local server context (meaning a network connection is not necessary to run them). The content for these objects must, therefore, remain local to the Fedora server. A new command line utility called “fedora-convert-demos” is provided to convert demo object xml files to reference the currently configured host and port. If the Fedora repository is configured to a host and port other than the default of localhost:8080, the “fedora-convert-demos” utility should be run before ingesting local demo objects into the repository. The “fedora-convert-demos” is found in the FEDORA_HOME/client/bin/ directory. Instructions on running the utility can be found in the Client Documentation section of the system documentation.

The Fedora server fails during initialization of the DefaultAccess module. DefaultAccess tries to use a dependent module (DOManager) that has not yet been loaded by the Fedora server. The problem does NOT occur in Java 1.4.0 or 1.4.1.

REPORTED ERROR: Can't get a DOManager from Server.getModule

FIX: DefaultAccess is a server module, that itself needs access to other server modules. The DefaultAccess module initialization fails because DefaultAccess tries to access a dependent module (DOManager) that has not yet been loaded by the server. The problem is that server modules are not loaded in any particular order on server startup. Within any particular module’s initModule method, you can't assume that ANY other modules are available from the server via the getModule(...) call. The solution is to move chunks of code like this to the postInitModule(...) method of the module in question. At THIS point in the server's lifecycle, you can assume that all modules have been loaded and are available via getModule(...), and that their initModule(...) methods have been called. Fedora server modules are listed in a HashMap. The reason that this problem showed up in Java 1.4.2 and not prior versions is that the order in which entries are put in a HashMap has changed in Java 1.4.2. It was just coincidence that the problem did not show up in prior Java versions (that loaded the HashMap in a different order.)

There were several places in the Fedora 1.0 code base where the default host and port of the server was hard-coded as “localhost:8080”. This required the repository administrator to make multiple changes when configuring a Fedora server to run on a different host or port.

FIX: All references to hostname and port are now driven off the fedoraServerHost and fedoraServerPort parameters in the Fedora server configuration file (fedora.fcfg). With this fix, a simple modification to these parameters and a re-starting the server is all that is necessary to change where the fedora server runs.

The Fedora server shutdown and redirect ports were not configurable. They were hard-coded in the Tomcat server_template.xml file as “8005” and “8443” respectively.

FIX: These are now configurable in the Fedora server configuration file (fedora.fcfg).

The repository domain name part of the OAI identifier was not configurable. It was hard-wired to be “fedora.info” which is not unique to a repository.

FIX: The Fedora server configuration file (fedora.fcfg) now has a repository domain name parameter in the OAI-PMH module.

Fedora 1.0 and 1.1 servers are unable to mediate access to remote datastreams that are password-protected. Currently, Fedora provides IP restriction for its own interfaces (API-A and API-M). However, at this time, it does not handle backend security handshakes with remote servers. Thus, when a digital object makes reference to a datastream on a remote server and that server protects its content with HTTP Basic Authentication, Fedora will not be able to negotiate with the remote server to access that content. The way around this is to make sure that such datastreams are marked with as type R (Redirected Content). This is done in the METS XML file by setting OWNERID=R on the METS file element that used to encode the datastream.

Fedora 1.0 and 1.1 servers cannot currently communicate with external web services that require the SOAP messaging protocol. This means that Behavior Mechanism Objects should not include WSDL that describes a service with SOAP bindings. In the current release, Fedora is able to communicate with web services that can be accessed via URLs using a simple HTTP GET (REST-style web services). The next release of Fedora will include a SOAP dispatching module which will enable the Fedora server to send SOAP requests to other services and receive SOAP responses from those services.