[ https://jira.duraspace.org/browse/DS-875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Donohue updated DS-875: --------------------------- Fix Version/s: (was: 1.8.0) 1.7.2 > DSpace Configuration service error when using "dspace" script. > -------------------------------------------------------------- > > Key: DS-875 > URL: https://jira.duraspace.org/browse/DS-875 > Project: DSpace > Issue Type: Bug > Components: DSpace API > Affects Versions: 1.7.1 > Reporter: Kevin Van de Velde > Priority: Major > Fix For: 1.7.2 > > Attachments: dspace_script_bugfix.patch > > > 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 > search). > From the dspace script: > FULLPATH=$CLASSPATH:$JARS:$DSPACEDIR/config > java $JAVA_OPTS -classpath $FULLPATH org.dspace.app.launcher.ScriptLauncher > "$@" > Conclusion: > 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.duraspace.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel