[
https://jira.duraspace.org/browse/DS-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20383#action_20383
]
Kevin Van de Velde commented on DS-875:
---------------------------------------
Stuart,
Although I'm also not a fan of losing the CLASSPATH the issue is should a
CLASSPATH be set and this CLASSPATH doesn't have any subdirectories (don't know
if this can happen) it will not retrieve a single config file from any of the
jars in the FULLPATH.
Once the PathMatchingResourcePatternResolver encounters an invalid (invalid
being a directory without a subdirectory) CLASSPATH option it will crash.
Perhaps we need to look into something that loops over all classpath options
and attempts to resolve them one by one, but I'm not a fan this personally
because I find that quite dirty.
Personally I would prefer another option but I can't seem to think of one at
the moment.
> 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
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including 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
