[
https://jira.duraspace.org/browse/DS-875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Van de Velde updated DS-875:
----------------------------------
Attachment: dspace_temp_classpath_fix.patch
Configuration_service_log_fix.patch
I have created temporary bugfix for this issue (to be committed in DSpace 1.72).
The configuration service patch should be applied on the services and a new
version of these should be released for DSpace 1.7.2 with a new minor version
number (the bugfix itself is just replacing the e.printstacktrace with
log.error).
The temp classpath fix patch will only pass a classpath along to the
scriptlauncher if one is explicitly set. For DSpace 1.8.0 a different solution
will be developed so that the crash cannot occur (as suggested by Mark Diggory).
I also opted not to show an error if a classpath is set, since the
configurationservice isn't used in DSpace 1.7.2 so it matters little if it
actually does crash.
>From the Developers meeting about this topic (2011/05/18)
[20:32] <kompewter> [ https://jira.duraspace.org/browse/DS-875 ] - [#DS-875]
DSpace Configuration service error when using "dspace" script. -
DuraSpace JIRA
[20:33] <KevinVdV> T.b.h. the thing is I don't know what the "best" way to fix
it is...
[20:33] <tdonohue> yea, thanks KevinVdV. I was also curious to see others
opinions on this. Do we remove 'CLASSPATH' altogether (like current patch does)
or see if we can find another way around it.
[20:34] <tdonohue> any other ideas on Ds-875 from anyone?
[20:35] <mdiggory> I was trying to comment... basically, I think if your going
to pass in a CLASSPATH... the problems that it causes are upto you to manage
[20:35] <PeterDietz> could we remove the e.printStacktrace ?
[20:35] <mdiggory> I think we should protect the command with at least a warning
[20:35] <KevinVdV> We could but that will not fix the issue
[20:36] <mdiggory> and use if conditionals to configure the commandline to have
CLASPATH only if it is set
[20:36] <mdiggory> conditional example provided needs work... theres a better
way in bash
[20:36] * hpottinger has to run, sorry folks
[20:37] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) Quit
(Quit: Page closed)
[20:37] <tdonohue> mdiggory -- so, something similar to what stuartlewis
suggested then?
[20:37] <KevinVdV> But I think it should also be clear IF it crashes the user
should be aware of this
[20:37] <mhwood> But we may not have bash.
[20:37] <KevinVdV> Perhaps a cleaner error could be thrown...
[20:38] <mdiggory> But more explict, check for CLASSSPATH present in
environment, set it only if it is present, right now what it dumps onto the
executable is not correct with CLASSPATH is not set
[20:38] <mdiggory> its a bash script
[20:38] <tdonohue> KevinVdV - yea, I can see a cleaner error perhaps. But, I do
like the idea of keeping the CLASSPATH in there, if it is set.
[20:39] <mhwood> mwood@mhw
~/servers/johncock/build/dspace/dspace-1.7.0/dspace/bin $ head dspace
[20:39] <mhwood> #!/bin/sh
[20:39] <KevinVdV> I agree with you on the fact that the CLASSPATH should stay
in (if explicitly set)
[20:40] <mhwood> Agreed, do not want to lose CLASSPATH if we can deal with odd
values.
[20:40] <tdonohue> Ok. it sounds like we have several of us in agreement that
"preserving the inclusion of CLASSPATH" is a good thing. So, sounds like we
need a few of us to revisit Ds-875 then, and see if we can throw better errors
if they should occur.
[20:41] <mdiggory> A warning clarifying that if your CLASSPATH is "dirty" you
may break DSpace would be good to toss in there
[20:41] <mdiggory> and like KevinVdV suggested, maybe a light/quick review of
that path might help...
[20:41] <tdonohue> yea, a cleaner warning or error would be best -- either one
[20:42] <mdiggory> likewise, I would still research use of classworlds in this
case as a possible means to let a third party open source tool dedictated to
managing classpaths on commandline execution of java deal with such problems
instead of us
[20:43] <mdiggory> because then one solution would apply to both *nix and
Windblows
[20:43] <KevinVdV> Using a third party tool might also work if it does a
propper job
[20:43] <tdonohue> Ok. any volunteers to continue work on this? Obviously need
to prioritize Ds-875 if we want to "make the deadline" for 1.7.2
[20:43] <KevinVdV> Well I can create a patch for a clean error pretty swiftly
[20:44] <mdiggory> I think thats best for 1.7.2
[20:44] <tdonohue> KevinVdV -- that'd be great. If we can combine that with an
updated patch that preserves the CLASSPATH, that seems like a good solution for
1.7.2
[20:44] <mdiggory> save the classworlds overhaul for 1.8
[20:44] <tdonohue> +1 mdiggory
[20:44] <KevinVdV> I will indeed save the classworlds until 1.8
[20:45] <KevinVdV> I can also attempt to look into the "optional" CLASSPATH
> 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: Configuration_service_log_fix.patch,
> dspace_script_bugfix.patch, dspace_temp_classpath_fix.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
