[
https://jira.duraspace.org/browse/DS-875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Donohue updated DS-875:
---------------------------
Status: Open (was: Received)
This issue was discussed in the DSpace Developers Meeting on April 20, 2011:
[20:31] <mdiggory> DS-875?
[20:31] <tdonohue> OK. back to DS-875, which stuartlewis wanted us to look at
briefly: https://jira.duraspace.org/browse/DS-875
[20:31] * kompewter (~kompew...@sul272peter.lib.ohio-state.edu) has joined
#duraspace
[20:31] <stuartlewis> I just wondered if we needed to do anything about it, as
it is listed as a Mjor bug against 1.7.1.
[20:32] <stuartlewis> As Mark says, all it does it prints out stack traces - it
still works.
[20:32] <stuartlewis> But at first glance you see stack traces and gulp.
[20:32] <mdiggory> so the analysis here is that your not supposed to place
files ass classpath entires
[20:32] <stuartlewis> And our monitoring scripts get upset.
[20:32] <mdiggory> unless they are jars
[20:32] <mdiggory> and the shell scripts do
[20:32] <stuartlewis> What 'files
[20:32] <richardrodgers> no resrouces in classpath?
[20:33] <stuartlewis> What 'files' are you referring to?
[20:33] <mdiggory> directories, yes, non-jar files... no
[20:33] * kompewter (~kompew...@sul272peter.lib.ohio-state.edu) Quit (Remote
host closed the connection)
[20:34] <mdiggory> directories of "non-jar files" yes
[20:34] <KevinVdV> Ps: just so everybody knows, the printing isn't a major
problem the issue is that this way it will never load in config files from jar
files when using the dspace script as oposed to the webapp where it will work
[20:35] <mdiggory> ok, so there is a deeper problem.
[20:36] <tdonohue> any volunteers to investigate this further? It sounds like
there is an issue here...
[20:36] <KevinVdV> Well I looked into it and the thing it is quite easy to fix
[20:37] <KevinVdV> Only put jars in the classpath and everything will work
properly
[20:37] <mdiggory> KevinVdV: do you know how the bin/dspace script gets into
the CLASSPATH above?
[20:37] <tdonohue> KevinVdV would you be willing to post a patch or the fix
then?
[20:37] <stuartlewis> Do we need to consider how this happened, and see if we
can learn from that. A brief look at the commit logs suggest it was introduced
from a change in dspace-services module, which presumably is in trunk
development whilst we were in branch. Do we need to consider branching modules
too?
[20:38] <KevinVdV> I am willing to post a patch
[20:38] <mdiggory> stuartlewis: we try to limit branching in favor of new
version releases
[20:38] <KevinVdV> The thing is at the moment the classpaths given are the
following:
[20:38] <KevinVdV> FULLPATH=$CLASSPATH:$JARS:$DSPACEDIR/config
[20:38] <KevinVdV> Leave out the $CLASSPATH (== {dspace.dir}/bin/dspace) and it
will work
[20:39] <KevinVdV> & t.b.h. I don't think that this dspace script belongs in
the classpath
[20:39] <stuartlewis> mdiggory: But would it be better to branch, so that we're
all on branches and fixing bugs, rather than mixing 1.7.1 branch and services
trunk with new features?
[20:40] <mdiggory> stuartlewis: I get what your saying... the strategy I
recommned then is that dspace trunk be on dspace-services-SNAPSHOT
[20:40] <stuartlewis> Or can we do as some have suggested and bring services
into main trunk, at least for a little while whilst we all get comfortable with
it?
[20:40] <tdonohue> stuartlewis & mdiggory -- I suggest leaving discussions
around 'branching' of dspace-services for larger discussion of *what belongs in
Trunk* / Asynch release processes (as whatever you decide now may or may not be
affected by that much larger discussion)
[20:40] <mdiggory> I hope that by the time we resolve the async / modularity
issues... there will be less need to adjust branches.
[20:41] <richardrodgers> but the issue is the branch (presumably stable), not
trunk, yes?
[20:41] <mdiggory> stuartlewis I am very very very against that
[20:42] <mdiggory> because the goal is currently the opposite, to work on
eliminating the need to merge all code into one svn project
[20:42] <mdiggory> poicies about upgrading versioins of modules in branches
would be more appropriate
[20:42] <tdonohue> Maybe we have a "special topics meeting" sometime in next 2
weeks on Asych Release Processes / What belongs in Trunk? This seems like
something we need to come to an agreement on soon.
[20:43] <mhwood> tdonohue++
[20:43] <stuartlewis> Yeah - either way, but I guess my main thought is that
does this issue need to make us consider how we manage the interplay of
releases a bit more, so that a 1.x.y release is really only bug fixes, and no
new untested features creep in from module trunks? But yes, can be discussed
another week.
[20:43] <mdiggory> so the enhancements that happened in the branch /
dspace-services were to provide backward compatable parity with the
ConfigurationManager.
[20:44] <mdiggory> which was basically a bugfix
[20:44] <tdonohue> I'd prefer scheduling that Special Topics Mtg for May 4.
Unfortunately, I may not be available for next weeks' mtg, and I really would
want to be a part of that Special Topic Mtg
[20:45] <richardrodgers> but even bug fixes can destabilize..
[20:45] <mdiggory> TBH we should be using something like classworlds in the CLI
[20:45] <tdonohue> So, if others are OK with May 4, then I'll schedule this
bigger discussion for then
[20:45] <stuartlewis> OK :)
[20:45] <mdiggory> richardrodgers: no-doubt it will occasionally happen
[20:45] <mdiggory> tdonohue: go for it
[20:46] <tdonohue> OK. May 4 = Special Topics Meeting on Async Releases + What
belongs in Trunk
[20:46] <tdonohue> Anything else to say about DS-875?
[20:46] <mhwood> Patch would be appreciated.
[20:47] <mdiggory> So, for clarification
[20:47] <richardrodgers> I guess we probably think it does *not* warrant a
1.7.2, right?
[20:47] <KevinVdV> Just give a me a second & I will have a patch :)
[20:47] <mhwood> It sounds like the only problem is ugly stuff in the logs.
[20:47] <mdiggory> DS-875 does not cause a problem unless you are loading
dspace modules cfg's out of the addon jars
[20:47] <stuartlewis> Nope - ugly stuff whenever you run [dspace]/bin/dspace
foobar
[20:47] <tdonohue> it seems like it'd be fine to schedule for 1.8.0?
[20:48] <tdonohue> oh really?
[20:48] <tdonohue> (stuartlewis, are you saying we need a 1.7.2 then?)
[20:48] <mdiggory> tdonohue: I think that is fine, I would attach it to 1.7.x
though I doubt we will be doing a 17.2 release
[20:48] * kshepherd predicts many dspace-tech emails
[20:48] <mdiggory> it would be good to get in there if there was a chance that
it did happen
[20:48] <stuartlewis> Dunno - that was why I raised it. I wonder if we do?
However, not seen many reports about it yet on dspace-tech, so maybe wait and
see for a while?
[20:49] <mdiggory> the correction is to remove "$CLASSPATH:" from the
bin/dspace script
[20:50] <tdonohue> OK, I suggest we tentatively schedule for 1.8.0 then. Push
forward to a 1.7.2 only if we end up with a stream of complaints, etc.
[20:50] <KevinVdV> Attached a patch to the JIRA
[20:50] <mhwood> KevinVdV: thanks!
[20:51] <KevinVdV> Well about the complaints is just a display bug, it has no
effect on the execution
[20:51] <mhwood> Yes, I don't think this alone warrants a point release. It's
easy enough to just edit the wrapper if you have problems.
[20:51] <PeterDietz> patch is fine for now, you're always free to patch (or
cherry-pick) your system. A release should have something more I think
[20:51] <tdonohue> DS-875 summary: KevinVdV posted a patch. Needs broader
review. Schedule to fix tentatively for 1.8.0, but may require a 1.7.2 if we
find many are significantly inconvenienced
[20:51] <mdiggory> More robust classloading would utilize the following
[20:51] <mdiggory> http://classworlds.codehaus.org/launchusage.html
[20:52] <stuartlewis> Yes for scripts that provide output, but for some (e.g.
itemcounter) with no output, all we saw was a stacktrace, and assumed that it
hadn't worked.
[20:52] <mdiggory> do we have anything else warranting a 1.7.2 release yet?
[20:53] <tdonohue> not as far as I know...this is the first thing that has come
up
[20:53] <stuartlewis> KevinVdV: Thanks for the patch. Do we also need to patch
dspace.bat in the same way?
[20:53] <PeterDietz> caching is annoying in 1.7.x (I've changed us to
noncaching)
[20:54] <KevinVdV> T.b.h. haven't tested dspace.bat
[20:54] <KevinVdV> Can do that tomorrow don't have a windows pc operational 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
> 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
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
