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-requ...@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-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 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.pourabdol...@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:
>        <
> 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
> 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
> wboss...@mit.edu<mailto: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
> <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_textto 
> 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)" <icbe...@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"
>        <scbr...@nps.edu>
> Message-ID: <ca55d044.2af1%icbe...@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." <pottinge...@umsystem.edu>
> Subject: Re: [Dspace-tech] batch import of Bagit-formated collections
>        and/or conversion script for Bagit to SAF
> To: Mark Diggory <mdigg...@atmire.com>
> Cc: "dspace-tech@lists.sourceforge.net"
>        <dspace-tech@lists.sourceforge.net>
> Message-ID: <ca55ebb4.70fb%pottinge...@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 <pottinge...@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" <mdigg...@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.
> ><pottinge...@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 <pottinge...@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.le...@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." <pottinge...@umsystem.edu>
> Cc: "dspace-tech@lists.sourceforge.net List"
>        <dspace-tech@lists.sourceforge.net>
> Message-ID: <8899ea18-5ef5-4d81-bfc1-c8428ef56...@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 <pottinge...@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" <mdigg...@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.
> >> <pottinge...@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 <pottinge...@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
> *******************************************
>
------------------------------------------------------------------------------
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

Reply via email to