[
https://jira.duraspace.org/browse/DS-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20037#action_20037
]
Kevin Van de Velde commented on DS-875:
---------------------------------------
I tested this issue on my local windows 7 computer at home and on windows it
loads the config files from the jars without throwing any exceptions. (Even
added a config file in a test jar just to make sure that it really did load the
properties)
So this issue could be a linux/osx bug only, this may be one of the reason
there haven't been many complaints as of yet.
> 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.8.0
>
> 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
------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been
demonstrated beyond question. Learn why your peers are replacing JEE
containers with lightweight application servers - and what you can gain
from the move. http://p.sf.net/sfu/vmware-sfemails
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
