On Tue, Nov 06, 2012 at 10:54:36AM +0100, Joachim Bingel wrote: > I don't know whether this is intended behaviour or I'm doing something > wrong, but my (finally successful) implementation of an external PID > service that extends the org.dspace.identifier.IdentifierProvider > creates the default Handle (hdl:...) along with every PID that my own > service creates. Maybe the problem is best described in bulleted points:
I would be surprised if the pluggable identifier service were not designed to permit assignment of multiple identifiers to a single object, if so configured. I think it's intended behavior, but I believe that you should be able to change it. > - I inject my identifier service in the > [dspace]/config/spring/api/identifier-service.xml (using the bean that > is provided for the VersionedHandleIdentifierProvider but replacing the > class value with my class). > > - I also tried uncommenting the bean in the same file that autowires all > classes implementing IdentifierServiceImpl This is where I would expect that HandleIdentifierProvider is being added to the list. > - When I submit a new item in DSpace, it gets the desired PID that my > service generates, but also a default hdl:... identifier > > - The identifier that is shown in the "Please use this identifier..." > box is the hdl identifier, which is not desired. Also, the item's URL is > the handle URL instead of "mine". The web page code should need to be modified for your intended use. It probably just asks for the Handle. > - Both identifiers are listed in the "Handle" table of the DSpace databse. I would suggest that this behavior is incorrect. I think that the Handle table ought to be for the exclusive use of the Handle minter. Each provider requiring its own state should make its own arrangements for recording that state. > I can think of two reasons for this: > 1) The standard handle class > (org.dspace.identifier.HandleIdentifierProvider) is used somewhere else > where the autowiring has no effect I don't understand: if HandleIdentifierProvider is not wired then it should never be called. I think it is being called because it *is* autowired. I would comment out the bean definition for HandleIdentifierProvider so that Spring has no knowledge of it and *cannot* wire it, if I want to prevent allocation of Handles. However, this may break other parts of DSpace. There has long been an assumption that every Item has a Handle, and that assumption may still exist here and there in the code. It may be expedient to allow Handle minting (using the reserved 123456789 prefix) but remove the Handles from casual view. -- Mark H. Wood, Lead System Programmer [email protected] Asking whether markets are efficient is like asking whether people are smart.
pgpK1eFgvGgoH.pgp
Description: PGP signature
------------------------------------------------------------------------------ LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
