$Id: release-notes.dbx,v 1.24 2003/09/02 20:59:29 cwilper Exp $
Copyright © 2003 The Rector and Visitors of The University of Virginia and Cornell University
Table of Contents
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
The bug was an errant update query for the SQL database that when modifying a datastream it had the potential for corrupting the SQL database dsBind table. It only got introduced when attempting to modify a Datastream using the View/EditDatastream menu option in the admin GUI. With this fix, the modifyDatastream command is safe to use.
OAI-PMH interface was not sending the correct HTTP Content-type header value to indicate the character encoding of the XML, and as a result, the Servlet that provides OAI-PMH functionality was not properly encoding the output in UTF-8.
It is now possible to change a managed content datastream's label without changing its content. Previously, the API-M method, modifyDatastreamByReference required that something was provided for the DSLocation. Now, if DSLocation is passed in a null or empty, the original datastream content will be used (no change).
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.
The API-A and API-A-LITE interfaces now define and implement the “describeRepository” request. This request will provide information about the repository server including repository name, version, base URL, and other attributes. The repository information can be obtained in either XML or HTML formats.
The API-A-LITE syntax is: http://yourhost:yourport/fedora/describe
The Fedora server now has internal support for avoiding breakage of self-referential URLs (i.e., URLs that contain the hostname and port of the Fedora server itself). This change allows the Fedora server host and port to be re-configured without breaking digital objects that contained URLs that referred to a previous host and port configuration. There are two places where self-referential URLs may exist: (1) in Behavior Mechanism Objects, where service bindings refer to a “local service” that runs within the repository server, and (2) in objects that contain a Datastream that references a dissemination of a digital object that is stored in the local repository.
Java Docs will now show the revision number generated from the Fedora CVS repository. These will not reflect the current Fedora software release number, but the actual version of the particular java source file. This will make it easier to determine whether a particular piece of code has changed from one Fedora release to another. For example, the source file FedoraAccessServlet.java has a release number of 1.58 as distributed within the Fedora 1.1 software.
All non-essential debugging and logging messages were removed from standard out. All meaningful server messages are now sent to the Fedora server log file.
Specifically, a failure in running the Batch Build and Batch Build and Ingest menu items in the AdminGUI client when running the client in X-Windows. The batch utility could not correctly resolve file locations of object-specific files.
REPORTED ERROR: Recoverable error. java.net.UnknownHostException
FIX: The problem was traced to line 196 of fedora.client.batch.BatchXforms and has to do with the number of slashes in the file path (i.e., file:///). Solaris (and perhaps UNIX in general) wants only 2-trailing slashes instead of three. Places in the code where this has been a problem have been modified to ensure that any such URL strings are instantiated as a java.io.File object, then converted to a java.net.URI object. The URL string is finally obtained via the toString() method of the java.net.URI class. The strings generated in this manner are acceptable on both Windows and UNIX platforms.
The problem occurs because the METS xml files for the demo digital objects contain URLs that assume that the repository is running on port 8080. The URLs point to the location of the demo content that is served up by the local repository server.
REPORTED ERROR: [DefaultExternalContentManager] returned an error. The underlying error was a fedora.server.errors.StreamIOException The message was "Server returned a non-200 response code (404) from GET request of URL: http://localhost:8080/demo/batch-demo/thumb/americanacademy.jpg"
FIX: There are two kinds of demos that are affected: “batch demos” that are loaded via the batch tool and “local server demos.” The content for the batch demos has been moved to www.fedora.info where it will always be available. The METS xml files for the batch demo objects now have URLs that point to the demo content at this stable location. The “local server demos” are intended to be run completely within the local server context (meaning a network connection is not necessary to run them). The content for these objects must, therefore, remain local to the Fedora server. A new command line utility called “fedora-convert-demos” is provided to convert demo object xml files to reference the currently configured host and port. If the Fedora repository is configured to a host and port other than the default of localhost:8080, the “fedora-convert-demos” utility should be run before ingesting local demo objects into the repository. The “fedora-convert-demos” is found in the FEDORA_HOME/client/bin/ directory. Instructions on running the utility can be found in the Client Documentation section of the system documentation.
The Fedora server fails during initialization of the DefaultAccess module. DefaultAccess tries to use a dependent module (DOManager) that has not yet been loaded by the Fedora server. The problem does NOT occur in Java 1.4.0 or 1.4.1.
REPORTED ERROR: Can't get a DOManager from Server.getModule
FIX: DefaultAccess is a server module, that itself needs access to other server modules. The DefaultAccess module initialization fails because DefaultAccess tries to access a dependent module (DOManager) that has not yet been loaded by the server. The problem is that server modules are not loaded in any particular order on server startup. Within any particular module’s initModule method, you can't assume that ANY other modules are available from the server via the getModule(...) call. The solution is to move chunks of code like this to the postInitModule(...) method of the module in question. At THIS point in the server's lifecycle, you can assume that all modules have been loaded and are available via getModule(...), and that their initModule(...) methods have been called. Fedora server modules are listed in a HashMap. The reason that this problem showed up in Java 1.4.2 and not prior versions is that the order in which entries are put in a HashMap has changed in Java 1.4.2. It was just coincidence that the problem did not show up in prior Java versions (that loaded the HashMap in a different order.)
There were several places in the Fedora 1.0 code base where the default host and port of the server was hard-coded as “localhost:8080”. This required the repository administrator to make multiple changes when configuring a Fedora server to run on a different host or port.
FIX: All references to hostname and port are now driven off the fedoraServerHost and fedoraServerPort parameters in the Fedora server configuration file (fedora.fcfg). With this fix, a simple modification to these parameters and a re-starting the server is all that is necessary to change where the fedora server runs.
The Fedora server shutdown and redirect ports were not configurable. They were hard-coded in the Tomcat server_template.xml file as “8005” and “8443” respectively.
FIX: These are now configurable in the Fedora server configuration file (fedora.fcfg).
The repository domain name part of the OAI identifier was not configurable. It was hard-wired to be “fedora.info” which is not unique to a repository.
FIX: The Fedora server configuration file (fedora.fcfg) now has a repository domain name parameter in the OAI-PMH module.
Fedora 1.0 and 1.1 servers are unable to mediate access to remote datastreams that are password-protected. Currently, Fedora provides IP restriction for its own interfaces (API-A and API-M). However, at this time, it does not handle backend security handshakes with remote servers. Thus, when a digital object makes reference to a datastream on a remote server and that server protects its content with HTTP Basic Authentication, Fedora will not be able to negotiate with the remote server to access that content. The way around this is to make sure that such datastreams are marked with as type R (Redirected Content). This is done in the METS XML file by setting OWNERID=R on the METS file element that used to encode the datastream.
Fedora 1.0 and 1.1 servers cannot currently communicate with external web services that require the SOAP messaging protocol. This means that Behavior Mechanism Objects should not include WSDL that describes a service with SOAP bindings. In the current release, Fedora is able to communicate with web services that can be accessed via URLs using a simple HTTP GET (REST-style web services). The next release of Fedora will include a SOAP dispatching module which will enable the Fedora server to send SOAP requests to other services and receive SOAP responses from those services.
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.
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.
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
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.
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:
http://hostname:port/userdocs
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.
This release includes major changes since the December Beta1 release that include the following additions and enhancements.
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.
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).
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.
The implementation of a new search interface has been added. Upon ingestion, metadata from the Fedora System Metadata section and the Dublin Core (DC) Metadata section of the object are indexed in a relational database, and may be searched using this interface. The DC Metadata section is an optional Implementor-Defined XML Metadata datastream in the object, where the "Datastream ID" is DC, and the XML conforms to the schema at: http://www.openarchives.org/OAI/2.0/oai_dc.xsd. If such a datastream is not provided, only the System Metadata will be indexed for that object. The search interface provides both simple and advanced searching via a web page included with the repository software. All queries are case insensitive. Simple search enables queries of words and phrases occurring anywhere in an object s indexed metadata fields. Advanced Search enables fielded searching across any combination of metadata elements using string comparison operators (= and ~) for string fields, and value comparison operators ( =, >, ≥, <, ≤ ) for date fields (dc:date fields may be treated as both). The wildcards, * and ? may be used in any string-based query.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Added a release directory for downloading both milestone source builds and nightly binary distributions, and created a wiki for user support and FAQs.
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.
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.
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.
The management API is exposed via SOAP over HTTP and has the following methods implemented:
ingestObject
purgeObject
listObjectPIDs
exportObject
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.
The access API is exposed via SOAP over HTTP and has the following methods implemented:
getBehaviorDefinitions
getBehaviorMethods
getBehaviorMethodsAsWSDL
getObjectMethods
getDissemination
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.
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.