Last month, the eXtensible Catalog (XC) project posted job openings for Java developers. These are short-term, grant-funded projects and, having been on the hiring side of that equation before myself, I know how difficult it is to get good people for a one- or two-year project. The XC posting is different, though, in one important way: it is possible to have XC buy out the time of a developer on staff for the time that the development is happening.
Thanks, Noel, and everyone else who made the video editions of Code4Lib 2008 presentations possible. I just had a chance to notice that the video from my JPEG2000 to Zoomify Shim lightning talk was online:
Some updates since the post and the presentation were first done. The code that exists in the source code repository now was refactored to use JJ2000 as part of the Sun package. We were seeing non-threadsafe problems with Kakadu and thought that using the multithreaded ImageIO package would help. Unfortunately, even with extensive caching, it did not. My next task is to bring Kakadu back into the picture using the threadsafe JNI implementation that is part of the ImageIO-ext project to see if that helps.
I’ve been working to get JBoss Seam tied into Fedora, and along the way thought it would be wise to stop and document a core concept of this integration: the centrality of Fedora Disseminators in the the design of the Ohio Digital Resource Commons. Although there is nothing specific to JBoss Seam (a Java Enterprise Edition application framework) in these concepts, making an object “render itself” does make the Seam-based interface application easier to code and understand. A disseminator-centric architecture also allows us to put our code investment where it matters the most — in the repository framework — and exploit that investment in many places. So what does it mean to have a disseminator-centric architecture and have objects “render themselves”?
Sometimes the best way to solve a programming problem is to see how others have done the same thing. When that happens, having immediate access to the various search engines helps get you back on track quickly. Here are OpenSearch plug-ins (suitable for Firefox and MSIE7) that will search the Java code in five of the more popular source code search engines.
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 . 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 onand was last updated on 18-Jan-2007.
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]:
- Fedora repository is now a web application (.war) that can be installed in any container
- Fedora authentication has been refactored to use servlet filters (no longer Tomcat realms)
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.
We’re beginning a new phase of our digital library development at OhioLINK and an oversimplification of one of the consequences of this new phase is that we will be developing more software from scratch rather than adapting stuff that we find out there on the net. (Another consequence of this new phase is our interest in applying the Service-Oriented Architecture paradigm to library applications.) In previous phases, we were somewhat at the mercy of whatever development framework was used in the application we were adopting. As we start this new development where we control more of our own destiny, we wanted to take a step back and look at the available frameworks to support our development efforts. The options we identified at the start were plain Java servlets, Apache Struts, Spring Framework, and EJB3 with JBoss SEAM.