[Dspace-tech] Trouble upgrading Solr stats from 1.6.2 to 1.7.1
Trying to sort out a SOLR stats issue that remains after our otherwise successful upgrade from 1.6.2 to 1.7.1 When running 1.6.2, the Solr stats service worked perfectly. Once we upgraded, I see this if I go to http://localhost:8080/solr/admin: org.apache.jasper.JasperException: Unable to compile class for JSP: An error occurred at line: 32 in the jsp file: /admin/index.jsp The method getRequestHandlers() in the type SolrCore is not applicable for the arguments (Class) 29:<%-- jsp:include page="header.jsp"/ --%> 30:<%-- do a verbatim include so we can use the local vars --%> 31:<%@include file="header.jsp" %> 32:<%boolean replicationhandler = !core.getRequestHandlers(ReplicationHandler.class).isEmpty();%> 33: 34: 35: Stacktrace: org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:92) org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:330) org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:423) org.apache.jasper.compiler.Compiler.compile(Compiler.java:317) org.apache.jasper.compiler.Compiler.compile(Compiler.java:295) org.apache.jasper.compiler.Compiler.compile(Compiler.java:282) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:586) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:317) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:295) org.dspace.solr.filters.LocalHostRestrictionFilter.doFilter(LocalHostRestrictionFilter.java:60) Does this ring a bell with anyone? The only change we made to solr configuration was adding this line to dspace.cfg: solr.resolver.timeout = 200 I see 1.7.1 added other files that appear to be related to stats (e.g., /dspace/config/dspace-solr-search.cfg) but I haven't touched those... Platform: Mac OSX Server 10.6.8 java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode) - Wally Wally Grotophorst Associate University Librarian Digital Programs and Systems University Libraries George Mason University Fairfax, Virginia 22030 (703) 993-9005 -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] Why is context null?
Hi
I am evaluating dspace-1.5.2 by creating it as an Eclipse project and
deploying it into Tomcat.
The problem I face is this:
in index.jsp;
context = UIUtil.obtainContext(request);
and then in UIUtil:
Context c = (Context) request.getAttribute("dspace.context");
context returns null.
If I deploy dspace according to standard installation instructions, it works
and there is a valid context object
But if I deploy from eclipse context is null
and when I try to run the application I get a page that returns a page that
says:
Internal System Error
The system has experienced an internal error. Please try to do what you were
doing again, and if the problem persists, please contact us so we can fix
the problem.
The error stack trace is as below:
java.lang.NoClassDefFoundError: Could not initialize class
org.imedia.authenticate.AuthenticationManager
org.dspace.app.webui.util.UIUtil.obtainContext(UIUtil.java:143)
org.dspace.app.webui.filter.RegisteredOnlyFilter.doFilter(RegisteredOnlyFilter.java:49)
Any ideas, suggestions?
thanks in advance
ilango
On Wed, Jul 27, 2011 at 4:57 PM,
wrote:
> Send DSpace-tech mailing list submissions to
>dspace-tech@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>https://lists.sourceforge.net/lists/listinfo/dspace-tech
> or, via email, send a message with subject or body 'help' to
>dspace-tech-requ...@lists.sourceforge.net
>
> You can reach the person managing the list at
>dspace-tech-ow...@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of DSpace-tech digest..."
>
>
> Today's Topics:
>
> 1. Re: Creative Common License Does not Show Properlyin
> xmlui
> (Amir Pourabdollah)
> 2. Batch metadata corrections question: does anyone know why the
> limit is set to just 20 items at a time? (Berry, Irene (CIV))
> 3. Re: batch import of Bagit-formated collections and/or
> conversion script for Bagit to SAF (Pottinger, Hardy J.)
> 4. Re: batch import of Bagit-formated collections and/or
> conversion script for Bagit to SAF (Stuart Lewis)
>
>
> --
>
> Message: 1
> Date: Wed, 27 Jul 2011 21:49:50 +0100
> From: Amir Pourabdollah
> Subject: Re: [Dspace-tech] Creative Common License Does not Show
>Properlyin xmlui
> To: "dspace-tech@lists.sourceforge.net"
>
> Message-ID:
><
> 4b6965e54e385e419329b3aa1e1a46f02c3389d...@exchange3.ad.nottingham.ac.uk>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Thanks Wendy for your reply.
>
> I noticed that there is a bitstream format of "CC License" already defined
> and associated to "License_text". Does this mean that the patch is already
> applied?
>
> I have manually changed the MIME type of CCLicense to "text/html;
> charset=utf-8" so the page is now rendered as HTML but it is still not what
> it should be, particularly some links (like the legal codes) are not
> working.
>
> I think the problem is beyond formatting and rendering issues. Do you think
> if I apply the patch, the links will also work?
>
> Yours,
> Amir.
>
>
> From: Wendy J Bossons [wboss...@mit.edu]
> Sent: 27 July 2011 19:54
> To: Amir Pourabdollah
> Cc: dspace-tech@lists.sourceforge.net
> Subject: Re: [Dspace-tech] Creative Common License Does not Show Properly
> inxmlui
>
> Hello Amir
>
> The format associated with the license text is not correct, which is why it
> does not display. There is a patch to address that particular issue for 1.6.
> See this patch https://jira.duraspace.org/browse/DS-295.
>
> I just completed some work on CCLicense that I hope will be in the upcoming
> 1.8 release. As part of that, the XMLUI will contain a link to the actual
> license, rather than storing the license text and trying to display it
> internally as you point out. I will leave it to the DSpace
> committers/Release Coordinator to comment on the schedule of the latter.
>
> Thanks!
>
> ..\Wendy
>
> " I am putting myself to the fullest possible use, which is all I think
> that any conscious entity can ever hope to do."
>
> Wendy Bossons
> Senior Software Engineer
> MIT Libraries
> Software Analysis and Development
> 77 Massachusetts Avenue
> Cambridge, MA 02139-4307
> 617-253-0770
> wboss...@mit.edu
>
> On Jul 27, 2011, at 1:42 PM, Amir Pourabdollah wrote:
>
> Dear friends,
>
> If a Creatice Common license is attached to an item (in xmlui), the page
> showing the license does not show properly (looks like an unformatted HTML
> with no image) and some of the links inside the page (including the Legal
> Code which is important) do not work and show this error:
>
> org.apache.cocoon.ResourceNotFoundException: Unable to locate bitstream
> -
> context:/jndi:/localhost/xmlui/sitemap.xmap - 268:70
>
> I know that there has been a
Re: [Dspace-tech] batch import of Bagit-formated collections and/or conversion script for Bagit to SAF
Hi, a little nervous about it, but I'm game to try a swing at this, and would appreciate any pointers, jeers, or tomatoes (or, heck, SWORDBagitIngesters, if you have one handy) thrown this way. :-) -- HARDY POTTINGER University of Missouri Library Systems http://lso.umsystem.edu/~pottingerhj/ "No matter how far down the wrong road you've gone, turn back." --Turkish proverb On 7/28/11 11:21 AM, "Tim Donohue" wrote: >Though, to be clear -- the replicate code is *not* hooked up to DSpace's >SWORD ingestion process yet. > >So, if we wanted to ingest bags via SWORD (which sounds like a good idea >to me), I believe there's still one piece missing: > >* a SWORDIngester class which calls the replicate code to ingest a bag >received via SWORD into DSpace. (This would be similar to how there's a >SWORDMETSIngester which forwards METS packages on to the DSpace METS >PackageIngester) > >- Tim > >On 7/27/2011 5:05 PM, Richard Rodgers wrote: >> BTW, the replicate code does all this - serializes and deserializes >>bags to DSpace objects >> >> Richard >> On Jul 27, 2011, at 5:56 PM, Stuart Lewis wrote: >> >>> Hi Hardy, >>> >>> SWORD is completely agnostic about what packages it transports, >>>however out the box, DSpace does not know how to ingest bags via SWORD. >>> You might therefore need to write a bag ingester than knows how to >>>unpack and ingest the contents of the bag. This would make an >>>excellent addition to DSpace :) >>> >>> Thanks, >>> >>> >>> Stuart Lewis >>> Digital Development Manager >>> Te Tumu Herenga The University of Auckland Library >>> Auckland Mail Centre, Private Bag 92019, Auckland 1142, New Zealand >>> Ph: +64 (0)9 373 7599 x81928 >>> >>> >>> >>> On 28/07/2011, at 9:29 AM, Pottinger, Hardy J. wrote: >>> Thanks, Mark, that code from MIT looks interesting, I will look into it more. I did notice that the Bagit spec is supported by the SWORD protocol, and when I mentioned this to our archivist, he went and looked and it does appear that the BIL 3.9 can send a "bag" using SWORD (see output of the BIL -h command, pasted below). So, it looks like Bagger and/or BIL + turning on SWORD for our repository will get us what we want. Huzzah! * BagIt Library (BIL) Version 3.9 Usage: bag [operation arguments] [--help] Parameters: Valid operations are: baginplace, bob, checkpayloadoxum, create, fillholey, generatepayloadoxum, makecomplete, makeholey, retrieve, splitbagbyfiletype, splitbagbysize, splitbagbysizeandfiletype, sword, update, updatetagmanifests, verifycomplete, verifypayloadmanifests, verifytagmanifests and verifyvalid. Operation explanations: baginplace: Creates a bag-in-place. The source must be a directory on a filesystem and may already have a data directory. bob: Sends a bag using BOB. checkpayloadoxum: Generates Payload-Oxum and checks against Payload-Oxum in bag-info.txt. create: Creates a bag from supplied files/directories, completes the bag, and then writes in a specified format. fillholey: Retrieves any missing pieces of a local bag. generatepayloadoxum: Generates and returns the Payload-Oxum for the bag. makecomplete: Completes a bag and then writes in a specified format. Completing a bag fills in any missing parts. makeholey: Generates a fetch.txt and then writes bag in a specified format. retrieve: Retrieves a bag exposed by a web server. A local holey bag is not required. splitbagbyfiletype: Splits a bag by file types. splitbagbysize: Splits a bag by size. splitbagbysizeandfiletype: Splits a bag by size and file types. sword: Sends a bag using SWORD. update: Updates the manifests and (if it exists) the bag-info.txt for a bag. updatetagmanifests: Updates the tag manifests for a bag. The bag must be unserialized. verifycomplete: Verifies the completeness of a bag. verifypayloadmanifests: Verifies the checksums in all payload manifests. verifytagmanifests: Verifies the checksums in all tag manifests. verifyvalid: Verifies the validity of a bag. [--version] Prints version of BIL and exits. [--help] Prints usage message for the operation. Examples: bag verifyvalid --help Prints help for the verifyvalid operation. -- >>
Re: [Dspace-tech] batch import of Bagit-formated collections and/or conversion script for Bagit to SAF
Though, to be clear -- the replicate code is *not* hooked up to DSpace's SWORD ingestion process yet. So, if we wanted to ingest bags via SWORD (which sounds like a good idea to me), I believe there's still one piece missing: * a SWORDIngester class which calls the replicate code to ingest a bag received via SWORD into DSpace. (This would be similar to how there's a SWORDMETSIngester which forwards METS packages on to the DSpace METS PackageIngester) - Tim On 7/27/2011 5:05 PM, Richard Rodgers wrote: > BTW, the replicate code does all this - serializes and deserializes bags to > DSpace objects > > Richard > On Jul 27, 2011, at 5:56 PM, Stuart Lewis wrote: > >> Hi Hardy, >> >> SWORD is completely agnostic about what packages it transports, however out >> the box, DSpace does not know how to ingest bags via SWORD. You might >> therefore need to write a bag ingester than knows how to unpack and ingest >> the contents of the bag. This would make an excellent addition to DSpace :) >> >> Thanks, >> >> >> Stuart Lewis >> Digital Development Manager >> Te Tumu Herenga The University of Auckland Library >> Auckland Mail Centre, Private Bag 92019, Auckland 1142, New Zealand >> Ph: +64 (0)9 373 7599 x81928 >> >> >> >> On 28/07/2011, at 9:29 AM, Pottinger, Hardy J. wrote: >> >>> Thanks, Mark, that code from MIT looks interesting, I will look into it >>> more. I did notice that the Bagit spec is supported by the SWORD protocol, >>> and when I mentioned this to our archivist, he went and looked and it does >>> appear that the BIL 3.9 can send a "bag" using SWORD (see output of the >>> BIL -h command, pasted below). So, it looks like Bagger and/or BIL + >>> turning on SWORD for our repository will get us what we want. Huzzah! >>> >>> * >>> BagIt Library (BIL) Version 3.9 >>> Usage: bag [operation arguments] [--help] >>> Parameters: >>> >>> Valid operations are: baginplace, bob, checkpayloadoxum, >>> create, >>> fillholey, generatepayloadoxum, makecomplete, makeholey, retrieve, >>> splitbagbyfiletype, splitbagbysize, splitbagbysizeandfiletype, sword, >>> update, updatetagmanifests, verifycomplete, verifypayloadmanifests, >>> verifytagmanifests and verifyvalid. >>> Operation explanations: >>> baginplace: Creates a bag-in-place. The source must >>> be a directory on >>> a filesystem and may already have a data directory. >>> bob: Sends a bag using BOB. >>> checkpayloadoxum: Generates Payload-Oxum and checks >>> against >>> Payload-Oxum in bag-info.txt. >>> create: Creates a bag from supplied >>> files/directories, completes the >>> bag, and then writes in a specified format. >>> fillholey: Retrieves any missing pieces of a local >>> bag. >>> generatepayloadoxum: Generates and returns the >>> Payload-Oxum for the bag. >>> makecomplete: Completes a bag and then writes in a >>> specified format. >>> Completing a bag fills in any missing parts. >>> makeholey: Generates a fetch.txt and then writes bag >>> in a specified >>> format. >>> retrieve: Retrieves a bag exposed by a web server. A >>> local holey bag is >>> not required. >>> splitbagbyfiletype: Splits a bag by file types. >>> splitbagbysize: Splits a bag by size. >>> splitbagbysizeandfiletype: Splits a bag by size and >>> file types. >>> sword: Sends a bag using SWORD. >>> update: Updates the manifests and (if it exists) the >>> bag-info.txt for a >>> bag. >>> updatetagmanifests: Updates the tag manifests for a >>> bag. The bag must >>> be unserialized. >>> verifycomplete: Verifies the completeness of a bag. >>> verifypayloadmanifests: Verifies the checksums in all >>> payload manifests. >>> verifytagmanifests: Verifies the checksums in all tag >>> manifests. >>> verifyvalid: Verifies the validity of a bag. >>> [--version] >>> Prints version of BIL and exits. >>> [--help] >>> Prints usage message for the operation. >>> Examples: >>> bag verifyvalid --help >>> Prints help for the verifyvalid operation. >>> >>> >>> >>> -- >>> HARDY POTTINGER >>> University of Missouri Library Systems >>> http://lso.umsystem.edu/~pottingerhj/ >>> "No matter how far down the wrong road you've gone, >>> turn back." --Turkish proverb >>> >>> >>> >>> >>> >>> >>> On 7/26/11 5:31 PM, "Mark Diggory" wrote: >>> Hardy, Be aware that MIT / Richard Rodgers also has some Bagit work available, currently nested within the modules directory here: http://scm.dspace.org/svn/repo/modules/dspace-replicate/trunk/src/main/jav a/org/dspace/pack
Re: [Dspace-tech] Batch metadata corrections question: does anyone know why the limit is set to just 20 items at a time?
On Thu, Jul 28, 2011 at 15:50, helix84 wrote: > I think the most error-prone part will be displaying the "diff" (the > list of all changes) via HTTP. This is what is most likely to cause > long waiting times and timeouts, because a lot of HTML will be > generated. I would suggest the developers to improve this by paging the diff in UI. This should be practically as fast as command line import, it would allow those who want to review the changes page by page and it would allow those who don't want to review it to just confirm the import. Regards, ~~helix84 -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Batch metadata corrections question: does anyone know why the limit is set to just 20 items at a time?
I think the most error-prone part will be displaying the "diff" (the list of all changes) via HTTP. This is what is most likely to cause long waiting times and timeouts, because a lot of HTML will be generated. I had no problem with command line imports - you can even halve the time it takes if you use the -s option to suppress confirmation of changes, but I do not recommend this. Regards, ~~helix84 -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Batch metadata corrections question: does anyone know why the limit is set to just 20 items at a time?
On Thu, Jul 28, 2011 at 15:37, Heitor Barbieri wrote: > Usually, how much time do you wait to import 2000 items via the command line > interface? Not more than a minute. Regards, ~~helix84 -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Batch metadata corrections question: does anyone know why the limit is set to just 20 items at a time?
helix84 Usually, how much time do you wait to import 2000 items via the command line interface? Regards Heitor De: "helix84" Para: "Alexander Bernard Lemann" Cc: dspace-tech@lists.sourceforge.net Enviadas: Quinta-feira, 28 de Julho de 2011 9:17:16 Assunto: Re: [Dspace-tech] Batch metadata corrections question: does anyone know why the limit is set to just 20 items at a time? On Thu, Jul 28, 2011 at 14:00, Lemann, Alexander Bernard wrote: > Relatedly, does anyone know how safe it is to test higher limit values? I > looked at the code to determine whether these batch edits occur within a > single database transaction, but I didn't see any evidence either way. This shouldn't be any problem at the database layer. This limit and timeout problems concern only the web UI. I upped the limit to 2000 because I wanted to look at the "diff" in a web browser and it wasn't a problem - but I only did the preview, not the actual import step. I routinely run my imports of 2000 items via the command line interface. This dspace machine has only 1 GB of memory dedicated to it. Regards, ~~helix84 -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Batch metadata corrections question: does anyone know why the limit is set to just 20 items at a time?
On Thu, Jul 28, 2011 at 14:00, Lemann, Alexander Bernard wrote: > Relatedly, does anyone know how safe it is to test higher limit values? I > looked at the code to determine whether these batch edits occur within a > single database transaction, but I didn't see any evidence either way. This shouldn't be any problem at the database layer. This limit and timeout problems concern only the web UI. I upped the limit to 2000 because I wanted to look at the "diff" in a web browser and it wasn't a problem - but I only did the preview, not the actual import step. I routinely run my imports of 2000 items via the command line interface. This dspace machine has only 1 GB of memory dedicated to it. Regards, ~~helix84 -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Batch metadata corrections question: does anyone know why the limit is set to just 20 items at a time?
> -Original Message- > From: Andrea Schweer [mailto:schw...@waikato.ac.nz] > Sent: Wednesday, July 27, 2011 6:38 PM > To: dspace-tech@lists.sourceforge.net > Subject: Re: [Dspace-tech] Batch metadata corrections question: does > anyone know why the limit is set to just 20 items at a time? > > Hi, > > On 28/07/11 10:19, Peter Dietz wrote: > > Doing batch changes with a large number of changes will keep your > > system busy, and the reindexing can take a while. I've noticed that > > when we set the limit to be really high, it appears that nothing will > > happen from the user's browser for 20+ minutes, so I've connected to > > the server from the command line, and noticed that the reindexing task > > was taking a long time, but still running. So you might be safe with > > setting this to a really high number (several thousand), you'll just > > have to have the patience to not disrupt it. But smaller / more > > manageable batch sizes will complete in a reasonable amount of time. > > With this set to 1000 or more, I'm guessing your more likely to run > > into Out-Of-Memory errors > > With one of 'my' repositories, when we increased the limit (to 1000 I think), > completing the changes took so long that the Apache-Tomcat connection > timed out. This meant that the user saw an error in their browser even > though the changes actually went through fine. In our case we decided to > stick with a lower limit to avoid confusion. Though 20 really does feel very > low. There are some reports of this working with as many as 1000 items. http://dspace.2283337.n4.nabble.com/Excel-to-Dspace-td3310564.html Though it seems to be dependent on the amount of RAM available on your server. Relatedly, does anyone know how safe it is to test higher limit values? I looked at the code to determine whether these batch edits occur within a single database transaction, but I didn't see any evidence either way. Thanks, Alex Lemann -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] Developing static pages to be part of Dspace
Hi All, I have a separate portal for our Institutional Repository (http://ir.uz.ac.zw) that explains the purposes, policies etc about our Institutional repository that runs on apache web server. Our Repository which uses DSpace is accessible on http://ir.uz.ac.zw:8080/jspui (still using the JSPUI). Now I want to incorporate the pages on our portal to be part of our IR, maintain the same look and feel and only populating the content part of DSpace. Any idea on or how-to achieve this would be greatly appreciated. Regards, Admire Mutsikiwa -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] AUTO: Carolyn Groom is out of the office. (returning 01/08/2011)
I am out of the office until 01/08/2011. I will respond to your message when I return. Note: This is an automated response to your message "Re: [Dspace-tech] Setting file descriptions on batch import" sent on 7/28/2011 7:02:42 AM. This is the only notification you will receive while this person is away. This email and any attachments may contain private and confidential information and is solely intended for the recipient(s) only. If you have received this email and any attachments in error and you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is strictly prohibited. If you have received this message in error, please notify the sender immediately by reply email and delete the message and any attachments without retaining any copies. Any views or other information in this message which do not relate to our business are not authorised by us, nor does this message form part of any contract unless so stated. We offer no guarantees that this email or any attachment will be received error or virus free and accept no responsibility whatsoever in this regard. Our e-mail system is subject to random monitoring and recording by us. Carnegie College is a body incorporated under the Further and Higher Education (Scotland) Act 1992. Check out what is new at Carnegie @ www.carnegiecollege.ac.uk -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
