Building an Institutional Repository Interface Using EJB3 and JBoss Seam

This tour is designed to show the overall architecture of a FEDORA digital object repository application within the JBoss Seam framework while at the same time pointing out individual design decisions and extension points that are specific to the Ohio Digital Resource Commons application. Geared towards software developers, a familiarity with Java Servlet programming is assumed, although not required. Knowledge of JBoss Seam, Hibernate/Java Persistence API, EJB3 and Java EE would be helpful but not required; brief explanations of core concepts of these technologies are included in this tour.

The tour is based on revision 709 of /drc/trunk and was last updated on 18-Jan-2007.

Looking Forward to Version 2.2 of FEDORA

Sandy Payette, Co-Director of the Fedora Project and Researcher in the Cornell Information Science department, announced a tentative date for the release 2.2 of the FEDORA digital object repository.

The Fedora development team would like to announce that Fedora 2.2 will be released on Friday, January 19, 2007.

This new release will contain many significant new features and enhancements, including [numbers added to the original for the sake of subsequent commentary]:

  1. Fedora repository is now a web application (.war) that can be installed in any container
  2. Fedora authentication has been refactored to use servlet filters (no longer Tomcat realms)

Java Application for Batch Processing FEDORA Objects

We had a need today to transform an XML file with a custom DTD into Dublin Core; the custom XML file is a datastream in our FEDORA repository and we want to put the Dublin Core XML file back into the FEDORA object as the DC datastream. This took a slew of technologies and techniques: reading a datastream out of the FEDORA repository using API-A, parsing XML documents using the Java DOM library, creating a new document with the correct namespaces using Java DOM, and modifying the DC datastream in the repository using API-M.

Sakai gets JSR-170 support; possible integration point with FEDORA?

Earlier this year, I was on a quest to hook a FEDORA content repository into the Sakai collaboration and learning environment. What looked at first to be a fairly easy integration turned out to be rather complicated and I set the project aside for another time. Today brings word from Ian Boston of a JSR-170 implementation in Sakai:

Colorado Alliance of Research Libraries to build a consortial repository using FEDORA

On Friday, the Colorado Alliance of Research Libraries announced the creation of a consortium-wide digital repository project similar to that of the Ohio Digital Resource Commons.

Colorado Alliance Digital Repository Project Approved


The Board of Directors of the Colorado Alliance of Research Libraries has approved initial funding for a consortium-wide digital repository project at its October 19, 2006 meeting.

The Board of Directors of the Colorado Alliance of Research Libraries has approved initial funding for a consortium-wide digital repository project at its October 19, 2006 meeting. The project will use the Fedora open source software which was selected after a long evaluation process by the Institutional Repository Implementation Team, chaired by John Culshaw from the University of Colorado at Boulder.

GSoC: JPEG2000 JPIP Server and Viewer Applet

OhioLINK was excited and privileged to participate in the second annual Google Summer of Code — a program to inspire young developers and provide students in Computer Science and related fields the opportunity to do work related to their academic pursuits during the summer, and to support existing open source projects and organizations. This is the first of three posts summarizing the efforts of three students; this one details the work of Juan Pablo Garcia Ortiz, a Ph.D. candidate at the University of Almeria in Spain, to build a JPEG2000 JPIP Streaming Server and Client Browser Viewer Applet. This is an edited version of his final report.

Why FEDORA? Answers to the FEDORA Users Interview Survey

The Fedora Outreach and Communications team is conducting a survey of the high-level sense of passion and commitment inherent in the Fedora community. I’ve posted some answers back to the FEDORA wiki on behalf of OhioLINK, and am also including the responses here as it fits into the “Why FEDORA?” series of blog postings. (If you are reading this through a RSS news reader, I think you’ll have to actually come to the DLTJ website and scroll down to the bottom of this post to see the table of contents of the series.) On with the responses!

XTF and FEDORA — Comments from the Community

Some questions and observations that have come in through mechanisms other than blog comments on the analysis of the XTF/FEDORA integration. I’ve reproduced those here for the sake of completeness, but also be sure to go back to the first two entries in this series to read the comments there as well.

Indiana University’s Observations


As it turns out, Indiana University is considering much the same path. They have an existing FEDORA-based repository and a number of XTF projects that have been in development for a while. They, too, are looking to put these two technologies together and have a page on their project website with Digital Repository Architecture > Search”>IU’s observations of an XTF plus FEDORA (plus more!) combination.

Analysis of CDL’s XTF textIndexer to Replace the Local Files with FEDORA Objects

This is a continuation of the investigation about integrating the California Digital Library’s XTF software into the FEDORA digital object repository that started earlier. This analysis looks at the textIndexer module in particular, starting with an overview of how textIndexer works now with filesystem-based objects and ending with an outline of how this could with reading objects from a FEDORA repository instead.

XTF’s Native File System handler

Natively, XTF wants to read content out of the file system. The core of the processing is done in these two class files:

TextIndexer.java