[Dspace-tech] modifying config dspace.cfg

1,234 views
Skip to first unread message

Glenn Little

unread,
Aug 25, 2015, 4:33:01 PM8/25/15
to dspac...@lists.sourceforge.net
I've got an install of dspace and am now trying to modify the
dspace.cfg file. But I'm confused as to which file to edit. I
thought I was supposed to do this:

+ edit [dspace-source]/dspace/config/dspace.cfg

+ change dir to [dspace-source]/dspace/target/dspace-1.7.0-build.dir

+ ant update_configs

The problem is that this does not do anything with my new changes.
Instead it puts an old copy of my dspace.cfg file over into
[dspace]/config/dspace.cfg.new. As far as I can tell, that *old* copy
comes from:

[dspace-source]/dspace/target/dspace-1.7.0-build.dir/config/dspace.cfg

So what is the real intent of the copy in dspace-<version>-build.dir
compared to the one higher up in the source tree? How is one *really*
supposed to update the configuration, post-install?

Thanks...

-glenn

amutsikiwa

unread,
Aug 25, 2015, 4:33:07 PM8/25/15
to Glenn Little, dspac...@lists.sourceforge.net
After making changes to [dspace-source]/dspace/config/dspace.cfg, change
directory to [dspace-source]/dspace/ and then run
mvn -e -o packages
Then change directory to
[dspace-source]/dspace/target/dspace-1.7.0-build.dir
And run
ant -Doverwrite=true update clean_backups


The changes should be effected.


Regards,

Admire Mutsikiwa
University of Zimbabwe
----------------------------------------------------------------------------
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
DSpace-tech mailing list
DSpac...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




Thornton, Susan M. (LARC-B702)[LITES]

unread,
Aug 25, 2015, 4:33:17 PM8/25/15
to amutsikiwa, Glenn Little, dspac...@lists.sourceforge.net
Here is the process I follow and never have any problems.

During the initial install/implementation of your DSpace instance, you will make your changes to dspace.cfg in {dspace-source}/dspace/config. Then once you do a "fresh-install", your /dspace directory is populated with all other sub-directories like /bin /config /etc /lib /webapps, etc.

From this point on, the place to make your changes to dspace.cfg is in your dspace installation directory, NOT the source directory. If you do not make your changes in /dspace/config/dspace.cfg, your changes will not be picked up. Also remember that you have to stop and start your web server before these changes will be picked up too.

Hope this helps,
Sue



Sue Walker-Thornton
Software Developer/Database Administrator
NASA Langley Research Center|LITES Contract
(757) 224-4074
------------------------------------------------------------------------------

Glenn Little

unread,
Aug 25, 2015, 4:33:21 PM8/25/15
to Thornton, Susan M. (LARC-B702)[LITES], dspac...@lists.sourceforge.net
Okay, I'm really confused now. These two replies are *both* different
from the (itself confusing) description at:

https://wiki.duraspace.org/display/DSDOC/Configuration#Configuration-UpdateReminder

The above page does not mention running mvn at all. Where does that
come from? The above page also explicitly recommends not just editing
the runtime config file.

What's confusing about that page itself is that it first says,
essentially, to edit [dspace-source]/dspace/config/dspace.cfg, then cd
to the target/dspace-<version>-build.dir and run "ant update_configs.

But then it goes on with to suggest running either (or both?) of "ant
-Dconfig=[dspace]/config/dspace.cfg", and "ant init_configs". I'm
having trouble really understand the conditions under which you would
run one or the other of those, and how those tie in with the initial
"ant update_configs". Let alone how those all tie in with the two
suggestions given previously in this thread.

Can anyone help unconfuse me?

Thanks!

-glenn

Brian Freels-Stendel

unread,
Aug 25, 2015, 4:33:23 PM8/25/15
to Glenn Little, dspac...@lists.sourceforge.net
Morning,

I'll give it a try, since I had the same conceptual problems with the process.

Editing the [dspace-source]/dspace/config/dspace.cfg file has the benefit of keeping everything in sync: you'll never make the mistake of moving the source to a new machine and leaving behind customizations that you've made to the other copies.

Assuming you only edit [dspace-source]/dspace/config/dspace.cfg, then you have to run 'mvn package' to get the updated dspace.cfg into the .../target/build-dir/... tree, which is the place ant works.

running 'ant update_configs' puts copies of any updated config files into the [dspace] (live) directory; but if you want to be able to use them with a simple Tomcat reboot, you need to tell ant to make the new copies the ones Tomcat will use. You do that with the -Doverwrite=true option, so: 'ant -Doverwrite=true update_configs'. (At the same time, ant will copy the old config files with a '.[date]' extension (in the [dspace]/config directory.) Otherwise, ant writes those new config files to the [dspace]/config directory with (I believe) a '.new' extension and you have to manually remove that extension (and rename the old config files -- the ones you want retired) to something else, or delete them.

'ant -Dconfig=[dspace]/config/dspace.cfg' => You'd need to have an actual command, such as update_configs or update_code for it to do anything. It would be of use if you were editing other code (perhaps a .java file) in the source, but do not use the source dspace.cfg file. In this case, you'd still need to use maven to get the altered code into the ...target... directory so that ant can put it where it belongs.

I hope this helps, and that I haven't misrepresented anything....

B--

>>> On 2/9/2011 at 11:46 AM, in message
<AANLkTinNwCUDPXj-ai0fu...@mail.gmail.com>, Glenn Little

Glenn Little

unread,
Aug 25, 2015, 4:33:24 PM8/25/15
to Brian Freels-Stendel, dspac...@lists.sourceforge.net
Wow.. okay... complex but makes sense given the whole
dspace/java/tomcat context I guess. The thing that seems weird to me
now is the "mvn package" command, which takes a while to run and seems
to rebuild all the apps. Is that really necessary, just to make a
quick change in a config file? (I'm trying to stay with the program
and not just edit the runtime file by hand). Does it actually do
something different in the build based on the new config values, and
should I actually reinstall all the applications ("ant fresh_install")
not just the config files? I think I need a new supply of advil...
:-)

-glenn

Brian Freels-Stendel

unread,
Aug 25, 2015, 4:33:25 PM8/25/15
to Glenn Little, dspac...@lists.sourceforge.net
I'll see your advil and raise you a demerol. But it does get easier once you've identified a workflow you're comfortable with...and forget about everything else.

I believe that nothing in the config files make a difference to the rest of the code; hence, the live versions are able to be altered. (This may be true only for dspace.cfg, I'm not positive about the other configs.)

The maven thing is cumbersome if you're only altering something like the config, yes. Myself, I've written some ant targets that go up the tree and grab some files, copy them to the appropriate target directory, and then into the appropriate live directory. Among those files are dspace.cfg, and the entire [dspace-source]/dspace/modules/xmlui directory. (I found it extremely onerous to wait for a build simply to put those few files up to see if a slight CSS alteration was just enough or just too much, and our server is now built so that I can't write files into the live directory...but ant can.)

ant fresh_install should only be used if you've emptied out the database. It'll crap out otherwise (thankfully.) You could use update_code, but that would be overkill if you only changed a config file. update_configs should be fine for that sort of thing.

B--

>>> On 2/9/2011 at 1:13 PM, in message
<AANLkTinQXRz9WQDeD8C+U...@mail.gmail.com>, Glenn Little

helix84

unread,
Aug 25, 2015, 4:33:31 PM8/25/15
to Glenn Little, dspac...@lists.sourceforge.net, Brian Freels-Stendel
On Wed, Feb 9, 2011 at 21:13, Glenn Little <lit...@cs.ucsd.edu> wrote:
> Wow.. okay... complex but makes sense given the whole
> dspace/java/tomcat context I guess.  The thing that seems weird to me
> now is the "mvn package" command, which takes a while to run and seems
> to rebuild all the apps.  Is that really necessary, just to make a
> quick change in a config file?  (I'm trying to stay with the program
> and not just edit the runtime file by hand).  Does it actually do
> something different in the build based on the new config values, and
> should I actually reinstall all the applications ("ant fresh_install")
> not just the config files?   I think I need a new supply of advil...
> :-)

I understand your concern completely. I'm using a different workflow
to avoid that useless rebuild. I still make changes to the source
files - the reason is, if I instead made a change to live config and
forget to make the change in source, next time I run ant I would lose
that change.

1. vim [dspace-source]/dspace/config/dspace.cfg
2. cp [dspace-source]/dspace/config/dspace.cfg [dspace]/config/dspace.cfg
3. /etc/init.d/tomcat restart

Thus - no need to rebuild and no fear of losing changes. One thing to
be aware of is to back up your old config. Ant does that for you but
here I skip that step. I do the same with theme files (it will work if
you want to change any but the .java files, then you should use
mvn/ant).

Just my 2 cents, choose a workflow that works best for you.

Regards,
~~helix84

Thornton, Susan M. (LARC-B702)[LITES]

unread,
Aug 25, 2015, 4:33:44 PM8/25/15
to Glenn Little, dspac...@lists.sourceforge.net

I'm attaching a little script, entitled "c", I wrote that does both the Maven assemble and the ant compile.  I execute this every time I make a change to a "source" object - that is, any object that resides under the {dspace-source} directory.  This includes .jsp  .java  messages.properties, etc - any object that lives in the {dspace-source} directory.  I also have another script, entitled "cc" that does the exact same thing as this one, except that it does a "mvn clean package" instead of "mvn package".  The purpose of these scripts is just to save me some typing, i.e., I only have to type "c" instead of the mvn and ant commands, and it does the directory changing so I can just execute this script from under {dspace-source}.

 

Every time I execute this script, I then have to restart my web server (we use Sun Webserver7) in order to have my changes picked up by the web application.

 

Note:  Any time I change dspace.cfg (or any other object in my /dspace installation directory), I do NOT have to execute this little script - I only have to restart my web server for my changes to be picked up.

Thornton, Susan M. (LARC-B702)[LITES]

unread,
Aug 25, 2015, 4:33:45 PM8/25/15
to Glenn Little, Brian Freels-Stendel, dspac...@lists.sourceforge.net

-----Original Message-----
From: Glenn Little [mailto:lit...@cs.ucsd.edu]
Sent: Wednesday, February 09, 2011 3:13 PM
To: Brian Freels-Stendel
Cc: dspac...@lists.sourceforge.net
Subject: Re: [Dspace-tech] modifying config dspace.cfg

 

Wow.. okay... complex but makes sense given the whole

dspace/java/tomcat context I guess.  The thing that seems weird to me

now is the "mvn package" command, which takes a while to run and seems

to rebuild all the apps.  Is that really necessary, just to make a

quick change in a config file? 

 

Glenn - this is why, if I’m just making a change to the dspace.cfg file, I edit the one under /dspace/config (my installation directory) because I then don’t have to rebuild the app (with mvn package) - I only have to restart my web server.  In fact, once I do the “ant fresh_install” during the initial dspace implementation, I *never* touch {dspace-source}/dspace/config/dspace.cfg again.  I will occasionally refer back to it if I need to look at how I initially set a property or something.

Sue

Glenn Little

unread,
Aug 25, 2015, 4:33:53 PM8/25/15
to Thornton, Susan M. (LARC-B702)[LITES], dspac...@lists.sourceforge.net, Brian Freels-Stendel
Okay, one of the things I was concerned about was if the ant of maven
processes were doing something else important with the info in
dspace.cfg, like processing some other file somewhere with that info.
It sounds like the consensus on that one is that it is not happening.

Regarding whether or not to keep dspace.cfg in the source and install
dirs in sync with each other or not appears to just be a matter of
taste at this point.

-glenn

On Thu, Feb 10, 2011 at 11:44 AM, Thornton, Susan M.

admin

unread,
Nov 16, 2016, 1:20:53 PM11/16/16
to DSpace Technical Support, amuts...@uzlib.uz.ac.zw, lit...@cs.ucsd.edu, dspac...@lists.sourceforge.net, susan.m....@nasa.gov
Hello,

I'm fresh DSpace user. I installed the software and wanted to change its configuration. I followed this post and ammended the file dspace.cfg in dspace/config directory, restarted tomcat, and no effect. Am I missing something? 



Thanks,

Peter

Monika Mevenkamp

unread,
Nov 16, 2016, 2:27:50 PM11/16/16
to admin, DSpace Technical Support, amuts...@uzlib.uz.ac.zw, lit...@cs.ucsd.edu, Dspace Tech, susan.m....@nasa.gov
That should work 
Be careful with your editing though 
Trailing blanks at the end of lines sometimes mess things up; 
a missing backslash at the end also causes trouble on multi value  configs
Watch your spelling of cause 

Monika

--
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To post to this group, send email to dspac...@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages