On Thu, Jan 22, 2009 at 9:35 PM, Scott Phillips
scott.a.phill...@gmail.comwrote:
You may want to look at a Journal collection we've done.
It doesn't completely address the problem you're asking about but is in the
same sphere, and i second what Mark said, it is likely best to not use
It seems that wildcard policy tool cannot give DEFAULT_ITEM_READ or
DEFAULT_BITSTREAM_READ rights to collections?
Nothing happens if I try give them using the tool.
Mika
--
This SF.net email is sponsored by:
SourcForge
It seems that wildcard policy tool cannot give DEFAULT_ITEM_READ or
DEFAULT_BITSTREAM_READ rights to collections?
Nothing happens if I try give them using the tool.
Mika
--
This SF.net email is sponsored by:
SourcForge
Lucene is the DSpace search engine. Currently, DSpace only used
tokenized indexes (field content is splitted in tokens: the words).
Lucene is able to very efficiently sort its result (by default it sorts
by disminishing relevance) but only for the untokenized fields (fields
indexed as is
Hi John,
during upgrade, did you run database_schema_14-15.sql as indicated in the
docs. This will create the language column in eperson, see
alter table eperson add column language VARCHAR(64);
update eperson set language = 'en';
Hope that helps
Claudia Jürgen
Hello,
We're in the process
Thank you! Not sure how we missed this, it was very clear in the docs.
-
John Furfey
Digital Systems and Services Coordinator
MBLWHOI Library
Woods Hole, MA 02543 USA
PHONE: 508-289-7435
EMAIL: jfur...@mbl.edu
On Fri, Jan 23, 2009 at 1:34 PM, John Furfey jfur...@mbl.edu wrote:
I erred in applying the above patch to a 1.4 system, and the results are
that now there are duplicate metadata fields for each item view. Example:
Is there an easy way to rollback a patch, or is it better to restore the db
I tend to agree with Dorothea on this one. I suspect it will be
difficult to roll back all the changes unless someone out there knows
how to magically unto completed transactions. If you can restore from
backup that would possibly be the safest decision. Otherwise,
reviewing the file, I see the
Does anyone happen to know in what order the Items (by Handle) are being
indexed in DSIndexer.java? In trying to figure out why index-all is
running so long, I put a System.out.println of each handle being
processed in DSIndexer.java so I can see if and where it's having a
problem. The handles
Unfortunately non of these suggestions seems to be the problem. Any
other suggestions?
thanks.
Diggory Mark wrote:
Yes, filesystem permissions in the assetstore would cause both to
fail. But also look at your filesystem quota as well to make sure
there is disk space.
On Jan 22, 2009, at
Can you go into you assetstore directory and create files via the
commandline as your tomcat user? Likewise verify that you are testing
with your webapplication servers permissions more specifically, if
your application server can't create files in the directory, you will
get this sort of
It uses the row ordering of the actual items in the item database
table, Items are retrieved using:
Item.findAll(context);
-Mark
On Jan 23, 2009, at 12:53 PM, Thornton, Susan M. (LARC-B702)[NCI
INFORMATION SYSTEMS] wrote:
Does anyone happen to know in what order the Items (by Handle)
On Jan 23, 2009, at 2:31 PM, Brian Freels-Stendel wrote:
FWIW, we see the same upload and license errors on a regular, but not
quite common, basis. Particular accounts seem to be affected
intermittently. If the submitter tries again, though, the second
attempt is nearly always successful.
This strikes me as odd... I might review your log4j.properties or
log4j.xml to verify its set properly
On Jan 23, 2009, at 1:43 PM, Thornton, Susan M. (LARC-B702)[NCI
INFORMATION SYSTEMS] wrote:
java.io.FileNotFoundException: /dspace.log (Permission denied)
~
Mark R. Diggory
You may have run out of inodes before disk blocks, try
df -i
--
Van Ly : University of Sydney Library
-Original Message-
From: Sandy De Groote [mailto:sgro...@uic.edu]
Sent: Sat 24/01/2009 8:00 AM
To: Diggory Mark
Cc: dspace-tech@lists.sourceforge.net; Claudia Jürgen
Subject: Re:
Yes, good catch. We've encountered that in the past as well.
On Jan 23, 2009, at 2:52 PM, Van Ly wrote:
You may have run out of inodes before disk blocks, try
df -i
--
Van Ly : University of Sydney Library
-Original Message-
From: Sandy De Groote [mailto:sgro...@uic.edu]
Sent:
Strange. After I hard-coded my log.dir in my log4j.properties and
log4j.xml files (in /dspace/config/dspace.cfg), the error disappeared,
however I am still getting these last 2 errors when I shut down my
virtual server:
From: Diggory Mark
17 matches
Mail list logo
