Thank you Mark,
On 11/06/2012 02:50 PM, Mark H. Wood wrote:
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.
I agree, but given my bean definition (see attached file) I am really
surprised that it is being added, since there is no autowiring declared
here.
- 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.
Do you happen to know which script is responsible for the item webpages?
- 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.
Okay, I thought my provider could just use the Handle table since I do
not plan to employ any default handles which would use that table in the
first place.
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.
Yeah, but as I said, it should not be autowired (again, see the attached
file)... I'm quite confused I must say.
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.
------------------------------------------------------------------------------
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
--
Joachim Bingel
Institut für Deutsche Sprache, Zentrale Forschung
R5, 6-13, 68161 Mannheim
+49 - (0)621-1581-456 | http://www.ids-mannheim.de
<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright (c) 2002-2010, DuraSpace. All rights reserved
Licensed under the DuraSpace License.
A copy of the DuraSpace License has been included in this
distribution and is available at: http://www.dspace.org/license
-->
<beans xmlns="http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:context="http://www.springframework.org/schema/context";
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd";>
<context:annotation-config />
<context:component-scan base-package="de.mannheim.ids.pid.dspace" />
<!-- Identifier Service Application Interface. Will be autowired with
any Identifier Providers present in Spring context.
-->
<!--bean id="org.dspace.identifier.IdentifierService"
class="org.dspace.identifier.IdentifierServiceImpl"
autowire="byType"
scope="singleton"/-->
<!-- provider for using the custom handle identifier instead of the default one.
This is the same specifications as in the suggested and uncommented bean below
which would inject the versioned handle identifier-->
<bean id="org.dspace.identifier.HandleIdentifierProvider"
class="de.mannheim.ids.pid.dspace.IDSIdentifierProvider"
scope="singleton">
<property name="configurationService" ref="org.dspace.services.ConfigurationService"/>
</bean>
<!-- provider for using the versioned handle identifier instead of the default one. -->
<!--<bean id="org.dspace.identifier.HandleIdentifierProvider" class="org.dspace.identifier.VersionedHandleIdentifierProvider"-->
<!--scope="singleton">-->
<!--<property name="configurationService" ref="org.dspace.services.ConfigurationService"/>-->
<!--</bean>-->
</beans>
------------------------------------------------------------------------------
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
