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, <dspace-tech-request@lists.sourceforge.net> 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-request@lists.sourceforge.net

You can reach the person managing the list at
       dspace-tech-owner@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 Properly        in      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 <Amir.Pourabdollah@nottingham.ac.uk>
Subject: Re: [Dspace-tech] Creative Common License Does not Show
       Properly        in      xmlui
To: "dspace-tech@lists.sourceforge.net"
       <dspace-tech@lists.sourceforge.net>
Message-ID:
       <4B6965E54E385E419329B3AA1E1A46F02C3389DF04@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 [wbossons@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 in    xmlui

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
wbossons@mit.edu<mailto:wbossons@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
<map:read type="BitstreamReader"> - context:/jndi:/localhost/xmlui/sitemap.xmap - 268:70

I know that there has been a known bug (http://dspace.2283337.n4.nabble.com/dspace-Bugs-2086708-xmlui-Creative-Commons-not-properly-displayed-td3294853.html ) but I just wonder if somebody in the meantime knows a solution to this. Things are OK in jspui and I wonder why the xmlui tries to show the license as an internal page not  just as a link to the CC website.

I have manually copied the necessary css files from the Creative Common website into the similar DSpace folders, now the look is a bit better but the links still don't work.

Please try http://elogeo.nottingham.ac.uk/xmlui/bitstream/handle/url/37/license_text to see what I mean!

Thanks,
Amir.


This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

<ATT00001..c><ATT00002..c>




------------------------------

Message: 2
Date: Wed, 27 Jul 2011 21:25:09 +0000
From: "Berry, Irene (CIV)" <icberry@nps.edu>
Subject: [Dspace-tech] Batch metadata corrections question: does
       anyone know why the limit is set to just 20 items at a time?
To: "dspace-tech@lists.sourceforge.net"
       <dspace-tech@lists.sourceforge.net>
Cc: "Brown, Simon Contractor, Digital Consulting Services"
       <scbrown@nps.edu>
Message-ID: <CA55D044.2AF1%icberry@nps.edu>
Content-Type: text/plain; charset="windows-1252"

Hello,
We're experimenting with making batch corrections to metadata using the Import Metadata feature in the jsp.  We'd like to raise the limit on the number of items that may be changed at a time.

I can see the file: http://scm.dspace.org/svn/repo/dspace/tags/dspace-1.6.2/dspace-jspui/dspace-jspui-api/src/main/java/org/dspace/app/webui/servlet/MetadataImportServlet.java

Where it says this:
// Set the lmimt to the number of items that may be changed in one go, default to 20
limit = ConfigurationManager.getIntProperty("bulkedit.gui-item-limit", 20);
log.debug("Setting bulk edit limit to " + limit + " items");


?We?d like to up it from 20 to maybe 500 as an experiment -- but potentially much higher.  Does anyone know if that's a really bad idea?  We just don?t know what the consequence is of making this limit larger, but 20 seems way too low for a typical batch of changes.

Thanks,

Irene Berry, MLIS
Digital Services Librarian
Dudley Knox Library, Naval Postgraduate School

-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 3
Date: Wed, 27 Jul 2011 16:29:58 -0500
From: "Pottinger, Hardy J." <PottingerHJ@umsystem.edu>
Subject: Re: [Dspace-tech] batch import of Bagit-formated collections
       and/or conversion script for Bagit to SAF
To: Mark Diggory <mdiggory@atmire.com>
Cc: "dspace-tech@lists.sourceforge.net"
       <dspace-tech@lists.sourceforge.net>
Message-ID: <CA55EBB4.70FB%pottingerhj@umsystem.edu>
Content-Type: text/plain; charset="us-ascii"

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> [operation arguments] [--help]
Parameters:
       <operation>
               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 <pottingerhj@umsystem.edu>
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" <mdiggory@atmire.com> 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/
>
>
><http://scm.dspace.org/svn/repo/modules/dspace-replicate/trunk/src/main/ja
>va/org/dspace/pack/>Mark
>
>On Tue, Jul 26, 2011 at 2:33 PM, Pottinger, Hardy J.
><PottingerHJ@umsystem.edu> wrote:
>
>Hi, I've done a bit of googling on Bagit, and I see that Dryad (and @mire)
>have done some work with Bagit as a repository interchange mechanism. I am
>interested in something a bit more mundane. There exists a very nice tool
>for constructing a "bag", called Bagger:
>
>http://sourceforge.net/projects/loc-xferutils/files/loc-bagger/
>
>
>Which would be ideal for adapting for our needs--we need a tool that a
>scanner technician can use to feed scanned images into our repository.
>
>Bags, in my mind, are not much different than SAF packages. It would be
>trivial to script a converter between the two formats, though I'm thinking
>someone is likely to have walked this path already. If so, and if you can
>share any code, or just talk about your approach, I'd love to hear from
>you. Thanks!
>
>
>--
>HARDY POTTINGER <pottingerhj@umsystem.edu>
>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
>
>
>
>
>
>--------------------------------------------------------------------------
>----
>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
>
>
>
>
>
>
>--
>Mark R. Diggory
>@mire - www.atmire.com <http://www.atmire.com/>
>2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010
>Esperantolaan 4 - Heverlee 3001 - Belgium
>




------------------------------

Message: 4
Date: Wed, 27 Jul 2011 21:56:58 +0000
From: Stuart Lewis <s.lewis@auckland.ac.nz>
Subject: Re: [Dspace-tech] batch import of Bagit-formated collections
       and/or conversion script for Bagit to SAF
To: "Pottinger, Hardy J." <PottingerHJ@umsystem.edu>
Cc: "dspace-tech@lists.sourceforge.net List"
       <dspace-tech@lists.sourceforge.net>
Message-ID: <8899EA18-5EF5-4D81-BFC1-C8428EF56E57@auckland.ac.nz>
Content-Type: text/plain; charset="us-ascii"

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> [operation arguments] [--help]
> Parameters:
>       <operation>
>               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 <pottingerhj@umsystem.edu>
> 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" <mdiggory@atmire.com> 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/
>>
>>
>> <http://scm.dspace.org/svn/repo/modules/dspace-replicate/trunk/src/main/ja
>> va/org/dspace/pack/>Mark
>>
>> On Tue, Jul 26, 2011 at 2:33 PM, Pottinger, Hardy J.
>> <PottingerHJ@umsystem.edu> wrote:
>>
>> Hi, I've done a bit of googling on Bagit, and I see that Dryad (and @mire)
>> have done some work with Bagit as a repository interchange mechanism. I am
>> interested in something a bit more mundane. There exists a very nice tool
>> for constructing a "bag", called Bagger:
>>
>> http://sourceforge.net/projects/loc-xferutils/files/loc-bagger/
>>
>>
>> Which would be ideal for adapting for our needs--we need a tool that a
>> scanner technician can use to feed scanned images into our repository.
>>
>> Bags, in my mind, are not much different than SAF packages. It would be
>> trivial to script a converter between the two formats, though I'm thinking
>> someone is likely to have walked this path already. If so, and if you can
>> share any code, or just talk about your approach, I'd love to hear from
>> you. Thanks!
>>
>>
>> --
>> HARDY POTTINGER <pottingerhj@umsystem.edu>
>> 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
>>
>>
>>
>>
>>
>> --------------------------------------------------------------------------
>> ----
>> 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
>>
>>
>>
>>
>>
>>
>> --
>> Mark R. Diggory
>> @mire - www.atmire.com <http://www.atmire.com/>
>> 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010
>> Esperantolaan 4 - Heverlee 3001 - Belgium
>>
>
>
> ------------------------------------------------------------------------------
> 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


End of DSpace-tech Digest, Vol 63, Issue 64
*******************************************