Outstanding IssuesISSUE-1: Ingest of demo:5,18,29,14 fail with non-fedora context CAUSE: Hardcoded URLs that don't use local.fedora.server. ACTION: Review all demo objects and use local.fedora.server where possible WHO: Aaron STATUS: ? ISSUE-2: Smiley demo "list" dissemination doesn't work with non-fedora context CAUSE: The SDep, demo:CollectionImpl requires the "fedora" part of the path to be specified: <http:operation location="fedora/risearch[...]"> ACTION: Modify Fedora so that, when the service URL is constructed, if it is not an http[s] URL: 1) If it starts with /, assume http://host:port WHO: Aaron STATUS: As it turns out, implementing a fix for portable relative links to resources in and outside the fedora app server context is a bit more complicated than just fixing the WSDL mechanisms. Basically, one of the demo objects (demo:SmileyStuff) has a URL reference datastream that contains (http://local.fedora.server/fedora...). So.. we would need to extend our solution to datastreams as well in order to be a complete solution. Additionally.. DOTranslationUtility tries its best to convert ALL URLs that reference local resources into general form (i.e. it will look for "http://localhost:8080/...", for example, and convert it to "http://local.fedora.server/...). This procedure does not take into consideration fedora app server context, and it too is broken at present. So.. the task is now considerably weightier. I called Bill for a sanity check, and we both agreed that this issue has enough consequences that it probably warrants a larger discussion. So.. could we (by 'we', I mean anybody who is interested in this issue) meet tomorrow some time to discuss this? How about 10 again? In the meantime, I created two JIRA issues, and decided to go forward with one solution and see if I reach any additional problems. Because our discussion may have bearing on the ultimate direction this takes, I've decided to put any work on this in a separate branch. This describes the issue as a whole: https://fedora-commons.org/jira/browse/FCREPO-486 ISSUE-3: System tests don't pass with non-fedora context CAUSE: Not fully determined, but ISSUE-1 above is one probable cause. At least ConfigA was failing for Eddie when he tried it. Eddie also saw strange references to 127.0.1.1, but grepping the code for this turned up no result. Also, Andrew noticed a failure with testBatchModify, which Kai has fixed, and Andrew has updated the documentation. ACTION: Re-run tests, making sure to set the correct fedora.appServerContext in build.xml and webapp_name in env-server.sh beforehand. WHO: Eddie STATUS: ? ISSUE-4: fedora-ingest-demos doesn't work with non-fedora context and usage message is incorrect. CAUSE: Doesn't pass optional parameters, so the ctx param is never passed in. ACTION: Fix usage message and allow it to take ctx WHO: Kai STATUS: ? ISSUE-5: fedora-rebuild gives confusing error message with non-fedora context when WEBAPP_NAME is not changed in env-server.sh/bat CAUSE: The fedora-rebuild script uses this info to determine what the classpath is, in order to run the right java ... command. ACTION: Give better error message. (Also see DOC-1) WHO: Kai STATUS: ? ISSUE-6: Some commandline scripts not covered by tests (Kai noticed) ACTION: Identify which ones WHO: Kai STATUS: ? ISSUE-7: Ingest and add managed datastream not working with new admin ui. CAUSE: Repeatable in Chris' environment when AuthN off for API-A and first attempt to POST to rest api is via one of these actions. This appeared to be happening because the popup window closes before the browser has a chance to prompt for credentials. So we were aiming for a solution that ensured credientials would be prompted for beforehand. However, it now appears to be happening regardless of the credentials... the data just doesn't make it into Fedora in some cases. Keeping the upload popup open after submit has been pressed (manually removing onSubmit="window.close()") seems to consistently allow this to succeed, regardless of credentials. ACTION: ?? WHO: Bill STATUS: ? ISSUE-8: Analyzer issues (harmless) warning when running with Derby embedded CAUSE: Derby embedded requires the database to be shutdown through java code before the vm exits, or it issues a warning. ACTION: Document that this is a harmless warning in the migration doc WHO: Chris STATUS: ? ISSUE-9: Upgrade from 3.1 still needs to be tested. ACTION: Normal install (point new fcfg to old db+data/ dir), then run RI rebuilder for Mulgara WHO: Eddie STATUS: ? ISSUE-10: Journal RMI Reciever not distributed or acknowledged in docs ACTION: Make a build.xml target for a self-contained jar distribution (with version=3.2) and note it's existence in journaling documentation. WHO: Aaron STATUS: ? Outstanding DocumentationDOC-1: Finish doc updates for webapp context configuration (with note that it's experimental) WHO: Andrew, with help from Kai STATUS: Installer text updated. New doc started here DOC-2: Update rebuilder documentation WHO: Chris STATUS: ? DOC-3: New doc: "Configuring Lowlevel Storage" (covers Akubra), linked from install/config WHO: Chris STATUS: ? DOC-4: New doc: "Web-Based Admin UI" WHO: Bill STATUS: ? DOC-5: Release Notes WHO: Chris STATUS: ? DOC-6: Review migration guide for accuracy WHO: Aaron STATUS: ? DOC-7: SWORD-Fedora integration guide (FCREPO-404) WHO: Eddie STATUS: ? |
