Fedora™ Release Notes

Fedora™ Development Team

$Id: release-notes.dbx,v 1.34 2004/04/20 00:57:29 cwilper Exp $

Table of Contents

Release 1.2.1 (Bug Fix Release) - April 19, 2004
Release 1.2 - December 15, 2003
Release 1.1.1 (Bug Fix Release) - September 5, 2003
Release 1.1 (Bug Fix Release) - August 5, 2003
Release 1.0 - May 16, 2003
Release 0.9 - March 7, 2003
Beta 1 - Dec 20, 2002
Alpha 1 - Oct 31, 2002

Release 1.2.1 (Bug Fix Release) - April 19, 2004

Fedora 1.2.1 provides fixes to several bugs that were reported by users of Fedora 1.2. The new release is backward compatible with Fedora 1.2 and contains no changes to the underlying database schema.

IMPORTANT!! - Migrating From Fedora Releases Prior to Fedora 1.2

Users wishing to migrate from releases prior to Fedora 1.2 need to follow the steps outlined in Release 1.2 - December 15, 2003 and migrate to version 1.2 BEFORE attempting migration to Fedora 1.2.1.

Migrating From Fedora 1.2 to Fedora 1.2.1

If you are upgrading from Fedora 1.2:

  • Shut down your existing repository using the fedora-stop command.

  • If you are using mysql, look at the new installation's config/fedora.fcfg file. Find the line that contains the word "autoReconnect". Open your old config/fedora.fcfg file and edit the jdbcURL parameter so it ends similarly (with "&autoReconnect=true").

  • Copy your old config/fedora.fcfg over the new one.

  • If you were using the bundled mckoi database with your previous installation, stop it with mckoi-stop. Then go to the mckoi094 directory in the new release and create a directory there called "data". Next, copy all mckoi094/data files from your previous installation to the NEW mckoi094/data directory. (If you previously modified the db.conf file, copy that over to the new mckoi094 directory, too)

  • Update your FEDORA_HOME environment variable to point to the new installation's location.

  • Update your PATH to point to the new FEDORA_HOME/client/bin and FEDORA_HOME/server/bin directories.

  • If you are using mckoi, start it now with mckoi-start.

  • Start the server as you normally would, with fedora-start.


1. Errors in installation document regarding source installations. (Bugzilla # 3)

The installation document has been updated to say that the JAVA_HOME environment variable must be set prior to installing the source distribution since ant requires this environment variable to perform the build. A typographical error regarding changing the permissions on the ant executables has been corrected to read: "This can be done with the command: chmod 755 $FEDORA_DEV/res/ant/bin/*."

2. Admin GUI client - Purge Failure error message text does not wrap. (Bugzilla # 5)

When an error is encountered while attempting to purge an object, the error message displayed in the message pane does not properly wrap and scrolls off the edge of the window. This has been modified to properly wrap the message text so the complete message is visible regardless of length.

3. Admin GUI client - Purging object does not close object paneI in ObjectEditor. (Bugzilla # 6)

When viewing an object using the ObjectEditor and then clicking the purge button, the object is removed from the repository, the object pane remains on the screen. The admin GUI client has been modified so that the object pane is now closed when the object is purged.

4. Admin GUI client - New Dialog Enhancement Request . (Bugzilla # 7)

In the New object creation dialog, one enters label text and content model text and clicks "create" to ingest the object. Pressing the ENTER key instead of clicking the "create" button has no affect. This has been changed so pressing the ENTER key now has the same result as clicking the "create" button on NewObjectDialog pane.

5. OAI day-granular "until" parm taken as midnight beginning that date. (Bugzilla # 9)

For OAI requests, the code interprets both "from" and "until" parms (which both have day-granularity) as meaning midnight beginning that date. This is correct for the "from" parm only. The day-granularity "until" parm should be interpreted as "23:59:59pm ending that date". That way, an OAI request with equal day-granular "from" and "until" parms will return records for that date. Changes have been made regarding the way that the OAI "until" date parm is handled when using "Day" granularity. If Day granularity is being used, the date value for the Until date parm is modified to be Day + 23:59:59. This means that when using Day granualrity, specifying the same Day for both "from" and "until" date parms will result in matching all dates between 00:00:00 and 23:59:59 on that day.

6. Admin GUI client - Export dialogs are incomplete under MAC OSX implementation. (Bugzilla # 10)

This problem shows up only on MACs in exports from an opened object. In contrast, the dialogs from both File and Export submenus (export one object, export by type) do work correctly, as with Windows. These correct cases are where the filename is selected programmatically (i.e., pid.xml). Exports from an opened object (either to export the object as xml or to export a datastream of the object) give dialog boxes which lack filename fields so the user has no opportunity to select the filename. Navigating with the dialogue to a directory with an existing file needs to match the needed mimetype, and selecting that file will result in overwriting that file's contents with either the object xml or the datastream contents, but without changing the filename. The JFileChooser dialog was not allowing entry of filenames in cases where that should be possible. The workaround was to, for these specific cases, default to the platform's native file dialog by using java.awt.FileDialog. Note that using the platform's native dialog is not a solution for all file dialog-related actions. JFileChooser still needs to be used in some cases because it has an option to only allow the choosing of directories, whereas FileDialog is limited in this regard.

7. Admin GUI client - Log file generated when ingesting objects by type is incorrectly persistent. (Bugzilla # 11)

When performing multiple ingest objects by type operations in the same admin client session, the log file displayed for subsequent ingest objects all show the log file from the initial ingest object operation. Closing the admin client between ingest object operations produces the expected results. This behavior is a result of the code checking to see if the log PrintStream is null to decide if a new log file is to be generated. If null, a new log is generated, otherwise it assumes there is an existing log to be displayed. Although the closeLog method in fedora.client.ingest.Ingest closes the log PrintStream(s_log), it does not get immediatley garbage collected so can have a non-null value for some time period after being closed. The code has been modified to explicitly set the PrintStream to null after being closed to resolve this issue.

8. Admin GUI client - After deleting disseminator using ObjectEditor, the bdef drop down list is not refreshed. (Bugzilla # 12)

If you open an existing object, delete a disseminator, then try to re-build the disseminator in the same session, the drop down list of behavior definitions does not include the bdef that was associated with the disseminator that was just deleted. If you exit the object editor after deleting the disseminator, then re-open the object in the editor, then the bdef becomes available again in the drop down. The code has been updated to refresh NewDisseminatorPane after a purge so the bdef used by the purged disseminator is visible once again in the drop down list of bdefs.

9. Fedora search not accepting underscores. (Bugzilla # 13)

The use of the underscore (_) character in Fedora searches generates an error that varies depending on the sql database being used. There was some obsolete code involving the syntax of the WHERE clause for Search queries where a special string " { escape '/'} " was appended to the end of any WHERE clause search string containing special characters that required escaping according to the SQL92 syntax rules. This code is no longer required and has been removed so underscores in searches no longer produce an error.

10. WSDL documentation - Inline wsdl docs for api-m.ingestObject mention incorrect state. (Bugzilla # 14)

The wsdl docs inside the Fedora-API-M.wsdl file say that upon ingest, an object's original state is "N", which is wrong. It should be "A". The comments in API-M.wsdl for ingestObject and createObject have been updated to reflect that the initial state of object is set to "A".

11. API-M addDisseminator method - addDisseminator method fails to update sql db when more than one pre-existing disseminator. (Bugzilla # 16)

When creating an object using the admin GUI client that has one or more existing disseminators, adding a new disseminator adds the disseminator to the object xml, but fails to properly replicate the disseminator in the sql database. This was a bug in DefaultDOReplicator that caused improper updating of the sql database in the case where a new disseminator was added to a data object, via the addDisseminator method of API-M, where the object had one or more pre-existing disseminator(s). The result was a mismatch between the xml representation of the object and the sql database representation. This problem has been corrected.

12.Admin GUI client - List of MIME types for XMLMetadata displays types other than text/xml when adding multiple datastreams. (Bugzilla # 17)

In the Admin GUI client, the MIME type drop down menu should only list text/xml when the XMLMetadata radio button is checked. This is true when the "new Datastream" button is clicked for the first datastream. However, if the datastream is saved, and another new datastream added, the MIME type list shows MIME types other than text/xml when the XMLMetadata radio button is checked. The code has been modified so that only MIME tpyes of text/xml are displayed for datastreams of type XMLMetadata.

14. Demo Objects - Label for DC datastream of demo object obj-ead-finding-aid.xml incorrect. (Bugzilla # 20)

The demo object (demo:17) for the Rita Mae Brown finding aid has an incorrect label when you do a viewItemIndex. The DC record's label is shown as "DC Record for Pavillion III Architectural image object" which is wrong. However, when you click on that link, the underlying xml looks correct. The label for demo object demo:17 has been corrected.

15. Search - resumeFindObjects skips next result in sequence. (Bugzilla # 21)

When displaying search results that spanned more than one screen, the search interface will skip over the first entry on the next screen. For example, if the maximum number of search hits to display is 10 and there are 30 hits, the search will display hits 1-10, then 12-21, and then 23-30 omitting hits 11 and 22. This was a bug in fedora.server.search.FiledSearchResultSQLImpl where the cursor in the ResultSet was being positioned incorrectly when there are more results to display than the specified maxResults value. The cursor is now correctly positioned and all hits are displayed.

16. Admin GUI client - Adding/removing datastream bindings in Admin GUI client result in broken disseminations. (Bugzilla # 24)

Removing and then re-adding a datastream binding in admin gui for a disseminator breaks the dissemination for that disseminator. XML representation of the object appears correct, but disseminations handled through sql database are broken. This was a bug in fedora.server.storage.DefaultDOReplicator that had to do with the improper updating of dsBind table when the binding map of an existing object was altered. The xml was correct after the update, but replication was incomplete on the sql database. The end result before the fix was an incomplete update of the dsBind table which had the effect of breaking disseminations for that object because of missing bindings in dsBind table. This has been corrected.

17. Admin GUI client -The state of datastreams is reset to Active in sql db when binding datastreams to a disseminator. (Bugzilla # 25)

If a datastream has a state other than Active and it is bound to a disseminator or if already bound and the binding is removed/re-added, the state of the associated datastream is reset in the sql db to Active. This was a bug in fedora.server.storage.DefaultDOReplicator that had to do with the updating of dsBind table when creating or modifying datastream bindings. The datastream state is correct in the xml, but the replication is incorrect in the sql database. Before the fix, the state of the updated bindings was always being set to "A" so if the state of a datastream was other than "A" and a binding that used that datastream was created/modified, the state in the sql database was reset to "A". The state of the datastream in the xml is now used to set the state when creating or updating a binding map. This guarantees that the state in dsBind table will always be the sameas that of datastream in xml.

18. Batch Utiltity - Sample mets-template.xml used in batch utility demo contains metadata wrapper errors. (Bugzilla # 25)

Some of the METS metadata wrapper elements in the mets-template.xml example file used with the batch utility are incorrect. e.g., administrative source metadata is in a techMD wrapper element. The typographical errors have been corrected in the sample template file.

19. Oracle open_cursor limit exceeded (Bugzilla # 29)

Users implementing Fedora with Oracle reported that the database would hang when attempting deletes of large numbers of objects. The database hang was the result of exceeding the open_cursor limit set by the database. This problem has only been reported with Oracle. There are apparently some subtle differences between the various JDBC drivers and how they handle cleanup when a ResultSet or Statement is closed. The JDBC code has been modified to better handle these variations and address the open_cursor problem for Oracle users.

20. FedoraMets ID lengths - ID lengths silently ignored. (Bugzilla # 30)

Fedora stores the definitive copy of objects as xml, but for performance also replicates a copy of objects in an sql database. With xml, there are no limitations on the length of attribute values or content. However, the sql database does impose field lengths which restrict the length of identifiers and labels. Users reported the truncation of some identifers in the sql database as a result of having identifier strings in the xml that exceeded the database schema field lengths. The xml validation code has been modified to verify the length of Fedora identifiers. Exceptions are now thrown at ingest time if any identifiers in the xml exceed the field lengths specified for those fields in the database schema. Currently, the validation is only applied to identifiers. Descriptive fields like labels, will be be truncated if they exceed the database schema field lengths. We will consider extending the validation checking to labels in the next release.

Release 1.2 - December 15, 2003

This new release contains a number of significant new features, including content versioning, the complete implementation of the Fedora Management interface, and major additions to the Fedora Administrator client to enable object creation and editing. With the advent of content versioning, the Fedora Access interfaces now support date-time stamped requests, so that a client can "go back in time" and see a digital object as it looked in the past. Additionally, this release provides a migration utility for mass export and mass ingest of objects from either directories or other repositories. The migration utility enables the moving of objects from older versions of Fedora repositories into the lastest version. It also is of general utility for copying or moving objects among repositories, for unloading repositories, and for bulk ingest of objects.

IMPORTANT!!! Upgrading From a Previous Release of Fedora

Although Fedora 1.2 is backward compatible with previous versions of Fedora at the interface definition level, there are changes to the underlying database schema that require digital objects to be migrated from an old Fedora installation to the new Fedora installation. If you want to keep digital objects from an old repository and migreate them to the new Fedora 1.2 repository, you must run the migration utility provided with Fedora 1.2. DO NOT INSTALL FEDORA 1.2 ON TOP OF THE PREVIOUS RELEASE. To upgrade from a previous release and migrate digital objects into the new repository follow these steps:


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:

1. install Fedora 1.2 into a different directory than the previous installation (set $FEDORA_HOME environment variable accordingly)

2. initialize a new database for Fedora 1.2 using the database configuration scripts which are set up with new defaults. If using MySQL, run mysql-config.bat (.sh for unix) with the new default database name of “fedora12” (or your own new database name that differs from the name used in your pre-existing Fedora installation. For McKoi, run the mkoi-init.bat (.sh for unix) which has a new default port number for Fedora 1.2.

3. set a different port for Fedora 1.2 to run on (fedoraServerPort in the Fedora config file fedora.fcfg)

4. set a different shutdown port for Fedora 1.2 (fedoraShutdownPort)

5. set a different redirect port for Fedora 1.2 (fedoraRedirectPort)

6. set a different storage path for digital objects (object_store_base)

7. set a different storage path for datastreams (datastream_store_base)

8. set a different storage path for temporary files (temp_store_base)

9. set the Fedora 1.2 repository to allow the PIDs from the old repository to be accepted (add namspaces to retainPIDs in fedora.fcfg)

10. if the OLD Fedora installation is running on a different machine, modify the fedora configuration file of the OLD Fedora installation to requests to be made by the new Fedora 1.2 repository. (Add IP address of Fedora 1.2 repository to allowHosts in fedora.fcfg of OLD repository.)


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.


1. Fedora Management Interface (fully implemented).

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.

2. Content Versioning.

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).

3. Fedora Administrator – Object Editor and Version Viewer.

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.

4. Date-Time-stamped Access Requests.

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.

5. Migration Utility.

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.

6. Externally-generated PIDs Accepted by Repository.

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).

7. PID Generation via Management Interface (getNextPID).

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.

8. Fedora Administrator – Behavior Definition/Mechanism Builders.

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. Service profile for Behavior Mechanism Objects. A tab pane for entering metadata about the service that is represented by a Behavior Mechanism object is now available. The service profile metadata consists of information about the technologies that underlie the service, the valid input and output formats of the service, and other technical metadata.

b. Selection of behavior contract for a Behavior Mechanism Objects. A drop-down list of all the Behavior Definition objects in the connected repository is provided in the Behavior Mechanism builder. The user can select a Behavior Definition as the behavior contract when building Behavior Mechanism objects. The methods defined by the Behavior Definition objects are pre-loaded into the builder tool to assist in building a Behavior Mechanism object.

c. Various enhancements. Help buttons, better table entry for Dublin Core records, better management of dialog windows (e.g., no lost windows outside of main frame), minor bug fixes, and cosmetics.

9. Fedora Administrator - Batch Utility enhancement.

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.

10. Fedora Administrator - Easier purge for multiple objects.

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.

11. XML schemas for all Fedora-generated XML.

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.


1. Ingest exception “unknown protocol c” in Windows XP.

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.

2. Failure on database connections with MySQL 3.23.53-3.23.58 on Windows.

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).

3. Datastream size limit problem via Default Disseminator requests.

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.

4. Concurrent ingest failure.

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.

5. ConcurrentModificationException on API-A-LITE.

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.

6. OAI provider service not escaping characters properly.

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.

7. Dissemination of Inactive or Deleted Datastreams.

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.

8. Possible Database Corruption as Result of Purging Objects.

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.

9. DateTimeStamp Using 12 Hour Clock Schema.

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.

10. API-A Not Functional With Example Soap Client When Running On Different Host (12/2)

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.

11. Mckoi-stop.sh Ignoring FEDORA_JAVA_HOME

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

12. FedoraAccessSOAPClient Returns ServletException When Disseminating Datastreams of Type "Redirected"

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.

13. Minor Bug Fixes to BDef/BMech Builder

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.

14. ListDatastreamIDs in FastDOReader returns ClassCastException

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.

KNOWN ISSUES (and ways to avoid them):

1. Setting Object State on Ingest XML.

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).

2. Bug in MySQL v4.0.12 on Linux causes database corruption.

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!

3. Field Search via API-A (SOAP binding) not backwards compatible.

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.

4. Behavior Mechanisms with SOAP Bindings Not Yet Supported.

(see release notes for Fedora 1.1).

Release 1.1.1 (Bug Fix Release) - September 5, 2003

Fedora 1.1.1 provides a fix for bugs detected by users of Fedora 1.1.

The new release is backward compatible with Fedora 1.1. If you are updating from an earlier release, please refer to the release notes for Fedora 1.1 regarding backward compatibility issues and new features introduced in Fedora 1.1


1. SQL DB Corruption During Datastream Modification

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.

2. OAI-PMH Unicode Support

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.

3. API-M Managed Content Modification

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).

Release 1.1 (Bug Fix Release) - August 5, 2003

Fedora 1.1 provides fixes to several bugs that were detected by users of Fedora 1.0. It also provides a new API-A method (“describeRepository”) that enables a client to obtain information about the repository server.

The new release is backward compatible with Fedora 1.0, with the exception of the Fedora server configuration file. If you are upgrading from Fedora 1.0, use you will need to enter your configuration values from the old Fedora 1.0 configuration file into the new configuration file provided with Fedora 1.1.

Aside from this, the Fedora 1.1 software is compatible with pre-existing digital objects created in Fedora 1.0. There is no need to re-create or convert existing digital objects. Fedora 1.1 can be configured to point at the existing file system location where Fedora 1.0 objects are stored, and to the existing relational database that contains information about the digital objects.

** REMEMBER: Do NOT use the Fedora 1.0 server configuration file (fedora.fcfg) with the new Fedora 1.1 release.


1. New API-A Method For Repository Info.

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

2. Server Support For Self-Referential URLs.

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.

3. New Source Code Revision Numbers.

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.

4. Suppression of Messages in Standard Out.

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.

5. Oracle 9i Support.

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


1. Failure of Batch Client Utility in UNIX Environment.

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.

2. Unable to Ingest Demo Objects when Fedora Server NOT on Port 8080.

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.

3. Failure of Server Start-up when Running with Java 1.4.2.

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.)

4. Hard-coding of Defaults for Server Host and Port.

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.

5. Fedora Shutdown and Redirect Ports Hard-coded.

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).

6. OAI Identifier was NOT Configurable.

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.


1. Remote Password-protected Datastreams Need to be Redirected:

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.

2. Behavior Mechanisms with SOAP Bindings Not Yet Supported:

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.

Release 1.0 - May 16, 2003

This release is the first public release of the Fedora repository system. Fedora is licensed under the Mozilla License. Refer to the README and COPYING files in the distribution for details of the license and restrictions governing copying and redistribution. This release includes some major changes since release 0.9 that include the following additions and enhancements.

1. Behavior Definition and Behavior Mechanism Object Builder

A new tool has been added to the Admin client that facilitates the building of behavior definition and behavior mechanism objects. The bdef/bmech builder provides a graphical user interface that greatly simplifies the task of creating behavior definition and behavior mechanism objects from scratch.

2. Additional Component Management Method Implemented

Several additional methods in API-M have been implemented. The new methods include

  • GetDatastream – retrieve the specified datastream

  • GetDisseminator – retrieve the specified disseminator

  • ListDatastreamIDs – obtain a list of datastream IDs

  • ListDisseminatorIDs – obtain a list of disseminator IDs

  • ModifyDatastreamExternal – change the pointer to a Referenced External Content datastream

  • ModifyDatastreamManagedContent – change the contents of a Managed Content datastream

  • ModifyDatastreamXMLMetadata - change the contents of an Implementor-Defined XML Metadata datastream

  • modifyDisseminator - modify the references to the behavior definition or behavior mechanism associated with the specified disseminator

3. Batch Utility Enhancements

The Batch Utility has been enhanced to make it less platform specific: all application files are now specified relative to the FEDORA_HOME environment variable. Also, a new tool has been added, combining build and ingest into a single step.

4. Documentation

The Fedora documentation now includes revised and enhanced Installation Guide, Release Notes, Manual, and Demos Guide. The Fedora manual includes a general introduction to the architecture, Installation Guide, User’s Guide, and Developer’s Guide. Upon successful installation, all documentation is also available through the userdocs webapp and can be access using the syntax:


  • hostname - required hostname of the Fedora server.

  • port - required port number on which the Fedora server is running.

  • userdocs - a required parameter specifying the Fedora servlet path hostname - required hostname of the Fedora server.

In-line documentation in the source code has also been updated.

Release 0.9 - March 7, 2003

This release includes major changes since the December Beta1 release that include the following additions and enhancements.

1. Repository-Managed Content Datastreams

The implementation of Repository-Managed Content datastreams has been added. Repository-Managed Content is used for datastreams that are to be under the complete control of the Fedora repository. Upon ingestion, content that is referenced in the Fedora-METS "file" element is copied to an internal storage location in the Fedora server and the external pointer in the Fedora-METS object is updated to reflect the new internal storage location. Repository-Managed Content should be used in cases where it is desirable for datastream content to be stored and managed locally within the Fedora server. The repository manager must insure that there is sufficient disk space allocated to accommodate the ingestion of objects containing Repository-Managed Content.

2. Implementor-Defined XML Metadata Datastreams

The implementation of Implementor-Defined XML Metadata datastreams has been added. XMLMetadata datastreams represent user-defined XML-encoded metadata that is included in-line in the "amdSec" and "dmdSec" elements of the Fedora-Mets object. Although these datastreams are included in the metadata section of the Fedora-METS object, they can be disseminated just like the regular datastreams included in the "fileSec" element. Implementor-Defined XML Metadata datastreams should be used in cases where it is desirable to include user-defined metadata in-line in the Fedora-METS object. The Dublin Core metadata datastream is an example of an Implementor-Defined XML Metadata datastream (see Search Interface note).

3. API-A-Lite Interface

A new Fedora Access interface has been implemented known as API-A-Lite. API-A-Lite provides a streamlined implementation of the Fedora Access API over HTTP. The new interface provides two methods: GetDissemination, and GetObjectProfile. GetDissemination is used to request disseminations using HTTP. GetObjectProfile uses object reflection to provide a description of an object and its components.

4. Search Interface

The implementation of a new search interface has been added. Upon ingestion, metadata from the Fedora System Metadata section and the Dublin Core (DC) Metadata section of the object are indexed in a relational database, and may be searched using this interface. The DC Metadata section is an optional Implementor-Defined XML Metadata datastream in the object, where the "Datastream ID" is DC, and the XML conforms to the schema at: http://www.openarchives.org/OAI/2.0/oai_dc.xsd. If such a datastream is not provided, only the System Metadata will be indexed for that object. The search interface provides both simple and advanced searching via a web page included with the repository software. All queries are case insensitive. Simple search enables queries of words and phrases occurring anywhere in an object s indexed metadata fields. Advanced Search enables fielded searching across any combination of metadata elements using string comparison operators (= and ~) for string fields, and value comparison operators (  =, >, ≥, <, ≤  ) for date fields (dc:date fields may be treated as both). The wildcards, * and ? may be used in any string-based query.

5. OAI Provider Interface

The implementation of an OAI-PMH2.0 Provider interface has been added. OAI-PMH is a standard for sharing metadata across repositories. Currently, only the Dublin Core metadata for each object may be disseminated via this interface.

6. Access Control and Authentication

Although Access Control is not slated until year two of the project, the implementation of a simple form of access control has been added to provide a minimal level of security. IP range restriction is supported at both the Management API and the Access API exposures. The fedora.fcfg configuration file contains two new optional parameters in the Access and Management Modules named "allowhosts" and "denyhost" that are used to provide a comma delimited set of IP ranges. By default, the Management API is restricted to the IP address of the local host and the Access API is unrestricted. In addition, basic authentication is supported for API-M client-to-server communication. The client scripts and fedora-admin GUI have been modified to take a username and password at startup. Only one user, the super user "fedoraAdmin", is supported at this time. The password for fedoraAdmin is configured in fedora.fcfg.

7. Server Port Configuration

Server administrators can now more easily configure the port on which the Fedora server is exposed. The port is set in fedora.fcfg. Its default is 8080.

8. METS Extension

To accommodate some of the new functionality in Fedora, it was necessary to extend the METS schema. Fedora-METS objects are now validated against this extended version of METS. The extended schema, mets-fedora-ext.xsd, is available at dist/server/xsd/ and contains inline comments where changes were made. Other constraints for the objects, expressed in schematron, are available in the dist/server/schematron/ directory. The demonstration objects act as useful examples in understanding this schema.

9. Default Disseminator

The implementation of a new Default Disseminator has been added. Prior to this release, a data object could not be disseminated without first constructing and ingesting a behavior definition and behavior mechanism object. The Default Disseminator is a built-in internal disseminator on every object that provides an internal behavior mechanism for disseminating the basic contents of an object. The Default Disseminator does not replace Behavior Definition and Behavior Mechanism object. Instead, it provides a simple way for viewing the contents of an object without having to construct a separate Behavior Definition and Behavior Mechanism object. Behavior Definition and Behavior Mechanism objects are still required for creating disseminations that provide more complex sets of behaviors.

10. Storage Subsystem Enhancements

The code supporting the Java instantiation of Fedora Digital Objects inside the server has been re-worked so that serialization and deserialization are completely de-coupled from the Java interfaces to the objects: the DOReaders and DOWriters. Method names have also been changed to be more meaningful and consistent. The serialization and deserialization code has been modified to support the new version of the Fedora METS extension schema (described above). Overall, the code in this portion of the server is more compact and robust than in the previous version of the software.

11. Batch Ingest Tool Enhancements

The functionality to create and ingest batches of objects has been moved under the fedora-admin client tool. This consolidates administrative functions into a single tool and provides a readily accessible user interface. There are now more attributes which can be substituted, per-object, into the batch template. These include object label; datastream labels, both general and specific to a disseminator; and datastream title. An object comment can also be inserted.

12. New Demo Objects

This includes new demonstration objects. These objects can be loaded into the repository in one of two ways. The xml source files can be "ingested" into the repository via the Fedora Admin GUI client (from the command prompt, run: fedora-admin). Otherwise, they can be loaded with all other demos by running the demo load script (from the command prompt, run: fedora-demoall [hostname] [port] [username] [password]). The demo object source xml files for the demo objects can be found in the following directory: [FEDORA_HOME]/server/demo

There are two categories of demonstrations:

  • Local Server Demos - These demos can be run under any conditions. They are intended to work when the Fedora repository server is in a stand-alone condition, for example, if the repository is running without a network connection, or if the repository is behind a firewall and not set up to received outside connections.

  • Open Server Demos - These demos can only be run if the Fedora repository server is running as a network accessible server, meaning that it can make outgoing connections AND accept incoming connections. If the repository server is running behind a firewall, the firewall must be configured to allow incoming connections on the port that the repository server is running. The Open Server Demos use distributed content and services that are remote to the repository server.

Once demo objects are ingested into the repository, they can be viewed via a web browser using API-A-LITE or API-A. Remember the URL syntax to get the object profile via API-A-LITE is: http://{hostname}:{port}/fedora/get/{objectPID}

Example: http://localhost:8080/fedora/get/demo:5

For additional information refer to the demos.html file in the userdocs directory.

13. Documentation

After you have installed the software and started the server, you can access the documentation at http://localhost:8080/userdocs (substitute your own hostname and port number if using something other than the default).

Beta 1 - Dec 20, 2002

This release adds several important features to the Fedora software, including a batch ingest tool, parameterized disseminations, and datastream mediation. Digital object serialization and PID generation are now fully active, and validation has been enhanced. This is a non-public release.

1. Batch Ingest

A simple batch tool has been added, enabling the creation of a batch of objects conforming to the same content model. The tool consists of a 3 phase process. Phase 1 will take a directory structure consisting of datastreams and metadata and convert that information into an XML-encoded file. Phase 2 will then take the XML-encoded file and merge that with a object template file that specifies the content model being used to produce a Fedora METS-encoded file. Phase 3 of the process then ingests the METS-encoded files and returns a list of the PIDs that were assigned to the new objects. Phase 2 and Phase 3 are implemented in the beta1 release. Phase 1 will be implemented in the next release and is NOT available in the beta1 release.

2. PID Generation

PID generation has been activated. Upon ingestion, Fedora objects that pass validation are automatically assigned a unique persistent identifer or PID. The namespace prefix on the PID is determined by the namespace parameter in the fedora.cfg configuration file.

Special default PID namespace. To simplify initial setup and use of the repository, the default namespace of "test:" enables special handling of Fedora object PIDs. If the PID namespace is set to "test:" in the fedora/fcfg configuration file, the ingest method will NOT generate unique PIDs, but will instead use the PID values contained in the Fedora objects. This behavior occurs ONLY for the namespace of "test:". This feature was enabled to allow for easier loadeing of sample objects by novice users of the repository software.

3. Serialization

Objects are completely deserialized and re-serialed upon ingest. This has the effect that the stored version of the object (in METS form) will not be the same byte-for-byte as the version coming out, but the information will be preserved. It also enables more complete validation and PID generation.

4. Validation Enhancements

Two-phase validation of objects implemented. Upon ingestion, Fedora objects undergo a two phase validation process to validate against the Fedora METS schema and to validate against a set of rules defined for Fedora objects.

5. Parameters

Method Parameters enabled Method parameters can now be defined in Behavior Mechanism objects using WSDL providing a way to pass parameters to methods from the end user. For example, an image mechanism might have a method named getImage with parameters X and Y that specify the pixel dimensions of the requested image. Method parameters may be supplied by the end user on a dissemination request to affect the result of the dissemination.

Default Method Parameters enabled Mechanism designers can now create method parameters that are known only to the mechanism. Default method parameters cannot be altered by the end user and their values must be specified in the Behavior Mechanism object.

Enhancements to the example soap client (FedoraAccessSoapServlet) In the alpha1 release, the soap client enabled one to reflect on an object using GetBehaviorDefinitions and GetObjectMethods to display a list of all methods for a given object and to disseminate each of the methods. This interface has been enhanced to now allow for user input of method parameters for those methods that define parameters.

DB Schema updated A new table named MechDefaultParameter has been added and the datatype and length of some column names have changed.

6. Fedora Public Website

Added a release directory for downloading both milestone source builds and nightly binary distributions, and created a wiki for user support and FAQs.

7. Datastream Mediation

To provide better security for the physical location of datastreams, a simple proxy has been implemented to disguise the location of datastreams to external mechanisms.

8. Sample Objects

The sample objects in the demo directory have been renamed for readability. The content of the objects has also been updated to reflect new additions like method parameters and default method parameters. The WSDL in the mrsid mechanism object in the alpha1 version contained errors that have been corrected. There is also a sample directory of image files and their associated metadata to create a batch of 10 image objects using the new batch tool.

9. Documentation

Enhanced in-line documentation in code. Ancillary documentation and diagrams updated. Master Specification Document updated. The Specification documented distributed in June 2002 has been updated to reflect changes.

Alpha 1 - Oct 31, 2002

Provided for the first time at the development/deployment team meeting at UVA, this release includes a basic server that can ingest objects, view objects in the repository, and export objects. This is a non-public release.

1. Management API

The management API is exposed via SOAP over HTTP and has the following methods implemented:

  • ingestObject

  • purgeObject

  • listObjectPIDs

  • exportObject

2. Management Client

The included GUI, Fedora Administrator, can be used to ingest objects, purge objects, view objects, and export objects. It also includes diagnostic consoles for API-M and API-A.

3. Access API

The access API is exposed via SOAP over HTTP and has the following methods implemented:

  • getBehaviorDefinitions

  • getBehaviorMethods

  • getBehaviorMethodsAsWSDL

  • getObjectMethods

  • getDissemination

4. Access Client

A java servlet is included with the server distribution that translates from pure HTTP requests to SOAP requests and provides an HTML interface so that object methods may be browsed and getDissemination requests can be provided without the need to send/recieve SOAP envelopes.

5. Object Validation

Objects must be validated according to METS schema rules, Fedora-imposed schema rules, and object integrity rules. For this release, the validation module implements the first two, but only METS schema validation has been activated.

6. Storage Subsystem

This has been implemented on top of a filesystem and a partially redundant database.