Uploaded image for project: 'DSpace'
  1. DSpace
  2. DS-875

DSpace Configuration service error when using "dspace" script.



    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.7.1
    • Fix Version/s: 1.7.2, 1.8.0
    • Component/s: DSpace API
    • Labels:
    • Attachments:
    • Comments:
    • Documentation Status:


      When using the dspace script (located in

      {dspace.dir}/bin directory) in DSpace 1.7.1 the following error will occur:

      java.lang.IllegalArgumentException: Resource path [{dspace.dir.path}/bin/dspace] does not denote a directory
      at org.springframework.core.io.support.PathMatchingResourcePatternResolver.retrieveMatchingFiles(PathMatchingResourcePatternResolver.java:563)
      at org.springframework.core.io.support.PathMatchingResourcePatternResolver.doFindMatchingFileSystemResources(PathMatchingResourcePatternResolver.java:543)
      at org.springframework.core.io.support.PathMatchingResourcePatternResolver.doFindPathMatchingFileResources(PathMatchingResourcePatternResolver.java:526)
      at org.springframework.core.io.support.PathMatchingResourcePatternResolver.findPathMatchingResources(PathMatchingResourcePatternResolver.java:342)
      at org.springframework.core.io.support.PathMatchingResourcePatternResolver.getResources(PathMatchingResourcePatternResolver.java:276)
      at org.dspace.servicemanager.config.DSpaceConfigurationService.loadInitialConfig(DSpaceConfigurationService.java:390)
      at org.dspace.servicemanager.config.DSpaceConfigurationService.<init>(DSpaceConfigurationService.java:62)
      at org.dspace.servicemanager.DSpaceKernelImpl.start(DSpaceKernelImpl.java:145)
      at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:51)

      This error in itself is completely harmless since it is actually a log bug, there is an e.printstacktrace() that should have been a log.error, the configuration service will just fail to load the dspace config files in the jars (which is harmless since the configuration service isn't used by DSpace at the moment).

      The reason why the error is thrown lies in the configuration service, the following method is called when attempting to retrieve .cfg files from the classpath.

      PathMatchingResourcePatternResolver patchMatcher = new PathMatchingResourcePatternResolver();
      Resource[] resources = patchMatcher.getResources("classpath*:dspace/config-*.cfg");

      From the Spring documentation (http://static.springsource.org/spring/docs/2.5.x/reference/resources.html):

      Please note that "classpath*:" when combined with Ant-style patterns
      will only work reliably with at least one root directory before the
      pattern starts, unless the actual target files reside in the file
      system. This means that a pattern like "classpath*:*.xml" will not
      retrieve files from the root of jar files but rather only from the
      root of expanded directories. This originates from a limitation in the
      JDK's ClassLoader.getResources() method which only returns file system
      locations for a passed-in empty string (indicating potential roots to

      From the dspace script:

      java $JAVA_OPTS -classpath $FULLPATH org.dspace.app.launcher.ScriptLauncher "$@"

      The problem is caused by the fact that the JDK is expecting directories or directories with at least one subdirectory to be passed in the FULLPATH argument when invoking Java. It is obvious that {dspace.dir}

      /bin/dspace violates these requirements, causing the process to throw an exception when trying to use this location as a directory. In order to solve this, I suggest removing the $CLASSPATH variable from the FULLPATH argument because I do not expect it to be of any use when running DSpace processes. I have verified the behavior of the dspace command after removing the $CLASSPATH variable and all processes seem to be working fine. However, in case this variable would be required for a reason I missed, a different solution should be used. The easiest alternative would be to properly handle the $CLASSPATH argument in order to avoid the exception.




            mdiggory Mark Diggory
            kevin van de velde Kevin Van de Velde (Atmire)
            1 Vote for this issue
            0 Start watching this issue