Table of Contents

  1. Release 2.1 - February 3, 2006
  2. Release 2.1b - October 21, 2005
  3. Release 2.0 - January 31, 2005
  4. Release 1.2.1 (Bug Fix Release) - April 19, 2004
  5. Release 1.2 - December 15, 2003
  6. Release 1.1.1 (Bug Fix Release) - September 5, 2003
  7. Release 1.1 (Bug Fix Release) - August 5, 2003
  8. Release 1.0 - May 16, 2003
  9. Release 0.9 - March 7, 2003
  10. Beta 1 - Dec 20, 2002
  11. Alpha 1 - Oct 31, 2002


1. Release 2.1 - February 3, 2006


Fedora 2.1 is a very significant release of Fedora since it introduces the new Fedora security architecture (with pluggable authentication and XACML-based policy enforcement), the Fedora Service Framework, and many other new features.  The introduction of the new security architecture resulted in a significant amount of code refactoring, therefore, Fedora 2.1 has been tested with an extensive suite of new JUnit tests.  The codebase and supporting libraries have also been updated making Fedora 2.1 compatible with Java 1.5. Some of the system documentation is still evolving.  Most documentation is complete, but several documents are still being enhanced and improved.  To identify documents that will continue to evolve, please look for an icon that says "Draft Doc" under the document title.  As revisions are made, we will publish the most updated versions of these documents on the Fedora web site ( and send alerts to the Fedora Users mail list. This release of Fedora was also tested against a large production testbed collection, where bulk loading was performed on for a collection of 2 million digital objects with approximately 160M  triples in the Kowari-based Resource Index.   

Also, coinciding with this release is the publication of the Community-Developed Tools page on the Fedora web site (see:   This is a clearinghouse for community-developed, open-source applications, tools, and services that work with Fedora repositories.   There are already many tools that are available, so check it out!


A. Migrating from Fedora 2.1b

If you have previously migrated to the beta release of Fedora 2.1 and want to upgrade to the final release, the move from Fedora 2.1b to Fedora 2.1 is quite simple and does not require reloading of your repository or rebuilding of the Resource Index.  If you are upgrading from Fedora 2.1b to Fedora 2.1, follow the steps found in the Fedora Installation Guide and the Upgrade and Migrate Guide.   There were a number of performance enhancements and bug fixes applied since the Fedora 2.1b release; see the sections below on New Features , Bug Fixes, and Known Issues for details of the changes.


B. Migrating from Fedora 2.0

The move from Fedora 2.0 to Fedora 2.1 is quite simple and does not require reloading of your repository.  If you are upgrading from Fedora 2.0 to Fedora 2.1 follow the steps below.  More detail on these steps is found in the Fedora Installation Guide and the Upgrade and Migrate Guide.   If you are starting from a release prior to Fedora 2.0, consult the Fedora 2.0 release notes and the Upgrade and Migration Guide for instructions on how to migrate to Fedora 2.0 before upgrading to Fedora 2.1.


NOTE:  Please be aware the base URLs for the Fedora SOAP interfaces have changed in Fedora 2.1.  The path names for API-A and API-M have changed to facilitate better security management.   The new path names can be seen in the WSDL files for API-A and API-M and in the Fedora Tomcat web.xml file.    In terms of impact on users, this change will only affect developers who have written custom SOAP clients or middleware for Fedora.  If you have written your own custom SOAP connector for Fedora,  be sure to reference the new path names within the SOAP base URLs:


B. New Features


  1. New Open-Source License (ECL)
    For version 2.1 we have decided to move from Mozilla Public License 1.1 (MPL) to the Educational Community License 1.0 (ECL). The main difference between the two licenses is that the ECL imposes no compulsion to contribute changes to source code. Our experience has been that consumers of our code, both academic and commercial, see it as in their interest to contribute code back anyway. In several cases, this requirement has been a barrier for adoption of Fedora.   Note that this license makes the software openly usable by anyone for any purpose. The only requirement imposed is that anyone using our source code, making changes and distributing the changed source, is required to make it clear that the new distribution is different and to describe the changes made.  Also note that this change only applies to version 2.1. All earlier versions continue to be covered by their original license.
  2. New Tools Page for Software Contributions by the Fedora Community
    A new page now exists on the Fedora web site ( for downloading community-developed, open-source tools, applications, services that work with Fedora.  Check it out!  There are a number of nice open-source clients for creating institutional repositories with Fedora (e.g., Fez, VALET, Elated), as well as other useful services and tools.
  3. Fedora Service Framework
    As of Fedora 2.1, the Fedora Service Framework is being introduced to facilitate the integration of new services with the Fedora repository.   The framework takes a service-oriented architecture approach to building new functionality around a Fedora repository.  While the Fedora repository, itself, exposes its functionality as a set of web service interfaces, all of these interfaces belong to the Fedora web application that runs in its own Tomcat   The new Fedora Service Framework allows new services to be built around the core repository - as stand-alone web applications that run independently of the Fedora repository.   While Fedora repository functionality can still be extended with new modules, the intent is to keep the repository service focused on the core functions of a repository.   Yet, there are many other services that are beneficial companions to a repository, such as specialized ingest services, workflow services, preservation services, and many others.   These are the kinds of services that the framework is intended to support.   There are two main benefits to the service framework approach:  (1) it allows new functionality to be added as atomic, modular services that can interact with Fedora repositories, yet not be part of the repository, (2) it makes co-development of new services for Fedora easier since each service can be independently developed and plugged  into the framework.   The Fedora development team has developed an initial set of services (Directory Ingest and PROAI described below), and will continue to develop new services over the coarse of Fedora Phase 2 (205-2007), especially services for workflow, preservation, and search.   New services will be part of the main Fedora distribution and will be kept up to date with new versions of the core Fedora repository distribution.   Members of the Fedora community will be collaborating on the development of services and will contributed back to the Fedora Project.    Further documentation will be provided to establish guidelines on how services should be designed to effectively plug into the framework.  In the mean time, developers of new services can follow the design patterns of the Directory Ingest and PROAI services.
  4. New Security Architecture - Four Security Configuration Options for the Repository
    Fedora 2.1 introduces a configurable security architecture, that provides options for SSL and authentication at the Fedora web service API level.   There are four base security configurations provided with the Fedora 2.1 server distribution: (1) "ssl-authenticate-apim" configuration which uses SSL and enables authentication for API-M, (2) "ssl-authenticate-all" configuration which uses SSL and enables authentication for both API-M and API-A, (3) "no-ssl-authenticate-apim" configuration which does not use SSL but still enables authentication for API-M, and (4) "no-ssl-authenticate-all" configuration which does not use SSL, but still enables authentication for API-M and API-A. Unlike Fedora 2.0, there is no longer a "default" configuration. Before starting the Fedora server, you must run the new server setup utility (fedora-setup) to select a base security configuration that will initialize the servers security configuration.   After setup, you can customize that base configuration as needed.   The document entitled "Securing Your Fedora Repository" describes the server setup process and the nature of the different base security configurations.
  5. New Security Architecture - Authentication
    The Fedora repository server is built on top of Apache's Tomcat, and authentication is channeled through the normal Tomcat mechanisms (e.g., HTTP Basic Authentication, HTTPS Client Authentication).  When you select one of Fedora's four security configurations, an appropriate rendition of the Tomcat configuration file (web.xml) will be copied into the Fedora Tomcat configuration directory.  This configuration file will set up authentication for Fedora web services (via <login-config>  and <security-constraint> elements).  Under the hood, Tomcat comes with different Realms, where a realm is defined as a "database" of usernames and passwords that identify valid users of a web application (or set of web applications), plus an enumeration of the list of roles associated with each valid user  [see: Apache Tomcat Realms]. 
    Tomcat defines a Java interface (org.apache.catalina.Realm) that can be implemented by "plug in" components to "connect" a servlet container to some existing authentication database.   Fedora 2.1 comes pre-configured with a customized JAAS Realm whose purpose is to multiplex several authentication sources.   By default, Fedora's JAAS multiplexing Realm in configured to deal with a simple user/password file.  There is also support for acquiring user attributes from an LDAP source.  Authentication methods other than the two described here are possible through Tomcat, but require configuring other Realm or Login Modules obtained separately from the Apache Project or third parties, or writing your own custom Realms or LoginModules.  Additional user attributes can be merged with those which Tomcat provides by configuring a site-written servlet filter, which calls the Fedora API.   For more details refer to the documents entitled "Securing Your Fedora Repository " and "Fedora Security Architecture - Authentication."

  6. New Security Architecture - XACML Policy Enforcement
    A major feature of the new Fedora security architecture is the introduction of the eXtensible Access Control Markup Language (XACML) and an XACML-based policy enforcement module.    Developed by the OASIS Consortium, XACML is an XML-based markup language to encode access control policies.  The policy language is flexible and enables the specification of fine-grained, machine-readable policies that can be used to control access to Fedora web services, Fedora digital objects, datastreams, disseminations, and more.    Since a policy is only worth its salt if it can be enforced, Fedora 2.1 introduces a new Authorization module implemented as part of the core Fedora repository service.    The Authorization module is built upon the Sun XACML engine.  Each XACML policy defines: (1) a "target" describes what the policy applies to (by referring to attributes of users, operations, objects, datastreams, dates, and more), and (2) one or more "rules" to permit or deny access.  Version 2.1 provides a Fedora-specific policy vocabulary for referring Fedora operations and Fedora-specific entities within in XACML policies.   For a description of how the policy enforcment module is implemented, see the document entitled "Fedora Authorization with XACML Policy Enforcement."  Regarding policies, Fedora supports both repository-wide policies (that specify broad access controls that apply to the entire repository), and object-specific policies (that specify rules for a single object, and can even be stored within the object in a special datastream).  Fedora 2.1 comes out-of-the-box with a set of default repository-wide policies that establish baseline access controls that are equivalent to what was provided in Fedora 2.0.   These default policies restrict access to the Fedora management web service (API-M) to only the Fedora administrator, permit open access to the Fedora access web service (API-A), and establish some other basic controls (e.g., allow access to API-M only from localhost; restrict policy management to administrator).   In addition to the default policies (which can be modified), any number of custom XACML policies can be written and loaded into Fedora.   For assistance in creating new policies for your repository and for your objects, see the "Fedora XACML Policy Writing Guide."
  7. Fedora Policy Reload Utility
    The Fedora Policy Reload Utility ("fedora-reload-policies" on the command line) provides an easy way to load new or modified policies into Fedora without having to restart the Fedora server.   With the addition of the XACML-based Policy Enforcement module, there is the opportunity to modify existing policies or add new policies over time.  All "active" policies must be stored in the active policies storage locations configured for the Authorization module in the Fedora server configuration file (fedora.fcfg).   Once policies are copied into one of these "active" policy directories, the Fedora server can locate them and load them into memory for policy enforcement.   Every time the Fedora server is started policies are loaded from the active policy directories.    It should be noted that Fedora supports both repository-wide policies and object specific policies.  The Policy Reload Utility will load only repository-wide policies.  For performance benefits, object-specific policies are loaded on demand when the repository receives a request for that particular object.
  8. Fedora Policy Validation Utility
    To support authoring and maintenance of XACML policyies for Fedora, the policy validation utility (i.e., "validate-policy  {policyfile name}"on the command line) is provided with Fedora 2.1.  This utility will validate an XACML policy against the XML schema defined by Sun for XACML.  It is recommended that this utility be invoked on all policies before they are moved to the active policies storage location to prevent errors when the Fedora server attempts to load XACML policies for use by the Fedora Authorization module.
  9. New Security Architecture - Backend Security for Service call-backs
    Backend security is applicable to repositories that contain digital object Disseminators that call upon external web services - and where a high level of security is desired.   Repositories that do not use such external dissemination services do not require any custom configuration of this new security feature.  
    The term "backend services" is used to describe the set of web services that are used by Fedora Disseminators.   Disseminators are optional components in the Fedora digital object model that allow for service-based views of the digital object.  A Disseminator points to a "Behavior Mechanism" which contains a WSDL service description that is used by the Fedora repository service to call upon an external supporting service at runtime.   These external services that Fedora calls upon are referred to as "backend services."   When Fedora makes a call to a backend service, it will typically send a reference to a datastream (stored in a digital object in the repository) that Fedora wants the external service to process in some way (e.g., a transformation of the datastream content).   When a backend service receives such a request from Fedora, it must call back to Fedora to get the datastream content that it is required to process.   This is where backend security comes in.  If the Fedora repository is set up in a secure manner (SSL and authentication), a backend service will be treated like any other incoming client to Fedora.  The service must make calls to Fedora in a secure manner, and it may need to provide credentials to Fedora.   To support the secure interaction of backend services with a secure Fedora repository, Fedora 2.1 provides a the "beSecurity Configuration Tool" for registering each backend service and specifying how it should call back to Fedora.  For more information on configuring backend security refer to the document entitled "Backend Services Security Configuration."
  10. New Directory Ingest Service (DirIngest)
    New as part of the Fedora Service Framework, is the new Directory Ingest Service, which is a stand-alone web service application that interacts with a Fedora repository to provide for ingesting directories or archives or files into a Fedora repository.  The service receives a zip/jar file of files in directory hierarchy (i.e., a file archive), including a METS-based manifest file.  The Directory Ingest Service will receive the archive, open it up, create a digital object in the repository for every file and directory, and populate the RELS-EXT datastream preserve the relationships between files and directories as represented in the input archive.
  11. New OAI-Provider Service (PROAI)
    New as part of the Fedora Service Framework, is the new Fedora OAI Provider Service, which is a stand-alone web service application that is a highly configurable OAI provider.   The PROAI service can be set up to harvest any type of datastream or dissemination of digital objects in a Fedora repository.  It also supports OAI sets.  (Note: PROAI can be used outside the context of Fedora too, by writing a custom adapter.)  Note also that the simple OAI provider interface on the core Fedora repository is still available.   The new OAI service provides much more functionality and better performance.
  12. Resource Index
    The Resource Index has undergone significant testing and a number of bugs have been fixed (see Bug Fixes below).  Most notably, a memory leak was discovered in the Kowari triplestore software that underlies the Resource Index that was the cause of reported Resource Index corruption problems.  (It should be noted that corrupted Resource Index can be restored using the Fedora Rebuilder Utility that was pre-release to those having the problem in Fedora 2.0.  The Rebuilder is now part of Fedora 2.1.)   There have been minor changes to the Resource Index data model.  This should be transparent, unless you have written applications or middleware with static queries to the Resource Index, in which case you may have to make modifications to those queries.  See the Resource Index Guide for more information.  Also with Fedora 2.1, a new indexing level is introduced for the resource index.  This new level (Level 3), will index parameterized disseminations as concrete "representations" of digital objects, whenever there is a fixed domain of values for method parameters.  This is explained in detail in the Resource Index Guide.  Also, as explained in below, the RELS-EXT datastream can be used more freely now, beyond just the expression of object-to-object relationships, making the Resource Index more useful for asserting community-specific properties about objects via RDF.
  13. Relaxation of REL-EXT datastream constraints
    In Fedora 2.0, the Relationships datastream in an object (identified as "RELS-EXT") was reserved for assertions of object-to-object relationships.   Now, in Fedora 2.1, the RELS-EXT datastream can be used as a means of creating extensible properties for digital objects (i.e., properties not defined in the FOXML schema).  The benefit of putting such properties in the RELS-EXT datastream is that the are automatically indexed in the Resource Index, and thus are searchable via the RISearch interface.  Previously, the RELS-EXT datastream was validated by Fedora to ensure that every assertion was of the form  "PID -- relationship -- anotherPID"  where the subject was the PID of the object containing the assertion, the predicate a relationship, and the object of the predicate was the PID of another Fedora object.   New in Fedora 2.1 is that validation of the RELS-EXT datastream has been relaxed so that it can be used to assert other kinds of custom properties about the digital object.    Specifically, the object of the predicate of an assertion does NOT have to be another Fedora PID;  it can be any URI or literal value.   Thus RELS-EXT can be used to associate properties defined in any ontology with a Fedora digital object.  The example below shows the content of a RELS-EXT datastream with three assertions about the Fedora object "demo:99."   The assertions are: (1) a object-to-object relationship defined in the Fedora ontology namespace that says "demo:99" is member of the collection object identified by "demo:c1"  (2) a relationship (myns:isPartOf) defined in custom namespace that says "demo:99" is part of a non-Fedora entity identified by "doi:10.123/456" and (3) an object property (myns:owner) defined in custom namespace that has a value of  "Jane Doe."    The second and third assertions are examples of what is newly supported in Fedora 2.1 that was not previously supported.   The second assertion is in the form "PID -- someRelationshipName -- someURI" and the third assertion is in the form of  "PID -- somePropertyName -- someLiteralValue."

    <rdf:RDF xmlns:rdf="" 
     <rdf:Description rdf:about="info:fedora/demo:99">
        <fedora:isMemberOfCollection rdf:resource="info:fedora/demo:c1"/>
        <myns:isPartOf rdf:resource="doi:10.123/456"/>
        <myns:owner>Jane Doe<myns:owner/>


  14. Rebuild Repository Utility
    The Fedora Rebuild utility is an interactive utility that can be used when the Fedora repository is somehow corrupted.  The utility rebuilds the repository by crawling the repository storage directories where the FOXML digital objects source files reside.   The utility can rebuild the SQL database (registries, search tables, and other tables), the Resource Index, or both.    This is useful for a number of purposes, such as migrating from Fedora 2.0 to Fedora 2.1, and also if a database or index becomes corrupted.   Additionally, if the Fedora administrator want to change from using the McKoi database to using the MySQL database, (or from MySQL to McKoi) the existing database can be purged, the fedora configuration file (fedora.fcfg) can be edited, and the fedora-rebuild utility can then be run to correctly populate the tables in the new database system.   Similarly, the fedora Rebuild Utility can also be useful for rebuilding the Kowari triplestore of the Resource-Index if a problem or corruption occurs.
  15. Command-line utility syntax changes
    With the introduction of the new security architecture for Fedora, the repository can be configured for SSL or non-SSL.  Therefore, the syntax for Fedora client command line utilities has been slightly changed to accomodate the a parameter for the protocol that will be used when calling Fedora.  Refer the the Client Command Line Utilities Guide for the new syntax for each command line utiltiy.
  16. Batch Utility Enhancements:  
    You can now use either a FOXML or METS template file when building objects with the Fedora batch utility.  The batch utility now detects the format of the template file and then generates objects based on the format of the template file so you can create either METS or FOXML  objects now. 
  17. Improved logging using log4j
    Fedora server logging has been standardized to use log4j.   In addition to the general repository server log (created each time the Fedora server is started and named with a date-time stamp), there are now separate logs for Resource Index activity (ri.log) and for transactions sent to the Kowari triplestore that underlies the Resource Index (see: trippi.log and replay.log).   With the log4j logging in place, the next release of Fedora will include a refactoring of log messages to eliminate excessive log messaging, and to better categorize the severity levels of existing log postings. 
  18. FedoraClient utility class for building new clients
  19. Performance and Scale testing
    Bulk loading was performed on the NSDL repository, which provided a testbed of 2 million digital objects with approximately 160M  triples in the Kowari-based Resource Index.  These tests were run on a 64 bit architecture due to heavy use of the Resource Index and Kowari memory requirements.  These tests were run by NSDL middleware that heavily exercised the repository in terms of adding/modifying/deleting large numbers of objects.   The results of these tests will be published soon on
  20. Performance Enhancement (added post 2.1b)
    Runtime performance degradation was reported when Fedora XACML-based policy enforcement was enabled in Fedora 2.1b. This was traced to Fedora's XACML attribute finder module that gets information from a Fedora object when evaluating an XACML policy. The problem was traced to the lack of caching of digital object readers for the duration of a Fedora API request. During the processing of a Fedora API request, the policy enforcement module obtains an instance of a digital object reader to get attributes of the object. A new reader was instantiated for every object attribute that was needed for a particular XACML policy. This resulted in FOXML XML files being parsed numerous times for one API request. The fix was to ensure that a cached instance of the digital object reader was available for the duration of the API request, thus eliminating the excessive and wasteful file I/O and SAX parsing.
  21. Performance Enhancement (added post 2.1b)
    In Fedora 2.1b, it was noted that the SQL Rebuilder utility was inadvertently logging to memory. In the Fedora Rebuild Utility (fedora-rebuild) the SQL Rebuild had degrading performance for rebuilds of very large repositories. The SQL Rebuild code did not properly set server logging and therefore kept all of its log messages in memory while the rebuild was running. This explains why users were not seeing server log files while the SQL rebuild was happening, and also explains the excessive java heap size in later stages of the rebuild. This problem was fixed by setting the logging to go to its proper location on disk..
  22. Object Policy Directory Removed (removed post 2.1b)
    The object-policies directory was removed in 2.1 final since it was intended mostly for testing. Object specific policies should be put in either the POLICY datastream of an object, or they can be put in the repository-policies directory if they have the object PID named in the policy target. See documentation for pros and cons of each choice.
  23. Java 1.5 Compatibility (added post 2.1b)
    The Fedora codebase is upgraded for Java 1.5 compatibility. The server can now be compiled and run with Java 1.5. Fedora source code updates were made to support this, plus key libraries in the Fedora distribution were updated to the latest versions (most notably Apache Axis). Note that Fedora 2.1 is no longer compatible with Java 1.4.1 since the latest Axis libraries do not work with Fedora under this older Java release. You should run Java 1.4.2 or higher with Fedora 2.1.
  24. Fedora Server Configuration Changes (added post 2.1b)
    In the Fedora server configuration file (fedora.fcfg), the default values for the storage locations for digital objects, datastreams, and xacml policies have been changed to relative directory paths to better support cross-platform compatibility. If the default path values are not changed, directories will now be created relative to FEDORA_HOME. You can still override the default paths with either a fully-qualified directory path or another relative path of your choice.



C.  Bug Fixes

        Refer to Fedora's Bugzilla for full descriptions of the resolved bugs.


  1. Bugzilla #68:  Inconsistent treatment of null vs. empty space on API-M method parameter values.  
    Within the Fedora's API-M modify operations (e.g., modifyObject, modifyDatastream, and modifyDisseminator), the use of null as the value for parameters on these operations was not handled consistently.  As of Fedora 2.1,  a null parameter value always means that NO change will be made to the object/datastream/disseminator property that the null parameter value is targeting.   The prior value for that property will be retained as is in the repository.  In contrast, when a modify operation (modifyObject, modifyDatastream, modifyDisseminator) contains a parameter value of the empty string (i.e., ""), then the value of that property will be changed to an empty string.  The empty string is the only way you can empty out the value of a property of an object/datastream/disseminator.  Any non-empty string parameter value means that property will be changed to the specified parameter value.
  2. Bugzilla #87-88  Minor display issues on Fedora web site.  These are fixed on
  3. Bugzilla #89: Classpath error when running fedora-stop.bat.  
    This was traced to servlet-api.jar not being found on the classpath.  Specifically, TC_COMMON is referenced at line 11 but not defined till line 15.  The fix was to move line 15 of  fedora-stop.bat to be after line 8 and before line 11.
  4. Bugzilla #93:  Fedora Tutorial has broken dissemination example.  
    In Fedora Tutorial 2 Example 5 there is an example image object (demo:800) with disseminators using the BDef demo:600.  The greyscale and and resize disseminations are now fixed.
  5. Bugzilla #97-98:  Command line scripts break if JAVA_HOME has spaces.  This problem was reported on fedora-stop.bat and fedora-ingest-demos.  This has been fixed.
  6. Bugzilla #99:  The API-A listDatastreams operation via SOAP returning incomplete list.  
    When running listDatastreams via API-A (SOAP), the list is incomplete, but when running against API-A-LITE (REST), it works fine.  The incomplete list consists only of datastreams that are used by disseminators. cause was getting a "cached" context in  The fix was to use a non-cached context so the full, acurate list of datastreams is returned.
  7. Bugzilla #100:  Fedora debug script required upgrading.  The fedora-debug.bat was not previously updated to be compliant with Fedora 2.0, which has now been fixed.
  8. Bugzilla #101 and 104: MySQL scripts fail when MySQL path includes spaces.  
    The scripts affected were mysql-config.bat  and mysql-drop.bat.  The fix is that If the MySQL path contained spaces, enclose the path in double quotes and the script will handle the path correctly (e.g., mysql-config.bat "C:Program files\MySQL\MySQL server 4.1").
  9. Bugzilla #105-106:  The MySQL script "mysql-drop-db.bat" does not work with MySQL 4.1. 
    This was a bug in mysql-drop-db.bat and has been fixed in cvs as of 2/18/2005. The optional mysql41_flag argument has been added to the script. When specified, the script will set the default character set to utf8 and collation to utf8_bin for the fedora database when it is recreated. This script is primarily a convenience utility when testing and you need to drop and recreate the Fedora SQL database.  Refer You can accomplish the same tasks manually using the MySQL commands.  Refer to Bugzilla for more details on how to do this. 
  10. Bugzilla #107:  Use of "distinct" ignored in Resource Index Search. 
    When using the Resource Index REST-based search interface (risearch), the use of "distinct" didn't work in queries.  The cause was that risearch was ignoring the "on" value.  The servlet that implements risearch was looking for a value of 'true' instead of a value of "on."  This caused "distinct" to not work.  The fix was done within the trippi libraries -- now it accepts 'on' or 'true' for the value.  A replacement trippi library (trippi.jar) was created and checking into cvs.
  11. Bugzilla #108:  Bad link on Download Page for Fedora 1.2.1.  
    The download page for 1.2.1 has a bad hyperlink to the patch download. Also the link "Download" on this page pointed to an old location.  Both are fixed.
  12. Bugzilla #110:  Resource Index Corruption.  
    After the introduction of the Resource Index in Fedora 2.0, there were reports of out of memory errors occurring related to the Kowari triplestore.  This often led to corruption of Resource Index.  This was
    traced to a memory leak in Kowari which was caused by a failure to properly clean up unused FreeList$Phase objects in one of the FreeList constructors.  The problem showed up when doing many inserts and deletions. More information can be found at:
  13. Bugzilla #114: Resource Index had missing lastModifiedDate property on datastream disseminations nodes.  
    Resource Index datastream disseminations had createdDate instead of lastModifiedDate properties.  According the the Resource Index data model, Disseminations should *not* have a createdDate property.  Now they have lastModifiedDates as expected.
  14. Bugzilla #116: Possible SQL database corruption during ingest when failure occurs.
    When ingesting an object and a failure occurs after the object is initially registered, the registry entries in the sql db table doRegistry are not properly backed out. The result is that PID entries are left in the doRegistry table so that subsequent attempts to re-ingest will fail with the error being that the PID already exists.  bug had to do with Exception handling during the ingest sequence. The bug was introduced with code changes related to Fedora 2.0. The occurence of this bug in the 2.0 release should be rare but could occur if a fatal error occurred with the sql database transactions during the ingest sequence after the object had been registered. The symptom would be a failed ingest and then the inability to re-ingest the same object after the failure without manually removing the PID entry from the doRegistry table.Exception handling has been modified in DOManager and DOWriter to account for this scenario and properly backout any entries in the doRegistry table. Exceptionon handling has been modified in DOManager and DOWriter to account for this scenario and properly backout any entries in the doRegistry table following a failure during the ingest process.
  15. Bugzilla #117: Inline datastream xmlns placement problem.
    An inline xml datastream with valid, namespaced XML.  When tried to export the object, it failed (but purging it worked).The problem seems to show itself when you have multiple 'xmlns=' ("default"namespace) declarations in one inline xml chunk.What happens is, somewhere along the line the default namespace declarations getmoved to the root.  And this makes for invalid (not well-formed) xml (repeatingattributes of the same name are not allowed in the same element).This is fixed in FOXMLDODeserializer and METSLikeDODeserializer.  The fix was tokeep a map of all prefix-to-uris and a list of prefixes that needed to be written while parsing each element inside xml content.
  16. Bugzilla #125: Fedora Administrator does not allow editing of "application/xml" MIME-typed datastreams.  This is now fixed.
  17. Bugzilla #127:  Problem with ampersand in ALT_IDS property on datastream:  If you modify a datastream, setting the ALT_IDS property to something with an ampersand, the object can no longer be loaded from the repository.  It even disrupts search results (Fedora basic search) since they require that the corrupt object is deserialized, and the XML parsing fails.  The problem was caused by a failure to xml-encode special characters when serializing digital objects using the class.  The fix was to encode them.  The problem also existed when encoding the FORMAT_URI property, so that was fixed also.
  18. Bugzilla #130 (fixed post 2.1b):  FieldSearch module ambiguous reference 'pid' when doing dc date search:   The problem was that in the case where a join is used (which is the case when doing a query comparing the dc 'date'), the 'pid' reference in the SELECT clause becomes ambiguous and the query fails. This is fixed in CVS and will go out with 2.1-final. The fix was to always qualify the fields in the SELECT clause with "doFields."
  19. Bugzilla #131 (fixed post 2.1b): No index on pid column in dcDate table:  The lack of an index on the PID column of dcDate table in the Fedora relational database resulted in some incremental performance degradation on ingest and SQL database rebuilds in large repositories.  The effect was became apparent when the repository had over 1 million objects.   The problem was fixed by adding an index to dbspec file so it would automatically be created on this table.
  20. Bugzilla #133 (fixed post 2.1b): Uploaded content not getting deleted properly:  When the upload servlet was used to upload content to Fedora, the temporary content file was not getting properly deleted. It would only get deleted after server startup. The fix was the removal of a line in that had the effect of "forgetting" that the content had been uploaded when it was downloaded, thereby causing the content to remain on the server until startup.
  21. Bugzilla #134 (fixed post 2.1b): length of datastreamPaths.token column:  In Fedora 2.0, the length of PIDs and datastream IDs was expanded in the SQL database schema from 32 to 64 characters to accomodate longer PIDs and datastream IDs. The "token" column in the datastreamPaths table was not updated to reflect this length change. In Fedora 2.1, the length of the datastreamPaths.token column has been updated from varchar(103) to varchar(199). This db schema change will only be applied to new databases created with Fedora 2.1 or databases rebuilt under 2.1 using the Fedora Rebuilder utility. This change may also be applied to an existing SQL database by simply updating the length of the datastreamPaths.token coumn from varchar(103) to varchar(109). If you plan to use datastream IDs that exceed 32 characters, it is recommended that you update the length of this column in your existing sql database.
  22. Bugzilla #135 (fixed post 2.1b): Server profile ignored when doing SQL rebuild:  When invoked with an argument indicating the "server profile" (for example, "oracle"), the SQLRebuilder doesn't pick up the right configuration values from fedora.fcfg (for example, the values specified in the "oracleValue" attribute). The solution was to make sure the -Dfedora.serverProfile parameter was passed to java in the fedora-rebuild.bat/sh scripts, because the SQLRebuilder depends on fedora.server.Server to parse fedora.fcfg, and fedora.server.Server uses the fedora.serverProfile property to decide which, if any, server profile to use.
  23. Bugzilla #136 (fixed post 2.1b): Oracle SQLRebuilds fail with 'invalid relational operator':  When running fedora-2.1b's SQL rebuilder against Oracle, a series of Oracle error messages are reported: 'invalid relational operator'. Rebuilding subsequently fails. This was caused by a "WHERE 1" clause at the end of a DELETE FROM statement that should have deleted all rows. MySQL is more lenient here, but Oracle complains.The solution was to remove the WHERE clause altogether. Fixing this issue also revealed another oracle-related bug where the SQLRebuilder was previously attempting to remove rows from ALL tables returned by getDatabaseMetadata. This works fine in MySQL because the list of tables is isolated to the fedora database.The problem is that this command in Oracle returns MANY non-Fedora tables (system tables, etc) from this method. In effect, this was attempting to remove all tables, even those from other tablespaces in the Oracle installation. The fix for this bug was to only remove rows from tables that exist in the database and are Fedora tables (the list of Fedora tables comes from DefaultDOManager.dbspec).
  24. Bugzilla #137 (fixed post 2.1b): embedded POLICY datastream policy not enforced: In line 278 of the PolicyFinderModule a call to GetDatastream vs getDatastream was used for retrieving a POLICY datastream out of an object for use in policy enforcement. The unfortunate ambiguous naming of these two methods, and the wrong one being called, resulted in the policy finder module returning null for policy datastream content. This resulted in policy datastreams not being in scope as expected. This was fixed, and the developers will never name two methods in this ambiguous manner again.
  25. Bugzilla #138 (fixed post 2.1b): HTTP Connections in CLOSE_WAIT:   After serving many dissemination requests that hit a backend service, NSDL reported the error of "Too many files open". It was determined that this was actually a socket problem. By listing the contents of /proc/pid/fd/ on the Linux box, we saw that many, many sockets from the process had been left in the CLOSE_WAIT state. Fedora had exhausted available file handles for the process. The problem was isolated to requests for datastreams by-reference, and requests for disseminations that hit a backend service. The two relevent pieces of code are and They each have a method to get content via HTTP into a MIMETypedStream object, and they both use fedora.common.HttpClient. We determined that the implementation for releasing connections was potentially flawed and could result in piling up lots of unused http connections which would leave connections in the CLOSE_WAIT state. The fix was to implement a different strategy for releasing connections and sharing a MultiThreadedHttpConnectionManager, similar to the behavior of FedoraClient.
  26. Bugzilla #139 (fixed post 2.1b): commons-httpclient connections hanging:  After applying fix to bug #138, NSDL noted that Fedora would seem to hang after five or so back-to-back dissemination requests from the oai provider service. After further investigation and testing, the lockup turned out NOT to be coming from the Fedora server, but coming from the commons-httpclient connection pool used by FedoraClient, which is used by the NSDL repo code (this is the NSDL's back-end dissemination service). But what looked like a "lockup" was actually commons-httpclient behaving normally: it was waiting for a connection to become available from the pool.The reason this situation occurred was: 1) The commons-httpclient connection pool was configured to only allow 5 simultaneous connections per host. 2) More than 5 simultaneous connections were needed in the normal course of events for the NSDL client code. 3) Part of the reason for #2 was the redirect behavior of FedoraClient: whenever a SOAP stub (APIA or APIM) was requested, a connection would be tied up just for the purpose of determining whether the Fedora server was going to redirect the client. The fix involved two changes to the code: 1) the default # of simultaneous connections for FedoraClient was increased. 2) re-implemented the APIA/APIM-SOAP redirect behavior so that it only makes the "redirect" determination ONCE per instance of FedoraClient, instead of every time an APIA or APIM stub is requested. These changes reduce the number of required http connections and as a bonus, improves performance in situations (like the NSDL's) where getAPIA() and getAPIM() are called multiple times on the same FedoraClient instance.
  27. Bugzilla #143 (fixed post 2.1b): temp files not being properly cleaned up: It was noted that some types of temporary files were accumulating in the temp directory and not being properly cleaned up.

      DefaultAuthorization(backend policy generation):
        Temporary transform files used to construct the set of backend policies were not being removed after the backend policies had been constructed. This was fixed in DefaultAuthorization , and updated in Fedora CVS.
        The servlet we use for "risearch" is included in the trippi library, and has configurable behavior to pre-save the results on the server before sending them. These files weren't being deleted which was leaving old copies of query results in the server tempdir whenever the resource index was enabled and "risearch" was used. This was fixed in trippi, and the new jar was checked into the core Fedora CVS.
        Proai is the library that the OAIProvider service uses. At the end of a cache update cycle, it prunes any out-of-date files from the cache directories. Part of this process creates a temporary file that is a simple list of files in the cache. This file wasn't being deleted properly. I fixed this and checked the latest proai.jar into the oai provider cvs.
        For each update cycle, this creates three temporary query result files per-format. These are automatically deleted under normal circumstances, but I put some defensive code in place that also attempts to delete them when the object that's reading them is garbage collected.
  28. Bugzilla #124 (fixed post 2.1b): API-A Lite search was not supporting international characters This was fixed for the FieldSearch servlet by explicitly assuming the encoding of the request parameters to be UTF-8 within the servlet code. In the case of the RISearch interface, it was fixed by changing the HTTP method to POST in the stylesheet that produces the html interface, and noting in the risearch documentation that POST should be used when the query is given by value and might contain international characters.


D.  Known Issues

  1. If you are using Disseminators that bind to external services AND if you configure Fedora to authenticate the API-A service, then you should NOT set the Fedora server hostname to LOCALHOST since this is not a resolvable domain name.  Disseminators with external services require that external services be able to call back to the Fedora repository to obtain datastreams.   When an external web service tries to call back to the Fedora, repository,  there must be a publicly registered domain name for the Fedora server or else the external service will not be able to contact the repository.   To avoid this problem, change the Fedora server hostname in the Fedora server configuration file (fedora.fcfg) to a registered domain name.  Note that if you are running as LOCALHOST when API-A authentication is ON, you will encounter exceptions in demo objects disseminations that depend on external services (demo:6, demo:7, demo:10, demo:11, demo:17).
  2. When the Resource Index is configured to be ON,  care should be taken to estimate the number of triples per object that will be indexed in the Resource Index (in the Kowari triplestore in particular).  Consult the document named "Triples in the Resource Index" for an understanding what is indexed in the Resource Index, and to estimate the number of triples in that will be inserted into the Kowari triplestore.   For very large triplestores, a 64 bit architecture is required for optimal performance and memory management.  Testing of Kowari has shown that performance on a 32 bit architecture degrades when the Kowari triplestore get to approximately 50M triples, but that with a 64 bit architecture, Kowari scales well to 250M triples (see:
  3. Also, when bulk loading a repository that is estimated to have a very large Resource Index (i.e., triplestore > 50M triples), it is recommended that the Fedora server be restarted periodically. Bulk load tests on Fedora 2.1 indicate that there may be a slow memory leak when doing large numbers of delete/insert sequences on the Kowari triplestore. This potential issue is currently under investigation. As a cautionary measure, periodic stopping and restarting of the Fedora repository server will reclaim memory and prevent the possibility of an out-of-memory exception (which might have unpredictable effects on the Kowari triplestore). Here are some sample guidelines:
    • Restart daily if:
      • a very large ingest takes up to a day to complete
      • you are using the Fedora 2.1 default values for start/max heap size of 256M
      • you invoke garbage collection on every commit (default in Fedora 2.1)
    • Restart every 8 hours if:
      • everything is the same as above, but you have configured fedora.GCOnCommit to be false, as discussed in issue #4 below.

    In either case if you change the start/max heap size for the fedora server, you can adjust the restart frequency by the same factor. e.g., Using the second scenario, if you increased the start/max heap size to 768M (triple the default), then you could ingest at 3x the rate of the first scenario and only need to restart the sever once a day.

    Note: this is only a precautionary measure when attempting very large bulk ingests on respositories estimated to have a very large Resource Index.
  4. Java garbage collection (GC) is run each time an object is ingested via API-M. This is a temporary safety precaution that came about because of issue #3. If issue #3 does not apply to your environment, you can disable this behavior and improve ingest performance by setting the fedora.GCOnCommit system property to false. This will cause garbage collection to be forced on ingest only when the available java heap space is down to 1/3 of its maximum. This can be done by manually editing the server/bin/ or server\bin\fedora-start.bat script, depending on whether you are running Fedora in Unix or Windows. For an example of doing this, please see this recent post on the fedora-users mailing list.

  6. Under certain situations, the HTTP error response generated by a dissemination request can mask the true underlying error. For example, consider a backend service that attempts to get a datastream request from Fedora and Fedora responds with a HTTP error response of 403 indicating authorization with the Fedora server was denied. If the backend service does not properly handle this response and just returns ServerException(500 error) for any non-200 response, then the originating dissemination request will only "see" the 500 error returned by the backend service and not the underlying 403.
  7. Running the server in "debug" mode will slow down performance.  You can turn debugging on/off in the Fedora server configuration file (fedora.fcfg).
  8. Modification of Behavior Definition and Behavior Mechanism objects not yet supported, but will be made available in the next release of Fedora.
  9. An early adopter of Fedora 2.1 reported anomalous 401 status codes returned after a period of normal server use. This problem is difficult to replicate, and the cause is unknown. A workaround to this problem is to instruct Tomcat to use a MemoryRealm instead of a JAASRealm. Detailed instructions on applying this workaround are available at bugzilla #144.
  10. The exception fedora.server.errors.servletExceptionExtensions.Ok200Exception, (and associated stacktrace) is produced by fedora.server.ServerController and can safely be ignored.
  11. Users have reported problems in creating C# class files using C# wsdl converter tools with Fedora-API-A.wsdl and fedora-types.xsd. There appear to be some differences between C# converter tools and the Axis wsdl2java converter tool used by Fedora. Refer to bugzilla #bug140 and bug#141 for additional details.
  12. (post 2.1b issue) Note that Fedora 2.1 is no longer compatible with Java 1.4.1 since the latest Axis libraries do not work with Fedora under this older Java release. You should run Java 1.4.2 or higher with Fedora 2.1.
  13. (post 2.1b issue) If you have configured ssl and authenticate all on the Fedora server, then if you log into Fedora Administrator client with the non ssl port (e.g., 8080) and non ssl protocol (http), you may run into problems with the client hanging when opening objects with the object editor. This is caused by ssl redirecting not working properly for some requests. To avoid this, log into Fedora Administrator with the redirect port (e.g., 8443) and ssl protocol (https) if your fedora repository is configured for ssl and authentication.
  14. (post 2.1b issue) In Fedora 2.1b, it was noted that double indexes were specified on some tables (both PRIMARY and INDEX) defined in the db schema. To prevent extra overhead that could negatively affect performance, the extraneous indexes were removed from the dbspec file for the following tables:
      a. doRegistry
      b. riMethod
      c. riMethodImpl
      d. riMethodMimeType
      e. riMethodPermutation
    These db schema changes will only be applied to new databases created with Fedora 2.1 or databases rebuilt under 2.1 using the Fedora Rebuilder utility. These changes may also be applied to an existing SQL database by simply removing (dropping) the duplicate index using an appropriate database utility.
  15. (post 2.1b issue) A minor adjustment was made to the length of the dsBind.dsCurrentVersionID column in the sql database schema to accomodate datastreamIDs that are between 59 and 64 characters in length. This column was increased from varchar(64) to varchar(69) to allow for the maximum of 5 additional characters that are part of the version ID. If you use datastream IDs that are between 59 and 64 characters in length, we recommend that you update the dsBind.dsCurrentVersionID column in your sql database from varchar(64) to varchar(69). Otherwise, you can leave the settings at their current values.
  16. (post 2.1b issue) Problems have been reported during ingest when using certain builds of MySQL (verified with 4.1.12 for Ubuntu Linux 5.10) with the ResourceIndex active (level 1 or 2). The resulting error generates a stack trace similar to the following:
    	  Caused by: java.sql.BatchUpdateException: Duplicate entry '' for key 1
            at com.mysql.jdbc.ServerPreparedStatement.executeBatch(
            at org.apache.commons.dbcp.DelegatingStatement.executeBatch(
            at fedora.server.resourceIndex.ResourceIndexImpl.addBDefMethodMapDatastream(
    According to reports, the problem should in fact manifest anytime PreparedStatements are used. One of the MySQL developers suggests that the issue may be the result of the combination of GCC 4.0.3 and glibc2.3.5 used to build MySQL (which might explain why only some builds of the same version exhibit the problem).

    Workarounds include:
    • using a different build of MySQL, e.g. one of the official builds from
    • using useServerPrepStmts=false (e.g., in fedora.fcfg, edit the localMySQLPool jdbcURL to include "useServerPrepStmts=false"). This should incur a marked performance penalty.
    • Although not rigorously tested, using the MySQL ConnectorJ 5.0.0-beta JDBC driver also appears to fix the problem

    See bugzilla #142 for additional details.



2. Release 2.1b - October 21, 2005


Fedora 2.1 was initially released as beta in version 2.1b. The beta version is now obsolete and replaced by the release of Fedora 2.1 final. Information about the earlier Fedora 2.1b release notes can be found at



3.  Release 2.0 - January 31, 2005

Fedora 2.0 is a major release that culminates Phase I of the initial Fedora project that began in October 2001 and ended in October 2004. Fedora 2.0 includes significant new features and improvements including the introduction of the Fedora Object XML (FOXML) schema as the new internal storage format for objects, introduction of the Resource Index that provides enhanced search capability, introduction of a Batch Modify utility, upgrades of all third party libraries, performance enhancements, and a number of bug fixes.

IMPORTANT!! - Migrating From Fedora Release 1.2.1

Users migrating from Fedora Release 1.2.1 need to follow the steps outlined in the section entitled, Migrating From Fedora 1.2.1 to Fedora 2.0, and apply patch number 2 to their existing Fedora 1.2.1 repository BEFORE attempting migration to Fedora 2.0. Failure to do so can severely limit future migration options.

If you are running a version of the Fedora software prior to version 1.2.1, you will need to migrate your server software up to version 1.2.1 first, and then proceed with the migration from Fedora 1.2.1 to Fedora 2.0. Steps for migrating to Fedora 1.2.1 can be found in the release notes section for Fedora 1.2.1.

A. Migrating From Fedora 1.2.1 to Fedora 2.0

If you are upgrading from Fedora 1.2.1 to Fedora 2.0 follow these steps:

  1. Download patch number 2 from
  2. Make sure you are running v1.2.1 of the Fedora server software.


    To check your repository's version, check the "describe" page. For instance, if you're running Fedora on localhost:8080, visit http://localhost:8080/fedora/describe

  3. Shut down your Fedora 1.2.1 server (using fedora-stop)
  4. Make a backup of the METSLikeExportDOSerializer.class file.

    Under Windows, make a backup of the following file:


    Under Unix, make a backup of the following file:

  5. Copy the METSLikeExportDOSerializer.class from this patch into the above directory replacing the one there.

    Under Windows, copy the METSLikeExportDOSerializer.class from patch into the following directory



    Under Unix, copy the METSLikeExportDOSerializer.class from patch into the following directory



  6. (OPTIONAL) If you installed the source code distribution of Fedora, you should also copy the included file into your source directory.

    Under Windows, copy the file from the patch into the following directory



    Under Unix, copy the file from the patch into the following directory



  7. Re-start your Fedora 1.2.1 server (using fedora-start). Your Fedora 1.2.1 repository is now ready for exporting its objects to the new server.
  8. Download the Fedora 2.0 software from
  9. Install and configure the new Fedora 2.0 repository with a different host and port than the Fedora 1.2.1 server.
  10. Start the Fedora 2.0 server (using fedora-start).
  11. There are two ways to ingest objects from the 1.2.1 server: 1) use the admin GUI client to ingest the objects from the 1.2.1 repository or 2) use the fedora-ingest command-line utility to ingest the objects from the 1.2.1 repository
    1. Using the admin GUI client to ingest objects from the 1.2.1 repository
      1. Start the fedora admin GUI client (using fedora-admin).
      2. Under the File menu item, select File, Ingest, Object By Type, From Repository.
      3. Specify the hostname and port of the Fedora 1.2.1 server from which you want to ingest objects. Specify the administrator username and password for the 1.2.1 repository.
      4. Select all three object types including Behavior Definition, Behavior Mechanism, and Data object and click OK.
      5. The Fedora 2.0 server will now ingest all objects from the 1.2.1 repository.
    2. Using the fedora-ingest command-line utility to ingest objects from the 1.2.1 repository.
      1. Run the fedora-ingest command-line utility which is found in the client/bin directory.

        Under Windows, this file is found in:


        Under Unix, this file is found in:

      2. Arguments for the fedora-ingest utility should include the following:
        • Type of ingest: specify R for repository
        • Hostname and port of the 1.2.1 repository from which you wish to ingest objects: source-host:source-port
        • Administrator username of the 1.2.1 repository: fedoraAdmin
        • Password for the administrator username of the 1.2.1 repository: fedoraAdmin is the default
        • Type of objects to ingest: specify DMO for all three object types.
        • Hostname and port of the 2.0 repository into which you are ingesting the objects: destination-host:destination-port
        • Administrator username of the 2.0 repository: fedoraAdmin
        • Password for the administrator username of the 2.0 repository: fedoraAdmin is the default
        • Log message: use "" for no message.

          For example:

          fedora-ingest r src-host:src-port fedoraAdmin fedoraAdmin DMO dest-host:dest-port fedoraAdmin fedoraAdmin ""
  12. After successfully ingesting all objects from the 1.2.1 repository, shutdown the 1.2.1 repository (using fedora-stop).
  13. If you desire to run the Fedora 2.0 repository under the same hostname and port as the 1.2.1 repository, you can now shutdown the 2.0 repository using fedora-stop, reconfigure the host and port in the fedora.fcfg file for the 2.0 repository to match those of the previous 1.2.1 repository, and restart the Fedora 2.0 repository.

B. New Features

  1. Fedora Object XML (FOXML)

    A new XML schema has been developed that provides a simple and unambiguous expression of the Fedora digital object model. Previously, Fedora digital objects could only be expressed in XML using an extension of the METS schema. FOXML is the new internal storage format for digital objects inside a Fedora repository. However, Fedora supports both METS and FOXML as ingest and export formats (see #2 below). The introduction of FOXML was motivated by several requirements: (1) simplicity - user feedback called for a conceptually easy mapping of the Fedora concepts to an XML format. Users wanted an obvious sense of how to create Fedora ingest files, especially those who are not familiar with formats such as METS and DIDL, (2) optimization and performance - the FOXML schema was designed to improve repository performance, both at ingest and during disseminations. Overall ingest performance has been positively affected with FOXML, especially in the validation phases, (3) flexibility - internal storage of FOXML enables easier evolution of functionality in the Fedora repository, without relying on Fedora-specific extensions to the METS schema. FOXML also introduces several new features to the Fedora Object Model including, the ability to store alternate identifiers for datastreams, and the ability to store format URIs for datastreams and objects (i.e., in anticipation of services such as the Global Digital Format Registry (GDRF). Refer to the user documentation for more details about FOXML and new features of the Fedora Object Model.

    The XML schema for FOXML is available at:

  2. Ingest and Export with Different XML Formats

    The Fedora project is committed to providing repository ingest and export functions that are compatible with community developed standards for digital object XML encoding. This is motivated by both interoperability and digital preservation concerns, where flexibility in the transmission format of digital objects is an important feature. In support of this, the ingest and export operations of API-M have been redesigned to allow submission and retrieval of digital objects in several alternative XML formats. In release 2.0, digital objects can be ingested and exported in either METS (Fedora extension) or FOXML. In future releases, we will add support for METS 1.3 and MPEG21/DIDL. Internally, the Fedora repository system provides a translation module that is responsible for mapping digital objects to the different supported formats. See the new "Ingest and Export Guide" in the system documentation for more details.

  3. Relationship Metadata for Digital Objects

    Fedora now supports the assertion of object-to-object relationships. Fedora digital objects can be related to other Fedora objects in many ways. For example there may be a Fedora object that represents a collection and other objects that are members of that collection. Also, it may be the case that one object is considered a part of another object, a derivation of another object, a description of another object, or even equivalent to another object. Relationship metadata of this sort can now be encoded in Fedora digital objects in a special reserved datastream (identified as "RELS-EXT"). Relationships are expressed as RDF/XML. Fedora provides a default relationship ontology that defines a set of common relationships (see: Also, there is support for community or user-defined relationships. The relationships datastream is automatically indexed by Fedora as part of the new Resource Index module (described below), which provides RDF-based searching of the repository, including object-to-object relationships.

  4. Resource Index

    The Resource Index Module provides an RDF storage and query service for object metadata and relationships in Fedora. By default, the Resource Index indexes object properties, datastream, and dissemination information. In addition, user-defined, inter-object relationships expressed the RELS-EXT datastream are also automatically indexed. Examples of relationships between digital objects that may be expressed in the Resource Index include well-known management relationships such as the part-whole links between individual chapters and a book, and semantic relationships useful in digital library organization such as those expressed within the Functional Requirements for Bibliographic Records (FRBR). The query interface is exposed as a web service, providing the foundation for external services. Refer to the user documentation for additional information about the Resource Index.

  5. Batch Modify Utility

    A new utility has been added to the Fedora administrative client that allows repository administrators to perform object modifications in batch mode. The utility is built using the management API method of API-M so that most of the API-M methods can be run against groups of objects. The utility works by creating an xml-encoded input file of modify directives. This directives files is then processed in sequence to carry out the designated tasks. A sample batch modify directives file is included in the distribution in the batch-demo directory. Refer to the Batch Modify Utility user documentation for additional information regarding the Batch Modify Utility.

  6. Repository Administrator Reporting Tools

    A new Reporting interface has been added for obtaining simple administrative reports about objects in the repository. The interface consists of several static queries that can be performed on the repository to obtain statistics about objects. These queries currently include object counts based on type of object, creation date, and pid namespace. Refer to the user documentation for additional information.

  7. Example Client for Making SOAP calls to Fedora APIs

    A sample java client application is provided that demonstrates how to make SOAP calls to API-M and API-A. This client is written as a single java class that connects to a Fedora repository, and makes a set of successive set of SOAP calls to ingest an object from a FOXML XML file, then add datastreams, modify datastreams, export the object, and several other useful examples. It is intended as a quick and easy starting point for Java programmers who want to write their own clients to the Fedora SOAP interface. The demo client is found in the Fedora 2.0 distribution at: {FEDORA_HOME}/client/demo/soapclient. Programmers should examine the file To compile the demo, run the script named "compile-demo-soapclient.bat" (or .sh on unix). To run the demo, run the script named "run-demo-soapclient.bat" (or .sh on unix).

  8. Third party Library Upgrades

    All of the major third party libraries used in the Fedora codebase have been updated to reflect the most current stable versions available. This includes updating the underlying tomcat server to tomcat version 5. For Additional details regarding new library versions, refer to the license.html file in the distribution which has a complete list of the new libraries.

  9. Performance Tuning

    Significant enhancements have been made to the Fedora server code to improve ingest performance. These enhancements included both tuning of the underlying relational database as well as tuning how ingests are handled internally in the Fedora server.

  10. API-A and API-A-LITE Changes

    A general cleanup of the methods found in API-A and API-A-LITE has been done to provide better consistency between the SOAP-based and REST-based interfaces for API-A. The corresponding WSDL files have also been updated to reflect the changes.

    Previously in Fedora 1.2.1:


    In Fedora 2.0:


    API-A Methods removed:

    • getBehaviorDefinitions - the functionality of this method is replaced with the revised getObjectProfile method which now provides complete object info including behavior definitions and methods.
    • getBehaviorMethods - the functionality of this method is replaced with the revised getObjectProfile method which now provides complete object info including behavior definitions and methods.
    • getBehaviorMethodsXML - the functionality of this method is replaced with the revised getObjectProfile method which now provides complete object info including behavior definitions and methods.
    • getObjectMethods - the functionality of this method is replaced with the revised getObjectProfile method which now provides complete object info including behavior definitions and methods.

    API-A Methods added or modified:

    • getDatastreamDissemination - this new method replaces the functionality provided in earlier releases using the getItem method of the Default Disseminator to return the contents of a datastream. Use of the default disseminator getItem method is now deprecated.
    • getObjectHistory - this new method provides a change history for a digital object listing each modification date when an object component has been modified. This is an interim solution to provide some basic information through API-A and API-A-LITE about the change history of an object. Eventually we would like to provide more detailed information from the Fedora audit records so one could obtain a detailed history of what changes were made to specific components of the object.
    • getObjectProfile - this method has been modified to return the complete object profile for a digital object. The object profile now includes all component information about an object.
    • listDatastreams - this new method replaces the functionality provided in earlier releases using the getItemIndex method of the Default Disseminator to list the datastreams of an object.
    • listMethods - this new method replaces the functionality provided in earlier releases using the getMethodIndex method of the Default Disseminator to list the methods of an object.
  11. API-M changes
    • logMessage parameter now exists on all object-modifying methods.
    • Datastream altIDs attribute. Any number of alternate identifiers can be specified for datastreams on creation or modification. This information is currently maintained, but not acted upon.
    • Datastream versionable attribute. A new boolean parameter that indicates whether Fedora should make changes in-place or retain prior versions on datastream modification. This information is currently maintained, but not acted upon.
    • New ingest method added. With the introduction of FOXML and support for multiple ingest formats, an additional parameter was required on ingest to specify the format of the file to be ingested. Valid values for format are "foxml1.0", "metslikefedora1", or "default". The format of "foxml1.0" specifies ingest files is encoded using FOXMLv1.0. The format of "metslikefedora1" specifies the encoding is Fedora's extension of METS. The format of "default" indicates to use the current repository default format. Refer to the API-M WSDL for additional information about the change. The former ingestObject method is now deprecated.
    • New export method added. With the introduction of FOXML and support for multiple export formats, an additional parameter was required on export to specify the format of the file to be exported and to specify the context of the export. Valid values for format are "foxml1.0", "metslikefedora1", or "default". Valid values for format are described above. Valid values for context are "public", "migrate", and "archive". A value of "public" produces an export file that is appropriate for use outside of the repository (all datastream content can be obtained via public callback URLs). A value of "migrate" produces an export file that is appropriate for migrating an object from one Fedora repository to another. A value of "archive" produces an export file that is a standalone entity, where all datastream content is inlines (XML inline and binary base64-encoded inline). Note that the "archive" option is not implemented in Fedora 2.0. Refer to the API-M WSDL for additional information about the change. The former exportObject method is now deprecated.
    • modifyDatastream now supports changing the mimeType and formatURI, and altID.
    • modifyDatastream and modifyDisseminator methods now support a "force" parameter, which indicates that even if a data type contract would be broken, Fedora should accept the change anyway.
    • purgeObject and purgeDatastream now include force parameters. Currently when specified as true, these throw an exception. This feature will be implemented in a future release.
    • Consistent parameter ordering. Parameter ordering of all the API-M methods was adjusted to make parameter ordering more consistent. Generally, the first one or two parameters identify the thing being accessed/modified (object PID, datastream or disseminator ID). When "logMessage" is relevant, it occurs just after any data parameters. When "force" is relevant, it occurs last.
    • The treatment of nulls versus empty strings in arguments for the modifyDatastream and modifyDisseminator methods of API-M is now more consistent. Arguments specified as null indicate that the original attribute of the component is to remain unchanged. Arguments specified as the empty string indicate the original attribute is to be set to the empty string. Arguments specified as non-null or non-empty indicate the original attribute is to be replaced by the specified value.

    Summary of API-M changes:

    • addDatastream: added parameters altIDs and logMessage
    • addDisseminator: added parameter logMessage; removed
    • parameters bDefLabel and bMechLabel
    • describeUser: [no change]
    • export: added parameters format, context
    • exportObject: [no change]
    • getDatastream: [no change]
    • getDatastreamHistory: [no change]
    • getDatastreams: [no change]
    • getDisseminator: [no change]
    • getDisseminatorHistory: [no change]
    • getDisseminators: [no change]
    • getNextPID: [no change]
    • getObjectXML: [no change]
    • ingest: added parameter format
    • ingestObject: [no change]
    • modifyDatastreamByReference: added parameters altIDs, versionable, MIMEType, and formatURI, and force
    • modifyDatastreamByValue: added parameters altIDs, versionable, MIMEType, formatURI, and force
    • modifyDisseminator: added parameter force; removed parameters bDefLabel and bMechLabel
    • modifyObject: [no change]
    • purgeDatastream: added parameters logMessage and force
    • purgeDisseminator: added parameter logMessage
    • purgeObject: added parameter force
    • setDatastreamState: [no change]
    • setDisseminatorState: [no change]
  12. PID Definition Syntax Relaxed

    Prior to Fedora version 2.0, the syntax for persistent identifiers (PIDs) was defined as a subset of the URN syntax, but was not strictly enforced by the server software. In version 2.0, the PID definition syntax has been relaxed to enable a wider range of possible PID values and the server software now strictly enforces the syntax of incoming PIDs.

    The following describes the syntactic constraints for PIDs in normalized form. The only differences with non-normalized PIDs are that the colon delimiter may be encoded as "%3a" or "%3A", and hex-digits may use lowercase [a-f].

    Length : maximum 64
    Syntax : namespace-id ":" object-id namespace-id:
    Syntax : ( [A-Z] / [a-z] / [0-9] / "-" / "." ) 1+ object-id:
    Syntax : ( [A-Z] / [a-z] / [0-9] / "-" / "." / "~" / "_" / escaped-octet ) 1+
    escaped-octet: Syntax : "%" hex-digit hex-digit hex-digit: Syntax : [0-9] / [A-F]
  13. Including PID As Default Parameter in Disseminations

    When constructing complex user-defined disseminators that reference disseminations from other objects, it is often handy to be able to pass the PID of the data object on to the nested dissemination requests. Prior to Fedora 2.0, the only way to accomplish this was to add a formal User Parameter to the disseminator method and use it to pass the value of the PID. This syntax is awkward since the PID of the data object is already contained in the dissemination request. For example:


    In the future, we plan to make it possible for the PID of the data object to be automatically passed as a parameter so it is always available downstream as a valid parameter on any dissemination request. As an interim solution to address this issue, Fedora 2.0 allows the PID of the data object to be passed as a default behavior mechanism parameter by using a special syntax of the DefaultInputParm element in the behavior mechanism object. For example:

    <fmm:DefaultInputParm defaultValue="$PID" label="The PID of the data object" parmName="PID" passBy="VALUE" required="true"/>

    Specifying a DefaultInputParm with a default value of "$PID" will result in the PID of the data object being passed on to the external service defined in the behavior mechanism object. In the WSDL section of the behavior mechanism object, reference the special DefaultInputParm as you would other parameters. For example:

      <wsdl:operation name="getService">
        <http:operation location=""/>

    At run time, this will be translated into

    A similar syntax is available to pass the object URI of the data object. If you want to pass the data object's URI, then specify a DefaultInputParm with a default value of "$objuri" and this will be translated at run time into

    where PID is the persistent identifier of the data object.

    The demo data object object named demo_SmileyStuff.xml and the associated behavior mechanism object named demo_DualResImageCollection.xml provide an example of the new syntax.

  14. Syntax Of Timestamp Values Extended

    Prior to Fedora 2.0, the syntax of timestamp values was to the nearest second. This range has been extended in Fedora 2.0 to include milliseconds to capture versioning changes that occur in less than one second. The new timestamp syntax is:

      e.g., 2005-01-17T12:13:54:185Z
  15. Redesign of Fedora Web Site and Documentation

    The Fedora web site at has been totally redesigned to provide enhanced readability, better navigation, and a more consistent "look and feel". Areas like the "Tools" section have been added to provide a place where Fedora users can share code and techniques they have developed using Fedora. The tools section is still under construction but will be available for accepting posts in the near future.

  16. Fedorial Tutorials

    A new series of tutorials is being developed that provides step-by-step instuctions for accomplishing common tasks with Fedora. The tutorials target a broad audience from system developers and repository managers to end users. Currently, there are three planned tutorials in the series:

    1. Introduction: Basic Concepts in Fedora
    2. Getting Started: Creating Fedora Objects and Using Disseminators
    3. Information Modeling: Designing Fedora Content Models
    As of Fedora 2.0, only the first two tutorials are available. The third tutorial is in progress and will be available in the spring of 2005. The tutorials can be found in the release in the tutorial directory under userdocs. The tutorials are also available on the web site at

C. Bug Fixes

  1. Incorrect GMT Datetimes - Creation dates for objects do not appear to have the correct GMT timestamps. (Bugzilla #52)

    When objects were created, the GMT timestamps stored did not reflect the correct time of object creation. This was bug in fedora.server.utilitites.DateUtility. The time zone offset was incorrectly being applied to the creation datetime. Objects now reflect the correct GMT creation datetimestamp.

  2. Managed datastreams inadvertently deleted - Under certain situations managed content datastreams could be deleted when purging similarly PIDed objects. (Bugzilla #53)

    This was a bug in Managed datastreams are stored internally using an identifier that consists of objPID + dsID + dsVerID. An errant regular expression was being greedy in matching which could result in similarly PIDed objects being deleted. The regular expression is fixed to prevent this from occuring.

  3. Errant space in SchemaLocation used by getnextPID - There is an erroneous space preceding the SchemaLocation in output for getNextPID. (Bugzilla #54)

    The SchemaLocation in the xml header output when running the getNextPID method of API-M and API-M-LITE contains an errant blank. This bug will only cause problems if trying to validate the xml output from the server. The errant space has been removed.

  4. Dublin Core description element missing from drop down menu in admin GUI client. (Bugzilla #55)

    The drop down menu for Dublin Core elements in the admin GUI does not contain the description element. The description element has been added to the drop down list.

  5. Unable to disseminate timestamped disseminations - Under certain situations, attempting timestamped disseminations would throw NullPointerException. (Bugzilla #56)

    This bug only occurs when attempting timestamped disseminations using user-defined disseminators (i.e., disseminators other than the default disseminator).

    This was a bug in When datastream state checking was added in Fedora 1.2, the section of code dealing with populating the DisseminationBindingInfo class did not include the new variable for datastream state. As a result this variable in the class is never initialized which leads to the eventual null pointer exception when attempting timestamped disseminations with user-defined disseminations.

  6. Serializer fails on export of bMech objects. Exporting bMech objects throws NullPointerException. (Bugzilla #57)

    The problem was that the method that checked WSDL and SERVICE-PROFILE datastreams for instances of the local pattern "http://local.fedora.server" did not have this pattern compiled. This caused a null pointer exception when the xml datastreams were searched for this pattern. Bmech objects now export correctly.

  7. Object Label updates not reflected in ObjectProfile - Changing an object's label in the admin GUI is not reflected when disseminating objectProfile. (Bugzilla #58)

    This was a bug in the replicator where the object label field was not being updated when the object label was changed in the object xml. Object label changes are now properly displayed when disseminating the objectProfile.

  8. Timestamp information not displayed in all views of Default Disseminator (Bugzilla #59)

    Timestamp information was not being properly handled by the XSL stylesheet that is used to style the output from viewItemIndex. This is now corrected and timestamp info is properly displayed in all views of the default disseminator (getObjectProfile, viewItemIndex, and viewMethodIndex).

  9. Date issues when Server and Client in different Timezones - Creation dates for objects can be incorrect when server and client are in different time zones. (Bugzilla #60)

    When a Fedora server is in one time zone and a Fedora client is in a different time zone, it was discovered that incorrect timestamps were displayed by the client when retrieving objects from the server.

    If you open the object editor on an existing object and go to the Datastreams pane, you will see that the created dates on the version timeline do not match what's in the datastream at the server.

    Even though the admin GUI client is getting the creation data from the server (via the java Calendar and Date classes), it appears that the client evaluation of the values considers the system clock current settings which are adjusted based on time zone. This is probably embedded in the underlying implementation of the java Calendar class.

    The fix was to redesign the handling of timestamp information by both the Fedora client and server. Fedora now standardizes on all dates PRODUCED by Fedora as STRINGS in ISO8601 format: mm-dd-yyThh:mm:ssZ. This allows Fedora to accept strings in mm-dd-yy or mm-dd-yyThh:mm:ss or mm-dd-yyThh:mm:ssZ format, to keep backward compatiability.

  10. Problem when versions get assigned the same timestamp (Bugzilla #64)

    In certain situations when modifications to an object component occur in rapid succession it was observed that a timestamp granularity of seconds was insufficient and you could have two versions with the same timestamp values to the nearest second. The solution was to extend the value of timestamps to include milliseconds to prevent any potential conflict.

  11. Inconsistent treatment of nulls versus empty string in arguments of modifyDatastream and modifyDisseminator methods of API-M (Bugzilla #68)

    The treatment of nulls versus empty strings in arguments for the modifyDatastream and modifyDisseminator methods of API-M is now more consistent. Arguments specified as null indicate that the original attribute of the component is to remain unchanged. Arguments specified as the empty string indicate the original attribute is to be set to the empty string. Arguments specified as non-null or non-empty indicate the original attribute is to be replaced by the specified value.

  12. Error when editing disseminator label when using McKoi (Bugzilla #76)

    When attempting to edit a disseminator's label when using McKoi as the underlying SQL database, the server would throw SQLException. This error was due to a typographical error in the database column name being used. Oracle and MySQL are case insensitive regarding column names, but McKoi is case sensitive. This allowed dissemination labels to work under MySQL or Oracle implementations, but fail with McKoi implementations. The case of the column name is now corrected and works for all three database implementations.

  13. Oracle error on ingest: cannot insert NULL into DSBIND.DS (Bugzilla #77)

    In certain situations when using Oracle as the underlying SQL database, ingest would fail with SQLException. The cause was attempting to insert NULL into the column dsBindKeySeq when no value was specified in the object for this optional value. Oracle does not allow NULL for this column type so the code has been modified to insert zero("0") when dsBindKeySeq is not specified in the object.

  14. Editing object label containing apostrophe throws SQLException (Bugzilla #82)

    When attempting to edit an object's label containing an apostrophe, the server responds with SQLException. The apostrophe character is a special character that must be properly escaped in SQL INSERT statements. Object labels are now checked for special characters and properly escaped before issuing the SQL INSERT command.

  15. Oracle char(1) column types return with space padding (bugzilla #85)

    It was observed that when using Oracle as the underlying SQL database, column types of char(1) would return with space padding which could result in errors downstream. This was not the case with McKoi or MySQL. The fix was to change the db schema column type to use varchar(1) instead of char(1) everywhere in the db schema.

  16. Object label containing ampersand character throws Exception when attempting to disseminate getObjectProfile method (bugzilla #86)

    It was observed that creating an object with a label containing the ampersand character would later cause the dissemination of the getObjectProfile method to fail. This resulted from special characters, like the ampersand character, not being properly escaped when written to dynamically generated xml served by Fedora. XML special characters are now properly escaped before being written to the outgoing xml stream so ampersands and other special xml characters can safely be included in object labels.


4. 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:


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



5. 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 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. Ignoring FEDORA_JAVA_HOME 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).



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



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

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 object, then converted to a object. The URL string is finally obtained via the toString() method of the 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 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 "" 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.



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



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



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

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.



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