Hi all,
One of my tasks for the 3.4 release, which I'd hoped to complete last
week, was a "legacy llstore adapter". Since package names have
changed since 3.3 (from fedora.server to org.fcrepo.server), and the
LLStore interface itself has changed a bit, the goal of this work was
to allow legacy plugins written against the old interface
(non-Akubra-based) to work with 3.4 without requiring code changes to
them.
It didn't work out so well :(
My goal was to put together an adapter module that spoke the new
interface, but wrapped instances conforming to the old interface.
Originally I thought I could just use the 3.3 jars that included the
old lowlevel package classes. I started going down this road last
week, and quickly discovered that in order for the adapter to work, it
would have to depend on a lot more than the legacy lowlevel classes.
But I held out hope, thinking I could put together a huge jar with all
the dependent classes and libraries. This turned out more challenging
than I expected; I still felt it was doable...just ugly.
But that wasn't the big problem. No, the main problem I ran into, and
something that looks insurmountable at this stage, is the old modules'
dependency on a working Server instance to be provided to their
constructors. In order to give them what they expect without
requiring their code to change, I'd have to provide a
fedora.server.Server instance that wraps the org.fcrepo.server.Server
instance that is available. Worse, they may actually want to use that
Server instance...and call getModule("old-module-interface-name"). I
can't see a way around that maze of twisty passages...
Unfortunately, this means old versions of third-party llstore plugins
that are not Akubra-based aren't going to work with this release.
Right now, trunk has two options:
akubra-fs (the default option, this is the akubra impl that goes
against a plain old filesystem)
legacy-fs (the legacy, default filesystem-based llstore
implementation, non-Akubra-based)
Thoughts/ideas?
Thanks,
Chris
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Fedora-commons-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
