Re: [Dspace-devel] DSpace deployment methods
Hi Robin, I'm hoping for the build/deploy/config process to be easier. If we eventually had configurations living within the DB (within the instance) that would be great. An instance could set config from the UI, and not-quite-reload, but just the config is updated, that would be great. That is however a different subject, a helpful one though. Build Once, Run Anywhere. Yep. We build on a server that doesn't run DSpace. Then scp the dspace-installer over to the app server. For each instance we have their config directory in its own git repository. So, locally I can upgrade configs for a site, push it to git. Then for that site, pull its configs back down. So on each app server, it might be ant -Dconfig=/home/some-university/config/dspace.cfg update, Since ant is a bit egregious with touching your configs, its followed with cd /home/some-university/config; git reset HEAD --hard; then restarting tomcat. There's more to do. SOLR 5 is going to change the game for solr. Such that DSpace won't be able to ship solr, it will no longer be a tomcat webapp, but it will instead be a standalone service / daemon. So, we'll need to clean up (if we have any custom solr code), and figure that out. And/or, an implementation for some other flexible no-sql data store, that can handle search/browse/statistics/faceting, ... The concept of a SITE within DSpace is interesting. Instead of having so many instances of DSpace, what.. really is distinct between instance A and instance B? The theme, the content, a few configurations. Expand the SITE DSO of DSpace to handle multiple DSpace sites. So then one DSpace instance can run dozens of SITES. Upgrading your instance of DSpace... upgrades all of your sites. boom. I'm dreaming here. I'm really trying to shed data OFF of the dspace instance, but rather into safe harbors. A dedicated postgres server, a log server, bitstreams into s3, configuration into the DB, sessions.. I don't know where. Thus, an instance of DSpace is really nothing, just the running application, your data is elsewhere. So instead of updating your instance. The eventual plan could be a "stateless" server. When your running DSpace build 100, and your ready to deploy DSpace build 105, just build new instances of 105, and then have your load balancer stop and shut down the build 100 instances. Do you update/upgrade, or just in with the new, out with the old. Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 On Fri, Aug 21, 2015 at 10:19 AM, TAYLOR Robin wrote: > Hi all, > > > Apologies for keeping this one running, but I'm still thinking about this > subject. My gut feeling is that I don't want to run a Maven build on a live > server, for two reasons... > > > 1. Java has always claimed to be a 'Build once, run anywhere' language. So > I want to build and test elsewhere, then deploy the tested app. > > 2. I instinctively don't like having development tools on a live server, > it feels like a dodgy thing to do, although I would struggle to justify > that statement. > > > At the moment we only copy the target build directory to our live server, > and then run 'ant update...' on the live server. But even that feels a bit > hacky. > > > At this point I should stop talking and read up on Tim's Commons > Configuration work. > > > Cheers. > > > Robin Taylor > Main Library > University of Edinburgh > > > -- > *From:* Tim Donohue > *Sent:* 17 August 2015 15:10 > *To:* dspace-devel@lists.sourceforge.net > > *Subject:* Re: [Dspace-devel] DSpace deployment methods > > Hi Robin, > > I am working to disentangle configuration from Maven & Ant builds in the > Commons Configuration work (aimed for 6.0). Once we switch to Commons > Configuration, we should be able to simply remove all our custom config > variable interpolation "magic" that Maven & Ant does. Commons > Configuration does interpolation on-the-fly, which means Maven and Ant > should no longer need to touch any of our configs (thought Ant will still > need a dspace.dir to install to obviously). > > See https://github.com/DSpace/DSpace/pull/991 and > https://jira.duraspace.org/browse/DS-2654 for a bit more info. > > - Tim > > On 8/17/2015 5:07 AM, TAYLOR Robin wrote: > > Hi Terry, > > > That's really useful, thanks. The main problem for me is that > configuration is so entwined with both the Maven build and the Ant > installation, it makes it difficult to find a process that avoids having to > do a Maven build on a live server, and hack various bits of configuration > specific to that server. Sigh [image: 😊] > > > Cheers, Robin. > > > Robin Taylor > Main Li
Re: [Dspace-devel] PLEASE VOTE on whether to include "Services API" refactoring in DSpace 6.0
I am happy to have an ORM added. I'm not really a fan of adding DAO, Service, ServiceImpl for each class, it feels verbose, but I guess it separates concerns. My coworkers' experience with Hibernate is that it does 90% of things well, but the remaining 10% is a major pain. Code where you thought you were making 1 query turns into thousands of queries. I'd like to see some performance comparisons between our native SQL, and hibernate's execution plan. Hibernate's caching and lazy-loading sound like improvements though. I'm supportive, I'll dig in, to see if I find any deal breakers. Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 On Thu, Aug 6, 2015 at 11:20 AM, Bram Luyten wrote: > +1 > > Bram > > -- > [image: logo] > *Bram Luyten* > *250 Lucius Gordon Drive, Suite B-3A, West Henrietta, NY 14586* > *Esperantolaan 4, Heverlee 3001, Belgium* > www.atmire.com > <http://atmire.com/website/?q=services&utm_source=emailfooter&utm_medium=email&utm_campaign=braml> > > > On 6 August 2015 at 16:50, Tim Donohue wrote: > >> I vote +1 >> >> - Tim >> >> >> On 8/6/2015 9:47 AM, Tim Donohue wrote: >> >> Hi Developers / Committers, >> >> As mentioned in yesterday's developers meeting, I'm calling a public VOTE >> around whether we include the Services API refactoring in the upcoming >> DSpace 6.0 release. As this change constitutes a major code refactor of >> the "dspace-api" (DSpace Java API), we'd appreciate feedback from anyone on >> this direction for 6.0. (If you have not yet read about the Services API >> refactoring, a brief summary and links to more information is provided at >> the end of this email) >> >> Please VOTE with one of these three options: >> >> +1 = "I agree. We should include Services API refactoring in 6.0" >> >> 0 = "I'm undecided / unsure" (Please provide a reason) >> >> -1 = "I disagree. The Services API refactoring should NOT be included in >> 6.0" (Please provide a reason why you disagree) >> >> Per our Voting Procedures [1], a vote on code modifications requires: "at >> least three positive (+1) votes, and no negative votes (-1) to pass. In >> this scenario, a negative vote constitutes a 'veto'." While *anyone* is >> welcome to vote, only Committers have "binding" votes (and can cast a >> veto). Others are free to vote to express your opinion, but those votes >> are considered advisory in nature. >> >> This public vote will be open until *15:00 UTC (11:00am EDT) on >> Wednesday, August 12* (which is the time of our next Developer Meeting). >> >> If there are any questions, feel free to ask them on this thread. >> >> >> *Summary of Services API refactoring* >> >> The Services API refactoring is a major refactoring of the "dspace-api" >> (DSpace's Java API) to better support "separation of >> concerns/responsibilities". Simply put, often, in the existing API, there >> is an intermingling of business logic and database logic which is difficult >> to maintain, debug and/or build against. One of the most obvious examples >> is how we deal with database software support (PostgreSQL vs. Oracle), but >> such intermingling of logic exists in many of our core classes. The DSpace >> "Services API" attempts to tease apart the database logic from the business >> logic into separate layers, while also adding support for Hibernate ( >> http://hibernate.org). The goal is to provide an easier to maintain, >> more modular API, while also enhancing how we deal with database logic in >> general (via Hibernate). >> >> Much more information with documentation, tutorials/examples, and a video >> presentation at: >> https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api >> >> What does adding this refactor to 6.0 mean? >> >>- This is essentially a *new* Java API for DSpace. But, it performs >>a very important refactor (see "Pros" below). >>- It is not backwards compatible with the existing API. All >>developers and Committers who work with the Java API will need to learn >>this new API, as all future development will require using this Java API. >> - Committers will be expected to learn, use and support this API >> immediately. @mire will be providing additional training materials / >> examples to help everyone get up to speed. >> - We also will need im
Re: [Dspace-devel] Support on RestAPI using LDAP authorization
Hi Glenson,
It appears that using DSpace's auth framework is missing from REST API. Its
hardcoded to use DSpace EPerson password auth.
https://github.com/DSpace/DSpace/blob/master/dspace-rest/src/main/java/org/dspace/rest/TokenHolder.java#L54
public static String login(User user) {
EPerson dspaceUser = EPerson.findByEmail(context, user.getEmail());
if ((dspaceUser == null) ||
(!dspaceUser.checkPassword(user.getPassword( {
...
A better solution would be to update the REST API authenticate to use what
SWORD does, and just call the Auth stack...
https://github.com/DSpace/DSpace/blob/master/dspace-swordv2/src/main/java/org/dspace/sword2/SwordAuthenticator.java#L53
public boolean authenticates(Context context, String un, String pw)
{
int auth = AuthenticationManager.authenticate(context, un, pw, null, null);
if (auth == AuthenticationMethod.SUCCESS)
{
return true;
}
return false;
}
We should also add rate limiting to the REST API login api. Something like
fail2ban might help, but repeated failed logins should be prohibited.
Peter Dietz
Longsight
www.longsight.com
pe...@longsight.com
p: 740-599-5005 x809
On Wed, Aug 5, 2015 at 5:02 AM, Galupo, Glenson Carlo V.
wrote:
> I just wanted to know if you are supporting LDAP authorization to login in
> RestAPI.
> Thanks...
>
> --glenson
>
>
> --
>
> ___
> Dspace-devel mailing list
> Dspace-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
>
--
___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] Feedback on migrating mailing lists off SourceForge
What happens to emails when someone a year from now sends an email to dspace-t...@lists.sourceforge.net, since a decade of random documentation suggests so, they've historically been subscribed, and used to just work? I'm guessing they'll get a bounce, can there be a message in the bounce? "This listserv has migrated to dspace-tech@gg . com" Or is there some forwarding option? I tend to like Mark Wood's tonic of "rip the bandaid off now", so, migrate to GG, and decommission SF. Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 On Mon, Aug 3, 2015 at 2:06 PM, Tim Donohue wrote: > Hi Graham, > > The Groups Migration API unfortunately only works for Google Apps Groups. > It won't work for normal "googlegroups.com" Groups (annoying, I agree). > See it's prerequisites: > > https://developers.google.com/admin-sdk/groups-migration/v1/guides/prerequisites > (There's also no way to migrate a Google Apps Group to a normal " > googlegroups.com" Group. So you cannot even use Migrations API as a "pass > through".) > > So, the only route to migrate messages into googlegroups.com is to send > them via SMTP. Here's an example: > https://github.com/wojdyr/fityk/wiki/MigrationToGoogleGroups > > Unfortunately, that's the route that seems to no longer take note of the > "Date:" field. This is the same route that Fedora used when they moved > from SF to GG. But, back then (mid-2013), GG *did* respect the "Date:" > field even when sending archives via SMTP. Though Fedora had a different > problem back in 2013, where all messages migrated under the same user -- if > you browse the Fedora archives ( > https://groups.google.com/forum/#!forum/fedora-tech) back to mid-2013 > you'll find that all messages appear under a user named "Fedo Raadmin" > (Fedora Admin). In my test migrations, all migrated messages retain the > "From:" field (sender info) and all other fields *except* for "Date:". > Interestingly, the "Date:" field actually does get migrated properly, but > it is no longer utilized in the browse interface for Google Groups (instead > it seems to be using the date provided in the latest "Received:" header). > > That's the best solution I've managed to come up with thus far. If you > know of anything else, I'd definitely be interested. But from my tests, > sadly, I haven't been able to find any way around the "Date:" problem. > > - Tim > > > > On 8/3/2015 10:12 AM, Graham Triggs wrote: > > How are you planning to do the migration, as the Groups Migration API > documentation suggests that it does take notice of the Date: field in the > (RFC 822 formatted) messages? > > G > > On 3 August 2015 at 15:40, Tim Donohue wrote: > >> Hi Developers / Committers, >> >> As of yet, I've heard little feedback on the proposed mailing list >> migration. So, I'm assuming no one else has major objections to any of >> these options. >> >> Currently, I'm leaning towards just migrating all mailing lists + >> archives into Google Groups, even though the dates of archived messages >> will appear incorrectly (this is option #1 described below). We can >> then add a note to the Google Group description letting everyone know >> that earlier messages all appear under the same date. I have not yet >> scheduled a start date for this process, but I'd hope to have it >> completed by the end of August. I plan to migrate less active lists >> first, and save our most active lists (dspace-tech especially) for >> last. Obviously though, I'll let each list know prior to migrating that >> list. >> >> Please do let me know though, if you have any thoughts (or prior Google >> Groups migration experience to share). >> >> Thanks, >> >> Tim >> >> On 7/29/2015 2:27 PM, Tim Donohue wrote: >> > Hi Developers, >> > >> > In case you haven't seen recent Developer Meeting notes, I wanted to >> > update everyone here on recent working investing the migration of our >> > DSpace mailing lists off of SourceForge (lists.sourceforge.net). As >> > you may have heard, SourceForge had some major stability issues >> > recently [1], plus there's been controversy around its practices [2], >> > not to mention the fact that all our mailing lists have crashed twice >> > this year already (Feb then last week). >> > >> > So, in some discussions on IRC, several of us feel it's about time to >> > move entir
Re: [Dspace-devel] Thoughts on format of config/default.license?
Once upon a time, I built a proxy license submission step. A penultimate step step that lets admin users upload a file "by proxy". And so they are uploading a signed document (PDF) https://github.com/osulibraries/DSpace/blob/osukb/dspace-api/src/main/java/org/dspace/submit/step/UploadLicenseStep.java Nobody views that license / file. Its only for legal/archival purposes for (in case) someone challenges how the repository obtained the original document. I guess another question you are asking is should the system store presentation information (markup / html), or should it be plain text. Another question is what's the purpose of the license? Just to present something better looking to the user before they click "I agree"? You could try to render the license within the license acceptance page. PDF's have better success at rendering than doc. http://stackoverflow.com/questions/1469/embed-pdf-in-html5 Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 On Mon, Apr 27, 2015 at 5:05 PM, Mark H. Wood wrote: > I was handed a Word document for use as a deposit license. Of course > that doesn't work, but what does? I carefully extracted and > re-formatted the content as plain text, and it was nearly destroyed by > the UI. > > It turns out that the license text is neither one thing nor another. > It seems to be provided by machine-machine interfaces that would make > HTML problematic. But XMLUI treats it as a "simple HTML fragment", > which gets it rendered as ordinary character data (meaning that my > nice spacing and multilevel bullet lists get squashed). > > What should we do with this thing? If it has to be plain text, then > XMLUI should treat it as so it doesn't get > rewrapped/filled/generally blenderized. Or should it *really* be an > HTML fragment in which we can use markup appropriate to the interior > of the element? Something else? > > -- > Mark H. Wood > Lead Technology Analyst > > University Library > Indiana University - Purdue University Indianapolis > 755 W. Michigan Street > Indianapolis, IN 46202 > 317-274-0749 > www.ulib.iupui.edu > > > -- > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] Bitstream storage refactor, i.e. Amazon S3
Hi All, I was going to tackle a quick-and-dirty S3 implementation for storing Bitstreams, to solve a pressing need of ours. (Lower cost cloud file storage). I was wondering if anyone had any suggestions on what also I should look at when touching that area. A proper BitstreamManager interface that can be extended to support LocalFileSystemBitstreamManager, AmazonS3BitstreamManager? It looks like the latest I can see in this space is: https://wiki.duraspace.org/display/DSPACE/DSpace+2.0+Pluggable+Storage Advice welcome. Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] Installing xmlui theme per dc.type
Another route to go would be to use a single theme, and then have XSL logic that changes the behavior of item-view, depending on that metadata value. In my theme I've been changing the display behavior depending on the mimetype of the bitstreams (audio, video, document), as well as metadata values, ex ds.firstpage.side=left [2] alters the bookreader to have a the first page of a scanned book display on the left side of a bookreader spine. [1] https://github.com/LongsightGroup/DSpace/blob/0f246b859df06cdd539f87896cca1635fffcafd2/dspace-xmlui/src/main/webapp/themes/mirage2/xsl/aspect/artifactbrowser/item-view.xsl#L908 [2] https://github.com/LongsightGroup/DSpace/blob/longsight-4_x/dspace-xmlui/src/main/webapp/themes/mirage2/xsl/aspect/artifactbrowser/item-view.xsl#L879 I'm longing to add a Collection Configuration page, where you could add some configuration values to a collection, and then have the theme change actions based on that. i.e. collection.map.show = true ________ Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 On Mon, Apr 13, 2015 at 1:51 PM, Mark Diggory wrote: > John, > > Seems sensible, what would be ideal is if we could arrive at some sort of > language for the field that would allow for matching on other criteria. > > Some days I wonder why this isn't just in the cocoon sitemap, xmlui.xconf > is very limiting and unwieldy. Alternatively, making the matcher into > Service and giving it a spring based configuration with matching rules > would also be extremely extensible without needing special "xmlui.xconf > parsing code" that you'd need to extend/alter to create your own config > attributes. > > Mark > > > > > On Mon, Apr 13, 2015 at 10:27 AM John Preston > wrote: > >> So if I add some rule patterns to the xmlui.xconf (regex=? section) that >> dont break the existing ones, and add code to ThemeMatcher (lines 105 to >> 120+) that use the uri to instantiate the dspace object and find some >> metadata and match to the rule pattern (similar to the checking handles >> code) then I should be good to go. >> >> >> John >> >> On Mon, 13 Apr 2015 at 11:18 Mark Diggory wrote: >> >>> John, >>> >>> You could add a theme match on Item handle. We have overridden >>> ThemeMatcher in other projects and extended it with additional support for >>> features such as requested domain name. I can see it feasible to extend it >>> to support checking for specific metadata fields in the 5.x DSpaceObject >>> metadata. >>> >>> >>> https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/java/org/dspace/app/xmlui/cocoon/ThemeMatcher.java >>> >>> Cheers, >>> Mark >>> >>> >>> On Mon, Apr 13, 2015 at 9:12 AM John Preston >>> wrote: >>> >>>> Hi All, Can anyone say if it is possible within DSpace 5.x codebase to >>>> install a different xmlui theme based on a dc.type similar to what is done >>>> to install a theme per collection or community, or if not then how easy it >>>> would be for me to add a hack or code to implement such a beast. >>>> >>>> John >>>> >>> >>>> -- >>>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >>>> Develop your own process in accordance with the BPMN 2 standard >>>> Learn Process modeling best practices with Bonita BPM through live >>>> exercises >>>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- >>>> event?utm_ >>>> >>>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___ >>>> Dspace-devel mailing list >>>> Dspace-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/dspace-devel >>>> >>> > > -- > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live > exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] Java7 EOL April 2015
Hi All, The JDK lifecycle length has changed in Java 7, with Oracle ending public support for Java 7 this month, April 2015. http://www.oracle.com/technetwork/java/eol-135779.html I don't know if major testing of DSpace with Java 8 has occurred, but it appears that the time to shift to JDK8 has already happened. To me, it feels like JDK6 was supported for a very very long time, and now JDK7 feels short lived in comparison. So, I was wondering if there was any JAVA8 known issues with DSpace. Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] We need to think a bit more about how we use the 'statistics' Solr core
Just to ask a follow up question about Google Analytics. Say I have all of my data (comm, coll, item views, bitstream downloads) for as long as I've been collecting it in SOLR or Elastic Search (many years). Is it possible to write a converter, and push this legacy information to Google Analytics? i.e. GA has bulk ingest API's where I can push legacy/historical events in? Also. What are people thinking would be a safe preservation location for usage events? i.e. for people concerned about resources. Could it be feasible to export all SOLR usage event data to log/usage-event..log, and then have all new real-time usage events from now on written to usage-event.log. Then when we need to populate a new statistics engine. We could populate it by indexing usage.event.logs >From my perspective, we've got 200GB+ of solr/ES indexes across instances, plus memory and CPU and ES instances, and it would be nice to outsource this work. Especially if GA is free. ____ Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 On Tue, Mar 17, 2015 at 5:06 AM, TAYLOR Robin wrote: > Hi Andrea, > > You are quite right about the download stats, I had forgotten that. > > Cheers. > > Robin Taylor > Main Library > University of Edinburgh > > From: Andrea Schweer > Sent: 16 March 2015 02:31 > To: TAYLOR Robin > Cc: DSpace Developers > Subject: Re: [Dspace-devel] We need to think a bit more about how we use > the 'statistics' Solr core > > Hi Robin, > > On 14/03/15 05:22, TAYLOR Robin wrote: > > Just a wee point about GA stats with apologies if I am stating the > obvious. You can present data going back as long as you have been > collecting it, not just from the moment you enable the DSpace GA Stats > XMLUI aspect. > > "As long as you have been collecting it" is fine for item page views. > But bitstream downloads really is the more interesting measure, and GA > knows about these only from when the download-as-GA-event code is > enabled, which is DSpace 5 if I remember correctly. That is a bit > disappointing to repository managers with download stats in DSpace that > go back to 2005. As far as I know, it isn't possible to bulk update GA > with retrospective data. > > cheers, > Andrea > > -- > Dr Andrea Schweer > IRR Technical Specialist, ITS Information Systems > The University of Waikato, Hamilton, New Zealand > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > > -- > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] We need to think a bit more about how we use the 'statistics' Solr core
ES is equally guilty of being a statistics data source, by storing original/raw. So, statistics is something that complicates DSpace's role in preserving assets, since stats are a value-add, and not a core repository function. But, since repo managers enjoy statistics, we can't not offer statistics. I would however like to offload the role of stats to a third party, such as Google Analytics though. Back to the relevant discussion. Both SOLR and ES prefer to be just indexes, something that you could rebuild if necessary. If you have all dspace.log's you potentially could rebuild, but its very laborsome. I've considered having an alternative log file, logs/usage-stats..log, that was similar to the output of stats-log-exporter|convertor, and input of stats-log-importer. Thus, that would be the source of record, and the stats engines could rebuild from this. Currently more information is being stored in the stats engines than gets logged to dspace.log (useragent, hostname, ...). I've added the ability for SOLR to export its data to csv: https://github.com/DSpace/DSpace/commit/f57619d726c07535ce786a3f79e9c39d56fd9031 So, potentially, one could run that regularly to have backup data points... ____ Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 On Wed, Mar 11, 2015 at 6:11 PM, Andrea Schweer wrote: > Hi, > > On 12/03/15 09:11, Mark H. Wood wrote: > > Several recent issues (DS-2337, DS-2487, and perhaps DS-2488) suggest > > that we should step back and take a long look at how we are using the > > Solr 'statistics' core. terms of promotion > > I agree with Mark, we need to at least make sure that we keep the data > safe across upgrades. Just a note, even the dspace.log files are not > helping 100% since they don't contain information that is now stored in > the solr statistics (referer, user agent) and some of the derived > information may change over time (geo / DNS lookups of IP addresses). > Usage statistics are not the primary purpose of a repository, but my > repository managers at least have made it very clear that this data is > important to them (in terms of promotion of the repository etc). > > > I think we need to give some more thought to how we can readily > > preserve usage records over DSpace upgrades and system failures. > > Let's also not forget that the authority core might be in a similar > situation at some point down the track. When enabled, it is the main > data source for authority data, if I understand things correctly. The > DSpace authority key, in that case, holds an id that is only meaningful > in the context of the authority solr core. So you would not lose the > disambiguation, at least, but you would lose the link(s) to external > authority sources. > > I'm assuming that the ElasticSearch statistics are affected by a similar > issue - using a mechanism not designed as a primary data source to > actually be the primary data source. But I haven't looked at the > ElasticSearch stats at all, so I may well be wrong on this. > > OAI and discovery are fine, they just hold a copy of data from elsewhere > and there is no problem with blowing away these cores and re-creating > them from the source data. > > > I should admit here that I am skeptical of using Solr as the > > statistics store *at all*, however well it works most of the time. > > But it is not my purpose in this note to advocate for something > > different. > > I'm not sure I have a solution either, other than perhaps a clear > statement from the committers to keep the data safe. At the minimum, it > will mean that every pull request will need to be examined for changes > to the solr schema and if there is one, it needs to come with an upgrade > path or the PR can't be merged. > > We could also put some resources into improving the existing > import/export functionality for the statistics so that no data gets lost > during those processes. This would allow people to back up their > statistics data regularly or at least before upgrades. We'd need > something similar for the authority core. > > And/or we could put some resources into generic solr reindexing code. We > have a first cut from Terry Brady at Georgetown, linked from > https://jira.duraspace.org/browse/DS-2489 (to add uids to the statistics > core). I've taken his approach and made it a little more generic; Hardy > is testing it at the moment but it looks like it won't quite get us > there. It's linked from https://jira.duraspace.org/browse/DS-2486 > > cheers, > Andrea > > -- > Dr Andrea Schweer > IRR Technical Specialist, ITS Information Systems > The University of Waikato, Hamilton, New Zealand > > > &
[Dspace-devel] Merging Community and Collection, into Container
Hi All, Here's an idea that I've been thinking about for some time. What if DSpaceObjects Community and Container got merged together into an object called Container. Thus, you could submit an item to a container. You could also add a container to a container. You couldn't submit an item to the root though. I was wondering if anyone else has been considered this, and if there are pro's con's of such a change. So, current DSpaceModel hierarchy is: Site - Community - - Collection - - - Item - - - - Bundle - - - - - Bitstream With the Container change, it would be: Site - Container - - Item - - - Bundle - - - - Bitstream Bundle is feeling a bit vestigial at this time, now that we have metadata4all, so Bundle could get yanked out. We would still need to indicate the type of bitstream, but perhaps would could do something to indicate derived bitstreams and relationships between source and derived better. With the Bundle change, and the Container change, the model looks like: Site - Container - - Item - - - Bitstream Then, I'm also thinking about with that SITE DSO, doesn't this sort of imply that a DSpace instance could be multi-tenant. One DSpace instance could hold multiple sites? Yes, obviously all of these ideas being positing would require work, cleanup, and discussion. I'm just wondering if anyone has thoughts on these approaches. Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] Maven optional modules
I would rather mirage2 be a regular (compiled) xmlui theme. I rarely add new JS libraries, and when I do, I can include them via
Re: [Dspace-devel] Do we not have administrator documentation for the 'RequestItemAuthorExtractor's?
How about: https://wiki.duraspace.org/display/DSDOC5x/Request+a+Copy Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 On Thu, Oct 23, 2014 at 10:07 AM, Mark H. Wood wrote: > Confluence could not find the string "RequestItemAuthorExtractor" in > the official documentation, and there's no mention of alternate or > custom extractors in Using DSpace | Request a Copy. Have I failed to > find it, or do we need to write it? > > -- > Mark H. Wood > Lead Technology Analyst > > University Library > Indiana University - Purdue University Indianapolis > 755 W. Michigan Street > Indianapolis, IN 46202 > 317-274-0749 > www.ulib.iupui.edu > > > -- > > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] Pascal's Linked Open Data PR
Hi All, Not sure if I should email dspace-devel or dspace-release. Cross posting... FYI, I'm +1 on Pascal's Linked Open Data PR. https://github.com/DSpace/DSpace/pull/568 I'm hoping people can review that, and/or comment with their opinions. So we can press or not press merge. One of the hopes is that a follow-up PR will happen to this ticket, which adds the dspace-oceanlink/dspace idea of the sesame triple store, so this can work out of the box. The current PR requires some setup, such as adding Apache Fuseki. ________ Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] Versioning the REST API, i.e. /rest/v1, /rest/v2
I really just want to gracefully migration from v1 syntax to v2. (In reality it's more of v1 to v1.1, where one or two things cause some incompatibility), i.e. getting parent community list or something is named slightly differently, and/or to get subcollections you would need to call another endpoint to get the data: /communities/:id/collections I'm thinking the same /rest webapp could include both v1 and v2 routes, just put them into another package, and annotate the routes. It's just this is extra effort, it adds to the maintenance burden, it causes the api to be less simple, and I'm just planning to deprecate/remove the v1 stuff, and make v2 the new default. So, just a crutch so that you don't break your rest consumer apps. Which is why I'm wondering if this is even necessary. Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 On Mon, Oct 13, 2014 at 12:11 PM, helix84 wrote: > Hi Peter, > > On Mon, Oct 13, 2014 at 5:19 PM, Peter Dietz wrote: > > i.e. DSpace 4 Read-Only API to be available at: /rest/v1 > > and DSpace 5 CRUD API to be available at: /rest/v2 > > this (ability to request a particular API version) makes sense only if > you're going to expose both API versions in DSpace 5. Which would be > great, but is this what you're going to do? OTOH, if you're only > informing the user of API version, just make it part of the response > (e.g. 5) to an info endpoint (a.k.a. > Identify in OAI-PMG or servicedocument in Atom). > > Regards, > ~~helix84 > -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://p.sf.net/sfu/Zoho___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] Versioning the REST API, i.e. /rest/v1, /rest/v2
Hi All, The Jersey REST API that shipped with DSpace 4, lets call the DSpace REST API v1. (Yes, there were other API's before it, Hedtek, Wijiti, GSOC). In DSpace 5, the REST API is still based on JERSEY, and it will add CRUD operations. See demo of DSpace 5 CRUD REST API: https://www.youtube.com/watch?v=Ba9TL1Pl5pw This CRUD API is very similar to the existing read-only API, the structure of most responses is very similar. But, there are some minor tweaks. So, I'm wondering what the advice of the crowd is? Should we just have DSpace 5 ship with a changed API? Or should we bother with "versioning" the API? i.e. DSpace 4 Read-Only API to be available at: /rest/v1 and DSpace 5 CRUD API to be available at: /rest/v2 ? Thoughts... I'm not sure how widely used the existing READ-only DSpace 4 API gets. i.e. If you didn't use DSpace 4 rest, then there's nothing to worry about. But, if you have built some integrations / apps on the DSpace 4 API, there will be the minor changes... So, what's to best way to inform API consumers that when you upgrade these are the changes that you need to make to your consumer app immediately. Or, do we go the extra mile now to add api versioning (which unfortunately would need to be yet-another-thing-to-spend-development-time-on, and yet-another-thing-to-support). Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://p.sf.net/sfu/Zoho___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] Rethinking dc.description.provenance?
Not entirely related to dc.description.provenance, but I want to see a thorough validatable audit log from the system. i.e. Who changed what/when/why/how. i.e. This Group name used to be "ABC Staff", now it's just "Staff", who did that, when did they do that, what was the previous value. What changes have been made in the past 7 days. This shouldn't really show up in the metadata section (we could use metadata4all I guess though). But I think those events would need timestamps. (Maybe even a isCurrent flag, to hold on to previous version of metadata field). Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 On Thu, Oct 9, 2014 at 3:27 PM, Mark H. Wood wrote: > While reviewing DS-2082 I realized that the way bitstreams are handled > in the provenance doesn't make much sense to me. I'll admit that I > don't think people are adding and removing bitstreams within > particular items all that often, but still, I feel that this is simply > an awful format for recording how an item came to be as it is. > > Should we not append a *new* dc.description.provenance value every > time the item is changed, rather than endlessly extending a single > one? The single string is awfully hard to read, let alone > mechanically parse, and at some point one will surely overflow the > maximum size of a TEXT column. Listing all of the bitstreams' names > in a single line every time there is a change is also not so > scalable. That's one factor that led to DS-2028 in the first place. > > I recall that there have been proposals for more radically > reorganizing this information, and perhaps that's what we should do. > But at a bare minimum, shouldn't we break the history of an item down > into separate entries, instead of stringing them together? > > BTW the change I suggest would require some other work, as right now > we are lucky that the appending happens on the proper metadatavalue. > MetadataUtilities.appendMetadata clearly was supposed to index through > matching entries looking for the "right" one, but in fact it ignores > the index and always appends to the first value that that DBMS happens > to return. I'm filing an issue on that, as it seems wrong > regardless. OTOH I see that it's only used three places, all in the > item updater, and likely would have no purpose if we change the way > item updates are recorded. > > -- > Mark H. Wood > Lead Technology Analyst > > University Library > Indiana University - Purdue University Indianapolis > 755 W. Michigan Street > Indianapolis, IN 46202 > 317-274-0749 > www.ulib.iupui.edu > > > -- > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] Metadata For All merged into master (DSpace5), run db update scripts.
Hi All, If you happen to be living on master branch, we've merged in @Mire/Kevin's MetadataForAll PR. https://github.com/DSpace/DSpace/pull/654 So, you'll see some new output in your build (ant step), update_registries: https://gist.github.com/peterdietz/15e573a83bb33d667151 Also, there are a lot of new database tables, so you'll need to run your DB upgrade step. Here's the schema change: https://github.com/DSpace/DSpace/pull/654/files#diff-d8e63cb1eda0c1fdf876c03785e9713dR17 Of note would be that if you happen to use the same database for DSpace4 development, as for DSpace5 development, and switch back and forth. This is kind of that significant change that will require you to have a separate DB for each. I've just updated my local development machine, and so far so good. The main change with this is that instead of model specific metadata living in that model's table. i.e. collection.name, it now lives in metadatavalue, with resource_type_id = 3 resource_id = collection.id, and metadata_field = field-value-for-dc-title (64 or something). You get the idea. Also, theoretically if you wanted to start adding collection specific metadata, such as collection.metadata['dc.date.issued'] = 2014-09-26, you would just need to be altering UI's to be able to set that anything fields. Also reminder: DSpace 5 Feature PR cutoff date is Oct 6th. In my timezone, thats 11 days from now. So, contribute early, and help review our backlog of PR's. There's 83... Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] DSpace 5: Dates and Features
Greetings from the DSpace 5.0 Release Team! We have another exciting release of DSpace in the works that has been growing steadily over the past few months. Many contributors have been busy adding new features and improvements to DSpace. This speaks volumes to the maturity, stability, and future of DSpace, that as the software project approaches its 12th year, we're still going strong. Read on for ways to help contribute, and find out the new features in DSpace 5. The full release schedule is here: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.0+Status October 6: Deadline for Feature Pull Requests In plain English, October 6 is the last day you may submit new features for acceptance into DSpace 5.0. If you are working on a new feature for DSpace, we urge you to prepare a Pull Request now. Getting your work visible early as a Pull Request allows others to review, and help steer your contribution to inclusion in the next release. Here’s how: https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines Other Important Dates: October 31 5.beta-1 - Release Candidate 1 November 03-14 Testathon (mark your calendar) November 20 5.beta-2 - Release Candidate 2 December (mid) DSpace 5.0 Release Of course, this also means we have a large pile of pull requests which need review, and other features that have been contributed but should still receive plenty of testing. We’d like to take a moment to call a few of those out, as they represent features we know are important to the community. If any of these features “speak to you” please consider pitching in with the review and testing work. The complete list of pull requests is here: https://github.com/dspace/dspace/pulls Six great new features in DSpace 5 We couldn't choose just 5 great new features in DSpace 5, here's six great features you should take a look at: DS-1461/DSPR#591 Batch Import Items from ZIP through UI https://github.com/dspace/dspace/pull/591 DS-1582/DSPR#629 Metadata for all DSpace objects (not just items) https://github.com/dspace/dspace/pull/629 DS-2061/DSPR#568 Linked Open Data for DSpace https://github.com/dspace/dspace/pull/568 DS-2049/PR#612 ORCID Integration https://github.com/DSpace/DSpace/pull/612 DS-2052/PR#587 Mirage2 Responsive Theme https://github.com/DSpace/DSpace/pull/587 DS-2108/PR#615 Google Analytics Statistics viewer (page views and downloads) https://github.com/DSpace/DSpace/pull/615 There are also many more great proposals for DSpace 5. The status page https://wiki.duraspace.org/display/DSPACE/DSpace+Release+5.0+Status has a full listing of things that we hope would make it in, contributions welcome. Lastly, we are still looking for more people to join the Release Team. Responsibilities include attending weekly developer meetings, reviewing pull requests, and ensuring requests get proper feedback and testing. ________ Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-2052) Mirage 2 Responsive theme for the XMLUI
Title: Message Title Peter Dietz commented on DS-2052 Re: Mirage 2 Responsive theme for the XMLUI I was thinking the cleanest/neatest approach to this would be for it to live in dspace-xmlui/src/main/webapps/themes/mirage2, where all of the other themes live. Instead of DSpace/maven managing all of the dependencies for this theme (bower/sass/etc), it becomes the end-developer to have all of that on their machine. Also, I can see the source and compiled version of this theme living together. i.e. Have mirage2/scripts/(file1.scss, file2.scss, file3.scss) all get compiled to mirage2/scripts/_styles.css, and you version control all of them. With your compiled version of mirage2 living in dspace-xmlui/src/main/webapps/themes/mirage2, the existing deploy process will continue to work fine. Add Comment This message was sent by Atlassian JIRA (v6.2.6#6264-sha1:ee76422) -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1986) REST API holds on to context for too long, should use DB pool
Title: Message Title Peter Dietz updated an issue DSpace / DS-1986 REST API holds on to context for too long, should use DB pool Change By: Peter Dietz Fix Version/s: 4.2 Add Comment This message was sent by Atlassian JIRA (v6.2.6#6264-sha1:ee76422) -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1986) REST API holds on to context for too long, should use DB pool
Title: Message Title Peter Dietz updated an issue DSpace / DS-1986 REST API holds on to context for too long, should use DB pool Change By: Peter Dietz Labels: has-pull-request Add Comment This message was sent by Atlassian JIRA (v6.2.6#6264-sha1:ee76422) -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1986) REST API holds on to context for too long, should use DB pool
Title: Message Title Peter Dietz commented on DS-1986 Re: REST API holds on to context for too long, should use DB pool Adding a Pull-Request to fix the context with REST. https://github.com/DSpace/DSpace/pull/561 The solution: Close the context in the finally after each request, and get a new context in each request. Cheers to [~rrodgers] for this tip during OR2014. Add Comment This message was sent by Atlassian JIRA (v6.2.6#6264-sha1:ee76422) -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1215) Display a default thumbnail if the user does not have permissions to view instead of 301 redirecting the image to a login screen
Title: Message Title Peter Dietz commented on DS-1215 Re: Display a default thumbnail if the user does not have permissions to view instead of 301 redirecting the image to a login screen DS-740 can generate a thumbnail of restricted content that is publicly available, which solves half of the problem. The unsolved half would be if the site chose not to make public thumbnails of restricted content. Then we would have to not attempt to show the restricted thumbnail in XMLUI. Add Comment This message was sent by Atlassian JIRA (v6.2.3#6260-sha1:63ef1d6) -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-740) Allow media filter to set non-default permissions on derivative bitstreams
Title: Message Title Peter Dietz updated an issue DSpace / DS-740 Allow media filter to set non-default permissions on derivative bitstreams Change By: Peter Dietz Status: Volunteer Needed Accepted Add Comment This message was sent by Atlassian JIRA (v6.2.3#6260-sha1:63ef1d6) -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-740) Allow media filter to set non-default permissions on derivative bitstreams
Title: Message Title Peter Dietz assigned an issue to Peter Dietz DSpace / DS-740 Allow media filter to set non-default permissions on derivative bitstreams Change By: Peter Dietz Assignee: Peter Dietz Add Comment This message was sent by Atlassian JIRA (v6.2.3#6260-sha1:63ef1d6) -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-740) Allow media filter to set non-default permissions on derivative bitstreams
Title: Message Title Peter Dietz commented on DS-740 Re: Allow media filter to set non-default permissions on derivative bitstreams I have made a Pull Request to implement this behavior. https://github.com/DSpace/DSpace/pull/543 Basically, I add a config where you whitelist the specific MediaFilter names that you want to make public content. Not listed, inherit parent's policy (i.e. restricted), if you are listed, then get public read. Add Comment This message was sent by Atlassian JIRA (v6.2.3#6260-sha1:63ef1d6) -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1986) REST API holds on to context for too long, should use DB pool
Title: Message Title Peter Dietz commented on an issue Re: REST API holds on to context for too long, should use DB pool So I have solved this by removing the static portion, however I can't commit it because it causes severe performance issues, ie 90% error on jmeter due to db pool/connection mismanagement. I'll sadly stick with stale data for the time being, until I can address db pool performance. Add Comment DSpace / DS-1986 REST API holds on to context for too long, should use DB pool REST API (Jersey), grabs a context, and never frees/returns/releases it. I don't know exactly what is going on, but it causes the REST API to not be able to reflect real-time updates to content. To repeat. Load a DSpace-REST result for some endpoint. Edit the title/name of the first object returned in that result. Reload the REST endpoint. For me, the... This message was sent by Atlassian JIRA (v6.1.7#6163-sha1:94d557d) -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software
[Dspace-devel] [DuraSpace JIRA] (DS-1945) Allow override so helpdesk can receive all Request Copy emails instead of submitter
Title: Message Title Peter Dietz commented on an issue Re: Allow override so helpdesk can receive all Request Copy emails instead of submitter I have played off of [~ottenhoffs]'s Pull Request, and made it use Spring DI for the HelpdeskStrategy. I then cleaned up the UI's to use the DI instead. PR: https://github.com/DSpace/DSpace/pull/530 Add Comment DSpace / DS-1945 Allow override so helpdesk can receive all Request Copy emails instead of submitter Some institutions want the DSpace admininistrator or DSpace helpdesk to receive all Request Copy emails instead of the emails going to the original submitter. The Request copy has two config options right now: request.item.type = all mail.helpdesk = dsp...@myu.eduThis pull request will add a new config option to allow the override. This message was sent by Atlassian JIRA (v6.1.7#6163-sha1:94d557d) -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available
[Dspace-devel] Database Pool - Best practices?
Hi All,
Calling all JDBC pooling experts. So, during the stress-testing of the
REST-API many months ago, I've had jmeter hit REST full throttle for hours,
fixed bugs in REST to support reliability and performance, and now it
supports about a million requests per hour, depending on endpoint.
However, I realized that I was doing something clever, or not-clever
depending on perspective. REST doesn't participate in the database pool
(getting a context, doing its thing, then returning the context at the end
of the method). Instead I had stored a private static copy of the context,
and never return it. Therefore, each endpoint holds its own connection,
doesn't go through the overhead of getting a new context, and doesn't go
through the overhead of closing the connection. This is quicker, but I've
just discovered that it causes rest to not have real-time data, and it
won't work when we add AuthN to rest.
However, most importantly, I don't think that the DatabaseManager /
DataSource / pool / context-stuff, properly supports this level of grabbing
a new connection, and releasing the connection. My jmeter test hits 7
endpoints, full throttle, and never stops.
The current 4.0 version of REST uses "keep connection". It performs well,
0% error, 50-200 requests/per second, about a million per hour. However, by
holding on to a static database connection, it can get
less-than-real-time-data.
if(context == null) {
context = new org.dspace.core.Context();
}
... do your thing
If I change all the endpoints to use the pool, each request grabbing a new
context, does its things, then closes the context, I get 80-100% error rate.
The code for new context / close context looks like:
context = new org.dspace.core.Context();
... do your thing
context.complete();
Errors are of the flavor:
ERROR org.dspace.rest.CommunitiesResource @ This statement has been closed.
ERROR org.dspace.rest.CommunitiesResource @ Cannot get a connection, pool
error Timeout waiting for idle object
So, to me, it looks like the database connection pool isn't working
correctly, or isn't supposed to be used like this.
So, if anyone has any ideas on what can be done, that would be greatly
appreciated. I'm tempted to dig into the DatabaseManager classes of DSpace,
but that is terrifying. I do suspect that proper use of things like JDBC
pools ought to support heavy usage. We are using JDBC 1.4, which is the
latest for Java6, JDBC 2.0 exists and requires Java7. I'm wondering if
perhaps we have a bug in the database manager code that uses a regular
database Connection, and not the PoolableConnection. These details are
beyond me, but a webapp should be able to have a good
internal-dspace-framework to stand upon. I don't know if this is where ORM
or something like jooq would help.
Thanks
Peter Dietz
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1976) "Private" items appear in REST API under their parent collection
Title: Message Title
Peter Dietz updated an issue
DSpace / DS-1976
"Private" items appear in REST API under their parent collection
Change By:
Peter Dietz
Labels:
has-pull-request
Add Comment
This message was sent by Atlassian JIRA (v6.1.7#6163-sha1:94d557d)
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1976) "Private" items appear in REST API under their parent collection
Title: Message Title Peter Dietz commented on an issue Re: "Private" items appear in REST API under their parent collection Has PR: https://github.com/DSpace/DSpace/pull/527 Add Comment DSpace / DS-1976 "Private" items appear in REST API under their parent collection If you mark an item as "private" in the Submission UI or the Admin UI, it is still visible in the browse functions of the REST API. By definition, a "private" item should be hidden from all browse/search interfaces (including REST API). Private items are still potentially accessible via direct URL, but should not be discoverable through REST API, excep... This message was sent by Atlassian JIRA (v6.1.7#6163-sha1:94d557d) -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Dspace-devel mailing list
[Dspace-devel] [DuraSpace JIRA] (DS-1976) "Private" items appear in REST API under their parent collection
Title: Message Title
Peter Dietz updated an issue
DSpace / DS-1976
"Private" items appear in REST API under their parent collection
Change By:
Peter Dietz
Assignee:
Peter Dietz
Status:
Received Accepted
Add Comment
This message was sent by Atlassian JIRA (v6.1.7#6163-sha1:94d557d)
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1976) "Private" items appear in REST API under their parent collection
Title: Message Title Peter Dietz commented on an issue Re: "Private" items appear in REST API under their parent collection Confirmed, the REST API has not respected the unlisted Item flag (isDiscoverable). I actually wasn't aware of the unlisted/"private" Item feature until just recently. I'm working on the fix for this for the REST API, and along the way I've made an org.dspace.content.service.ItemService method isItemListedForUser, that can be used to do the business logic of the check. Add Comment DSpace / DS-1976 "Private" items appear in REST API under their parent collection If you mark an item as "private" in the Submission UI or the Admin UI, it is still visible in the browse functions of the REST API. By definition, a "private" item should be hidden from all browse/search interfaces (including REST API). Private items are still potentially accessible via direct URL, but should not be discoverable through REST API, excep... This message was sent by Atlassian JIRA (v6.1.7#6163-sha1:94d557d) -- Start Your Social Net
[Dspace-devel] [DuraSpace JIRA] (DS-1986) REST API holds on to context for too long, should use DB pool
Title: Message Title Peter Dietz commented on an issue Re: REST API holds on to context for too long, should use DB pool Fixing the unlisted/"private item" bug for REST, helped me to find this context / db connection bug in REST. Add Comment DSpace / DS-1986 REST API holds on to context for too long, should use DB pool REST API (Jersey), grabs a context, and never frees/returns/releases it. I don't know exactly what is going on, but it causes the REST API to not be able to reflect real-time updates to content. To repeat. Load a DSpace-REST result for some endpoint. Edit the title/name of the first object returned in that result. Reload the REST endpoint. For me, the... This message was sent by Atlassian JIRA (v6.1.7#6163-sha1:94d557d) -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Dspace-dev
[Dspace-devel] [DuraSpace JIRA] (DS-1986) REST API holds on to context for too long, should use DB pool
Title: Message Title Peter Dietz created an issue DSpace / DS-1986 REST API holds on to context for too long, should use DB pool Issue Type: Bug Affects Versions: 4.1, 4.0 Assignee: Peter Dietz Components: REST API Created: 27/Apr/14 4:07 AM Priority: Minor Reporter: Peter Dietz REST API (Jersey), grabs a context, and never frees/returns/releases it. I don't know exactly what is going on, but it causes the REST API to not be able to reflect real-time updates to content. To repeat. Load a DSpace-REST result for some endpoint. Edit the title/name of the first object returned in that result. Reload the REST endpoint. For me, the REST response didn't have the updated title/name. Since the typical use-case of DSpace is content that rarely/never changes, this isn't a big deal, but it needs to be resolved. I believe this bug got in during the performance stress-testing process, where after hitting DSpace REST with millions of requests to Communities, Collections, Items, Bitstream over the span of an hour, I had added changes to help REST spend less time dealing with database connections, and instead keep a connection. The better route would be to grab a database connection from the pool, and return the connection back to the pool once the request is complete. I think I/we need to take a look at database connection pool
[Dspace-devel] [DuraSpace JIRA] (DS-1978) "Private Items" are misnamed, as permissions/privacy is not really changed
Title: Message Title Peter Dietz commented on an issue Re: "Private Items" are misnamed, as permissions/privacy is not really changed org.dspace.content.Item.isDiscoverable is the relevant attribute for determining if these Items are to be shown in Item Lists or not. Not that we should have YouTube govern how we proceed with the naming of features in our repository, I imagine that they have gone through plenty of discussion, and settled upon three classifications: - Public (anyone can search for an view) - Unlisted (only those with the link can view) - Private (can only be seen by you and the users you select) Therefore, I'd be happy to call this feature "Unlisted" Items. When I hear the word discoverable, I think it has something to do with a faceted search and browse interface... I'm currently working on making an ItemService method for determining if an Item is able to be shown in an Item list for a user. It has to check for READ permission, and if isDiscoverable=true. The method name in my draft is: isItemListedForUser(context, item), already I have this ready and tested for the REST API, and it should be suitable for the other affected components of DSpace that have to get fixed for unlisted/"private". Add Comment DSpace / DS-1978 "Private Items" are misnamed, as permissions/privacy is not really changed "Private" items are misnamed in DSpace. When you make an item private, it does not change the privacy settings (permissions). Instead, it's really just changing its discoverability settings (ability to find it via Browse/Search). See the definition at: https://wiki.duraspace.org/displa
Re: [Dspace-devel] jspui and xmlui in the long run
Sorry to bump an old thread. XMLUI and JSPUI are quite solid and both provide a complete package as a repository interface, they don't maintain parity and don't have to, but there are interested parties that make the needed investments in each, that I don't see either dissolving in the short term. DSpace today presents a lot of work to build yet-another-user-interface. I think that with the current REST-API this has changed for the frontend end-user browsing experience. There are a few experiments of client apps to the API, and this is where the future of DSpace becomes a bit more interesting. If 99% percent of your traffic is the anonymous end-user, then why not build an application well suited for delivering an experience that delights visitors, and helps expose your content. (API provides read access to public communities, collections, items, and bitstreams) Ruby on Rails client app: http://dspace-rails.herokuapp.com/item/59996 Java Play! client app: http://dspace-rest-client-play.herokuapp.com/item/59996 For the remaining 1% of users, your administrators, editors, submitters, I haven't yet begun work on functionality in the REST-API to support any of their needs, so my first thought would be to leverage one of the existing user interfaces, and just hand the user back to (jsp|xml)ui for the advanced features. This route certainly seems a bit too cutting edge for a casual repository, but once more groundwork has been laid in the API, building a complete UI might not be such a chore. Long response to your question, but I would say there are contributors to both xmlui and jspui, that I see both ui's sticking around for the next few releases. Even once REST-API of the future emerges, jspui and xmlui could be refactored to use/send all data through the rest API. On Oct 9, 2013 5:36 PM, "helix84" wrote: > On Wed, Oct 9, 2013 at 11:23 PM, Claudia Juergen > wrote: > > Meanwhile the community has grown and both UI's are used and developed > not > > in sync but on a more or less equal level. > > > > So, apart from completely new developments, can one assume, that for the > > next couple of releases both UI's will be supported? > > Hi Claudia, > > it definitely seems so. There are both users and commiters who use > both JSPUI and XMLUI and at any point in time, one or the other is > in ahead development in some respects, but overall, both progress > steadily. > > I'm confident this will continue to be so for the next few years and > when someone starting with DSpace asks which one is better, I > recommend them to > 1) choose based on features currently available, if there are some > UI-specific ones they need > 2) if they're going to do more than basic customization, go with the > technology they're most familiar with (JSP vs. XSLT). > > In the future, with Solr and REST API, I foresee that this landscape > will become even more diverse with other UIs (maybe task-specific > ones, not necessarily full-featured) popping up, written in other > popular languages/platforms. > > Regards, > ~~helix84 > > > -- > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1884) REST API output for text/html
Title: Message Title Peter Dietz commented on an issue Re: REST API output for text/html Hi [~helix84], the html display was added at one point, and they currently are mostly useless. Instead of fixing them to make them more useful, I would be in favor of removing output serialization to HTML, its unnecessary, you would otherwise get json or xml, depending on your browsers preferred accept header. If you want to make HTML from the API, it would be better to use a client application, where you can put in your own business logic. One issue with just adding stylesheets is that we'll eventually support authN/authZ in the API, which means the client will need to send secrets in the call, which the stylesheets aren't going to help with. Add Comment DSpace / DS-1884 REST API output for text/html REST API currently responds to requests for text/html, application/xml and application/json. The text/html output: * is very simple, does not correspond to any formal HTML standard * is not created systematically, only by concatenating strings * doesn't contain all the information returned by the other types, therefore it's nearly useless * is the onl... This message was sent by Atlassian JIRA (v6.1
Re: [Dspace-devel] A Tale of Two 'Rome's: dependency confusion
I can't think of a why-not, but I remember adding/using one of the romes for adding iTunes Podcast support to RSS feeds. So, I would test that feature once a change is made. Peter Dietz On Tue, Dec 10, 2013 at 12:27 PM, Mark H. Wood wrote: > dspace-api depends on net.java.dev.rome:rome:1.0.0 and > rometools:rome-modules:1.0 which depends on rometools:rome:1.0. So we > wind up with rome-1.0.jar AND rome-1.0.0.jar in the built kit. > > It looks as though the Rome project moved from java.net to Github > around 1.0 time, that the rometools versions are thus the latest, and > that we should therefore be depending on rometools:rome:1.0 rather than > net.java.dev.rome:rome:1.0.0. That would harmonize with the > transitive dependency and not leave us wondering what the classloader > will do when it finds two rome-*.jar archives. Does anyone know why > we should not change this? > > It's probably not a big problem > > -- > Mark H. Wood, Lead System Programmer mw...@iupui.edu > Machines should not be friendly. Machines should be obedient. > > > -- > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] DSpace and Continuous Delivery (and a tangent on provisioning)?
My deploy process is not quite continuous deployment, but its a script that helps me deploy updates easier, and less human-error-prone than previously. https://gist.github.com/peterdietz/7893272 Essentially its a script that pulls the latest from our git repository. Then does maven package, ant update, and tomcat restart. To provision new servers, its a lot of manual steps, since I've got apache box, tomcat/dspace box, postgres box, and elasticsearch box. Inefficient, definitely, but I'm sure that in the end its correct, and configured how I want it to be. If I can get that through puppet/chef magic, then two thumbs up, but for now, I remain skeptical. Peter Dietz On Tue, Dec 10, 2013 at 10:25 AM, Graham Triggs wrote: > I believe some of the service providers that maintain a number of DSpace > instances have looked into this. > > And it would make sense for our demo server, for us to deploy new versions > as it is developed. That may be true for you if you are doing lots of > active development. > > It's also quite nice to be able to deploy to a staging server, and once > checking that, be able to trust that a live deployment would be successful. > > However, setting up automation can be a very expensive and frustrating > process. Others that have done it, might have more to say, but my feeling > is that it's not really worth it unless you have to do a lot of repeatable > deployments. > > From the sounds of it, in your position I would wonder why I'm having to > set up so many damn boxes :) > > G > > > On 9 December 2013 16:17, Pottinger, Hardy J. wrote: > >> Hi, I'm wondering if anyone in the community has explored using a >> deployment tool, or even better, a continuous delivery tool, for deploying >> DSpace in production? I am researching the possibility of using Go [1] to >> manage code deployment, but I'd love to hear from others in the community >> about what you might be using for deploying DSpace? I do know of one >> institution that uses Capistrano to deploy DSpace. >> >> I'm mostly looking for a tool to give some structure and manageability to >> what code gets deployed where, when and why. >> >> Tangent: as long as I'm asking about the dev side, might as well ask about >> ops. Has anyone out there built a Puppet or Chef recipe for preparing a >> server to run DSpace? Or, more broadly, has anyone scripted the >> installation stage of provisioning a server for DSpace, and if so, would >> you be able to share the script(s)? >> >> I'm very aware that I'm asking for the keys to the kingdom here. :-) I'm >> just in a situation where I'm going to have to re-provision a new "box" >> for running DSpace, and, I'm frankly sick to death of thinking about >> boxes. :-\ >> >> [1] http://www.thoughtworks.com/products/go-continuous-delivery >> >> >> -- >> HARDY POTTINGER >> University of Missouri Library Systems >> http://lso.umsystem.edu/~pottingerhj/ >> https://MOspace.umsystem.edu/ >> "We shall not cease from exploration, and at the end of all our exploring >> will be to arrive where we started and know the place for the first time." >> --T.S. Eliot >> >> >> >> >> >> >> >> >> -- >> Sponsored by Intel(R) XDK >> Develop, test and display web and hybrid apps with a single code base. >> Download it for free now! >> >> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk >> ___ >> Dspace-devel mailing list >> Dspace-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dspace-devel >> > > > > -- > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] current hardware recommendations for DSpace?
I don't know if we want this thread to turn into a show and tell, but our stack is: PROD - vm for Apache - vm for Tomcat (DSpace) - vm for Postgres - vm for Elastic Search And then repeat that two more times, with a complete replica of the stack for Staging, and for Development. Development is actually done on my laptop though. The total for us is 12 vm's. But its shared among our IT/App groups, and other things use the prod/staging/dev apache, postgres, and elasticsearch. When we run into growing pains, our first response is to just scale vertically, and add more memory and another CPU, and that usually suffices for us. Elastic Search supports clustering natively, we haven't looked into Postgres replication/pooling yet, and for Apache we are considering things like HA-Proxy, but for now we suffice. I haven't looked into such things as a load balanced DSpace/tomcat. I'm not sure I understand all of the requirements of that, regarding data, and sessions. If you've got a light-weight use case, then a spare Dell box under someone's desk has worked for us in the past, atleast to spin up a dedicated dev-box for someone. Peter Dietz On Tue, Nov 19, 2013 at 4:16 AM, TAYLOR Robin wrote: > Hi Hardy, > > I am a little wary about recommending hardware, there are so many > different use cases for DSpace out there. I was once contacted by an > architects office that just wanted somewhere to store their drawings. The > danger is that someone considering DSpace may conclude that our > recommendation is the minimum requirement, when their use case would > require something more lightweight. In some cases a PC in the corner of > the room with some backup facility might be sufficient. > > Cheers, Robin. > > > On 18/11/2013 20:24, "Pottinger, Hardy J." > wrote: > > >Hi, I have been asking around privately for hardware recommendations for > >running DSpace in production, and I noticed we have an old page of advice > >here: > > > >https://wiki.duraspace.org/display/DSPACE/EndUserFaq > > > > > >We should probably have a page of hardware advice for production DSpace on > >the "official" DSpace wiki (that End User FAQ page isn't quite there). > >>From all my asking around, here's what I've come up with for production: > > > >First, there's a question of approach. Most of the people I asked were > >running PostgreSQL on a separate machine (DB tuning and troubleshooting is > >not the same thing as Tomcat tuning and troubleshooting). > > > >So, if one is running an application stack on one machine, and a DB on > >another machine, the specs for those machines would be different than an > >"everything on one box" approach. Everything on one box is appropriate for > >a staging/development server (which would have smaller requirements than > >production). I've got a pretty good idea of what to recommend for the > >application stack box and DB box, so I'll include those specs below. But, > >if you have another suggestion, I'd love to hear about it. > > > >Three-box approach to DSpace > > > >Production Application Box: > >4 CPU, 4GB of RAM, and with the following stack set up (note some of this > >is specific to our environment): > >Java 7 (OpenJDK is fine) > >Tomcat 7 > >Ant 1.8.2 or higher > >Maven3 (3.0.4 or higher) > >Shibboleth SP 2.5 or higher (optional) > >Apache 2.0 (optional) > >PHP 5.3.3 (optional) > >As much storage as you need for your production bitstream content (very > >environment-specific, external SAN storage recommended) > > > >Production DB Box: > >1 CPU, 2GB of RAM > >With this software installed: > >PostgreSQL server > > > >As much storage as you need for a DB, probably the default space for your > >VM will be sufficient. > > > > > >Staging Box (everything on one box): > >2 CPU, 2GB of RAM, and with the following stack set up (note some of this > >is specific to our environment): > >Java 7 (OpenJDK is fine) > >Tomcat 7 > >Ant 1.8.2 or higher > >Maven3 (3.0.4 or higher) > >Shibboleth SP 2.5 or higher (optional) > >Apache 2.0 (optional) > >PHP 5.3.3 (optional) > >PostgreSQL server > > > >As much storage as you need for your staging and development bitstream > >content (very environment-specific, external SAN storage recommended) > > > > > > > >-- > >HARDY POTTINGER > >University of Missouri Library Systems > >http://lso.umsystem.edu/~pottingerhj/ > >https://MOspace.umsystem.edu/ > >"We shall not cease from exploration, and at the end of all
Re: [Dspace-devel] Instance-local object identifiers for REST and other uses [was Re: A few early REST API comments]
Example: http://demo.dspace.org/rest/handle/10673/1?expand=all
Peter Dietz
On Fri, Nov 15, 2013 at 12:00 PM, Peter Dietz wrote:
> Sorry, but the current REST API does support lookup by handles.
> https://github.com/DSpace/DSpace/tree/master/dspace-rest#handles
>
>
> https://github.com/DSpace/DSpace/blob/master/dspace-rest/src/main/java/org/dspace/rest/HandleResource.java#L32
>
>
> @Path("/handle")
> public class HandleResource {
>
> @GET
> @Path("/{prefix}/{suffix}")
>
> @Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
>
> public org.dspace.rest.common.DSpaceObject getObject(@PathParam("prefix")
> String prefix, @PathParam("suffix") String suffix, @QueryParam("expand")
> String expand) {
>
>
> It should work just-as-well as looking it up by DB-id. With the exception
> that we haven't added the pagination params to the Handle lookup. The
> handle returns either 404, or an object of the type as the found DSO, i.e.
> ,
>
> Peter Dietz
>
>
> On Fri, Nov 15, 2013 at 11:36 AM, Anja Le Blanc <
> anja.lebl...@manchester.ac.uk> wrote:
>
>> It is very easy to make the REST API understand handles. I have done it
>> for items locally already. At the moment it is in addition to database
>> ids, but I would be happy for DB ids to disappear from view completely.
>>
>> Best regards,
>> Anja
>>
>> On 15/11/2013 16:08, Tim Donohue wrote:
>> > Hi Mark,
>> >
>> > On 11/13/2013 12:06 PM, Mark H. Wood wrote:
>> >> I had missed that we were hurrying to do something in 4.0. I had
>> >> assumed that there wasn't time.
>> >
>> > To clarify, I was not recommending we change identifier schemes in 4.0.
>> >
>> > As Graham mentions, all I was recommending is that we stay *consistent*
>> > with our current identifier scheme.
>> >
>> > So, the only change I recommend for 4.0 is to change the REST-API to
>> > accept Handles ([prefix]/[suffix]) as the identifier. Currently the
>> > REST-API only works with Database IDs.
>> >
>> > As noted earlier in this thread, using Database IDs for the REST API has
>> > several limitations:
>> >
>> > (1) Database ID is not very easily "discoverable" to end users. So, if a
>> > user wanted to access this item from the REST API:
>> >
>> > http://demo.dspace.org/xmlui/handle/10673/3
>> >
>> > How would they be able to determine that it is actually available at:
>> >
>> > http://demo.dspace.org/rest/items/2
>> >
>> > (The same goes for specific Communities/Collections -- the ID from REST
>> > is almost always going to be different from the Handle ID)
>> >
>> > (2) As mentioned previously, Database IDs are slightly more fragile than
>> > Handles currently -- e.g. they cannot be restored by AIP backup &
>> restore.
>> >
>> > I hope this makes some sense. All I'm recommending for 4.0 is that we
>> > tweak the REST API to understand Handles (either instead of or in
>> > addition to Database IDs). For 5.0, we should investigate a better
>> > resolution for https://jira.duraspace.org/browse/DS-1782 (and related
>> > issues)
>> >
>> > - Tim
>> >
>> >
>> --
>> > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
>> > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
>> > Free app hosting. Or install the open source package on any LAMP server.
>> > Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
>> > ___
>> > Dspace-devel mailing list
>> > Dspace-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/dspace-devel
>> >
>> >
>>
>>
>> --
>> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
>> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
>> Free app hosting. Or install the open source package on any LAMP server.
>> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
>> ___
>> Dspace-devel mailing list
>> Dspace-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>>
>
>
--
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] Instance-local object identifiers for REST and other uses [was Re: A few early REST API comments]
Sorry, but the current REST API does support lookup by handles.
https://github.com/DSpace/DSpace/tree/master/dspace-rest#handles
https://github.com/DSpace/DSpace/blob/master/dspace-rest/src/main/java/org/dspace/rest/HandleResource.java#L32
@Path("/handle")
public class HandleResource {
@GET
@Path("/{prefix}/{suffix}")
@Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
public org.dspace.rest.common.DSpaceObject
getObject(@PathParam("prefix") String prefix, @PathParam("suffix")
String suffix, @QueryParam("expand") String expand) {
It should work just-as-well as looking it up by DB-id. With the exception
that we haven't added the pagination params to the Handle lookup. The
handle returns either 404, or an object of the type as the found DSO, i.e.
,
Peter Dietz
On Fri, Nov 15, 2013 at 11:36 AM, Anja Le Blanc <
anja.lebl...@manchester.ac.uk> wrote:
> It is very easy to make the REST API understand handles. I have done it
> for items locally already. At the moment it is in addition to database
> ids, but I would be happy for DB ids to disappear from view completely.
>
> Best regards,
> Anja
>
> On 15/11/2013 16:08, Tim Donohue wrote:
> > Hi Mark,
> >
> > On 11/13/2013 12:06 PM, Mark H. Wood wrote:
> >> I had missed that we were hurrying to do something in 4.0. I had
> >> assumed that there wasn't time.
> >
> > To clarify, I was not recommending we change identifier schemes in 4.0.
> >
> > As Graham mentions, all I was recommending is that we stay *consistent*
> > with our current identifier scheme.
> >
> > So, the only change I recommend for 4.0 is to change the REST-API to
> > accept Handles ([prefix]/[suffix]) as the identifier. Currently the
> > REST-API only works with Database IDs.
> >
> > As noted earlier in this thread, using Database IDs for the REST API has
> > several limitations:
> >
> > (1) Database ID is not very easily "discoverable" to end users. So, if a
> > user wanted to access this item from the REST API:
> >
> > http://demo.dspace.org/xmlui/handle/10673/3
> >
> > How would they be able to determine that it is actually available at:
> >
> > http://demo.dspace.org/rest/items/2
> >
> > (The same goes for specific Communities/Collections -- the ID from REST
> > is almost always going to be different from the Handle ID)
> >
> > (2) As mentioned previously, Database IDs are slightly more fragile than
> > Handles currently -- e.g. they cannot be restored by AIP backup &
> restore.
> >
> > I hope this makes some sense. All I'm recommending for 4.0 is that we
> > tweak the REST API to understand Handles (either instead of or in
> > addition to Database IDs). For 5.0, we should investigate a better
> > resolution for https://jira.duraspace.org/browse/DS-1782 (and related
> > issues)
> >
> > - Tim
> >
> >
> --
> > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> > Free app hosting. Or install the open source package on any LAMP server.
> > Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> > ___
> > Dspace-devel mailing list
> > Dspace-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/dspace-devel
> >
> >
>
>
> --
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> ___
> Dspace-devel mailing list
> Dspace-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
--
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] A few early REST API comments
I don't think I'm able to see too far into the future on this (or any) API.
I see it as more a means to an end. This new machine interface will be a
pleasant way to get data out of your repository, repurposed into other
systems. Clients of the API should expect a stable interface for a period
of time, that they can build applications/uses against. I'm not envisioning
long-term-persistent API, but if you know what your looking for, it will
give you a way to use it.
A quick-win (not quick enough for 4.0) would be to introduce some type of
UUID on objects. They should be some type of globally-unique ID, I don't
see this being used for citation purposes, but if a collection, and its
content were moved from one repository to another, if it could retain this
UUID, and you can keep referencing the same identifier. Overcoming the DB
incremented entity ID, and not binding yourself to an overloaded handle.
Then regarding the entity vs entity-lists. I think the route that I'm
currently on _could_ be a bit bloated, where you request a specific
community, and you can also bring along its child-collections, and
child-communities. It might be cleaner / more-restful to move that
expansion, or just provide some syntax sugar to ask for a more restful
expansion, i.e. /communities/123/collections and
/communities/123/communities and /communities/123/items. Such that the
"communities/" returns a entity-list, i.e. community list,
"communities/123" returns a singular entity i.e. community, and so on down
the line.
I haven't touched the REST API for the past week to let some of the dust
settle, but I am in favor of wrapping responses, and including the request
context, so that regarding pagination, you have enough state/hints to know
how far you can paginate to. We do have limit and offset present currently,
so you can form your own pages.
Peter Dietz
On Fri, Nov 8, 2013 at 10:49 AM, Richard Rodgers wrote:
> Hi Mark:
>
> Thanks for the thoughtful response.
> The point about handles was not intended to enshrine that particular ID
> system;
> I meant it as illustrative ("persistent IDs, _such as_ handles"). I
> certainly agree that
> a REST API should not enforce any particular scheme, and we have made some
> headway in abstracting identification services in the platform.
> If your persistent ID of choice is something else, the the REST API should
> expose it.
>
> Whether the use of Handles is appropriate (if that's your ID system) in
> this context,
> or whether DSpace needs a new persistent ID system with the
> characteristics you outline is more debatable I think,
> and raises many thorny questions (if only locally unique, how can content
> stewardship be transferred without collisions?, etc)
> that are quite important, but I think to some degree orthogonal to the
> REST API design features I was trying to point out.
>
> But point definitely taken, and I'll try to use more neutral descriptions
> (PID maybe?), which I agree is the issue at hand here.
>
> Richard R.
>
>
> On Nov 8, 2013, at 9:51 AM, Mark H. Wood wrote:
>
> > I want to look over this posting more carefully, but I did want to get
> > one thought out quickly. Please, let's not overload Handles even
> > more. There are sites, I've heard, that would like to do away with
> > Handles and use something else for durable universally-unique external
> > identifiers. That's hard to do if we wire Handles into everything.
> >
> > What we want, it seems to me, is an additional durable identifier
> > which requires only local uniqueness and has *no meaning* in
> > isolation. The last property excludes Handles and DB IDs alike. What
> > this means is that we need, probably, just a simple serial number
> > facility, which is used to name every object created. These names are
> > not used internally by DSpace (as DB IDs are); they exist solely for
> > users to identify "that object you mentioned before".
> >
> > This way, those names can be permanent (unlike DB IDs), don't tie us
> > to specific external services (like Handles), and can't tie us down to
> > specific internal organization (like either).
> >
> > --
> > Mark H. Wood, Lead System Programmer mw...@iupui.edu
> > Machines should not be friendly. Machines should be obedient.
> >
> >
> --
> > November Webinars for C, C++, Fortran Developers
> > Accelerate application performance with scalable programming models.
> Explore
> > techniques for threading, error checking, porting, and tuning. Get
Re: [Dspace-devel] DSpace REST API
Hi Kostas,
Thanks for drawing attention to this, I would love the developer community
to give input on this, so that we end up with a more acceptable product. I
would say the current status of the REST API is acceptable, and certainly
gives us the ability to do new things with DSpace. Its some of these finer
points that we will want to address so that we don't cause unnecessary
surprises, once this gets widely adopted. I think we still have time before
4.0 FINAL to make these final tweaks.
1) Versioning
I've been worrying about versioning for some time, and I'm mostly worried
that future updates to DSpace / DSpace-REST-API, when cause issues for
clients, so, versioning should be seen as mandatory. (i.e. This client was
designed to use v1.)
I'm in the school of thought that the version lives in the URI, and its on
the left-hand side of the base URI.
i.e. /rest/*v1*/collections, or /rest/*v2*/collections
Because I'm thinking that a future DSpace-REST could be reimplemented in
any technology, so requests to the old version, can be sent to an old
webapp still running. Or, you would have to build backwards compatibility
into new REST v2 webapp. Doing this at URI path, gives you plenty of tricks
to deal with it. Doing this in Headers, limits you to building a v2, that
can also speak v1.
Also, I'm thinking about weak/simple clients. i.e. single javascript file
that will embed a few Items on another site. They can set the URL, I'm
doubtful they will have very strong ability to customize every header.
Code to support multiple versions inside the API might look like:
@Path("/v1/myresource")
public class MyResource
@Path("/v2/myresource")
public class MyResourceV2
2) Response
I've been reviewing Anja's PR that includes a "context", such as
limit/offset/total-count. And I think it's also wrapping the response
objects in some type of named container.
https://github.com/peterdietz/DSpace/pull/2
I'm still reviewing it. The master-merge things cause some grief, but
there's plenty of good improvements in there.
2.iii) General / Template parsing.
For a moment I didn't return a collection, community, item, or bitstream
object, but it was instead the vanilla base-class of DSpaceObject. I like
the response to have the output object be wrapped in a "collection" or
"collections" object.
I'm not thinking of making anything like a WSDL. But we'll document the
format of the API when the release is final for 4.0, and then when 5.0 is
out, I'm guessing we'll have a REST v2 format emerging. When REST v2 is
ready we'll document the response objects. It might not kill us to create
some example code (I've got the Java Play! client app, and you've built
some ObjC iOS code). An SDK at some point might be useful, but I don't want
to get too far ahead of myself. I'm thinking something like that for Rails
or Javascript would be welcomed.
3) Better Error Messages
I would like to see friendly error messages, in some type of response
object. Throwing the HTTP status code is minimally acceptable, but an
"error" object, that said what went wrong, and not throwing a stack-trace
is definitely better. PR's wanted.
Peter Dietz
On Mon, Nov 4, 2013 at 4:52 AM, Andrea Bollini wrote:
> Hi Kostas,
> here my viewpoint
> 1) I prefer the header method. A missing header should be read as the
> current version.
> 2) I agree with you. It is usually to find a common template across REST
> API implementation and we should follow the "common practice"
> 3) Detailed errors information are desirable so also in this case, I agree
> with you about the opportunity to introduce a response error object
>
> Andrea
>
> Il 04/11/2013 10.13, Kostas Stamatis ha scritto:
>
> Dear developers,
>
>
>
> I have some comments, regarding the Jersey Rest API, after a discussion we
> had with Peter Dietz in the “dspace” IRC channel some days ago.
>
>
>
>
>
> 1) REST API versioning
>
> ---
>
> As read from some sites and blogs, the versioning of a REST API can be
> denoted either in the URL or in the mime type of the HTTP communication (in
> the ”Accept” and “Content-Type” header fields).
>
> ex1: http://example.dspace.com/rest/v1/communities
>
> ex2:
>
> ===>
>
> GET /communities HTTP/1.1
>
> Accept: application/vnd.dspace.rest-v1+json
>
> <===
>
> HTTP/1.1 200 OK
>
> Content-Type: application/vnd.dspace.rest-v1+json
>
>
>
> Either has advantages and disadvantages, as I read. For example, the
> former is said to be wrong since the same resource may have more than one
> URIs pointing to it. The latter helps the backward compatibility. From what
> I read, I think that most prefe
[Dspace-devel] [DuraSpace JIRA] (DS-1696) DSpace REST API built in JERSEY
Title: Message Title Peter Dietz commented on an issue Re: DSpace REST API built in JERSEY Documentation for DSpace 4.0 REST API can be found at: https://wiki.duraspace.org/display/DSDOC4x/REST+API Add Comment DSpace / DS-1696 DSpace REST API built in JERSEY Pull request https://github.com/DSpace/DSpace/pull/323 This message was sent by Atlassian JIRA (v6.1.1#6155-sha1:7188aee) -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1657) Adopt/Create an official DSpace REST API
Title: Message Title Peter Dietz commented on an issue Re: Adopt/Create an official DSpace REST API For the record. DS-1696 (JERSEY), has received positive approval by committers, and the 4.0 Release Team, and was merged in. Documentation for the DSpace 4.0 REST API can be found at: https://wiki.duraspace.org/display/DSDOC4x/REST+API There is still some work to do to improve the JERSEY API overall, but it brings a good foundation, and meets the requirements laid out in this ticket (READ-ONLY access to public (non-restricted) information in your DSpace instance. Add Comment DSpace / DS-1657 Adopt/Create an official DSpace REST API As has been discussed many times, DSpace needs a REST API. Based on discussions in the Developer Meeting on Sept 18, 2013 (http://irclogs.duraspace.org/index.php?date=2013-09-18 ), the DSpace Committers have come up with a loose set of requirements around what we need out of a REST API. Requirements for REST API inclusion: 1. A read-only API is acc... This message was sent by Atlassian JIRA (v6.1.1#6155-sha1:7188aee
[Dspace-devel] [DuraSpace JIRA] (DS-1731) Add config option to "Elastic Search" to define which group has statistics viewing privleges
Title: Message Title Peter Dietz commented on an issue Re: Add config option to "Elastic Search" to define which group has statistics viewing privleges Hi Hilton, Not being able to configure the group-name for the limited-access to viewing ES statistics (i.e. statistics_viewer) was an oversight of mine. https://github.com/DSpace/DSpace/blob/c43c224eda972dc8d356ef844dcaa9ebf4c38653/dspace-xmlui/src/main/java/org/dspace/app/xmlui/aspect/statisticsElasticSearch/SpecifiedGroupAuthenticatedSelector.java#L28 private String SPECIFIED_GROUP = "statistics_viewer"; Add Comment DSpace / DS-1731 Add config option to "Elastic Search" to define which group has statistics viewing privleges Add an option in "Elastic Search" config to define which group has statistics viewing privileges. This message was sent by Atlassian JIRA (v6.1.1#6155-sha1:7188aee) -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practice
[Dspace-devel] [DuraSpace JIRA] (DS-1748) Add a config option to "dspace.cfg" to enable the "Elastic Search" event listener, similar to enabling the "Discovery" listener.
Title: Message Title Peter Dietz commented on an issue Re: Add a config option to "dspace.cfg" to enable the "Elastic Search" event listener, similar to enabling the "Discovery" listener. Hi Hilton, I think that due to the way Spring works, each web-app has to define which Event Listeners are active. Thus, the documentation states that to enable Elastic Search Usage-Event-Listener, uncomment the ElasticSearch bean in dspace-xmlui/.../applicationContext.xml I'm not familiar with Spring-Magic enough to somehow globally enable an event listener. Add Comment DSpace / DS-1748 Add a config option to "dspace.cfg" to enable the "Elastic Search" event listener, similar to enabling the "Discovery" listener. Add a config option to "dspace.cfg" to enable the "Elastic Search" event listener, similar to enabling the "Discovery" listener. This message was sent by Atlassian JIRA (v6.1.1#6155-sha1:7188aee) -- Android is increasing in popularity, but the open development platform that develo
[Dspace-devel] [DuraSpace JIRA] (DS-1719) JERSEY based REST does not report statistics
Title: Message Title Peter Dietz closed an issue as Fixed Anja added the improvements, and I merged it in. https://github.com/DSpace/DSpace/commit/eb1902ae7faaa23a7d1eb5cca6d836dd1a250f8c DSpace / DS-1719 JERSEY based REST does not report statistics Change By: Peter Dietz Resolution: Fixed Status: Accepted Closed Add Comment This message was sent by Atlassian JIRA (v6.1.1#6155-sha1:7188aee) -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-552) Servlet to deliver repository size statistics
Title: Message Title Peter Dietz commented on an issue Re: Servlet to deliver repository size statistics I've implemented this on Ohio State's instance. I've divided the bytes by (1024*1024*1024) to work around the too-big for int problem. Our code is at: https://github.com/osulibraries/DSpace/blob/osukb/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/aspect/dashboard/ContentStatistics.java Example use in production: https://kb.osu.edu/dspace/content-statistics (Its slow loading). 189 1475 54188 118424 111867 86495 8907 mhwood and I were discussing this in #dspace, and we determined that stuffing this in REST might not be a bad idea, and we found this advice: https://blog.apigee.com/detail/restful_api_design_what_about_counts -- Say, you want a count of all of some resource (scoped based on whatever the requester has access to). -- /dogs/count -- In this way, you think about "count" as a reserved word. Thus, this might fit into REST at endpoints: /communities/count, /collections/count, /items/count, /bitstreams/count, /bitstreams/size?unit=GB, /bitstreams/count?mimetype=image*, /bitstreams/size?unit=GB&mimetype=image* The DB logic couldn't reside in rest though, it would have to move to dspace-api. Add Comment DSpace / DS-552 Servlet to deliver repository size statistics A tiny servlet to return counts of bitstreams, items, collections, and communities, and the amount of storage occupied. The attached patch also maps it into both JSPUI and XMLUI at /content-statistics. The returned "page" is an XML document. For now, see the package.html changes in the patch. I'll up
[Dspace-devel] [DuraSpace JIRA] (DS-1475) Improvement of Collection Dropdown
Peter Dietz assigned DS-1475 to Peter Dietz Improvement of Collection Dropdown Change By: Peter Dietz (08/Oct/13 12:05 PM) Assignee: Ivan Masár Peter Dietz This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1475) Improvement of Collection Dropdown
Peter Dietz commented on DS-1475 Improvement of Collection Dropdown Not sure where to leave a review.. But I'm thinking that instead of having dividers within the text, you have the UI render it more meaningfully, such as with HTML optgroup. http://www.w3schools.com/tags/tag_optgroup.asp (My understanding of) PR#324's way: - German Cars - Audi - German Cars - Mercedes - Swedish Cars - Saab - Swedish Cars - Volvo OPTGROUP way: German Cars - Audi - Mercedes Swedish Cars - Saab - Volvo (In the example, country is community, and manufacturer is the collection). (This might be a new Jira ticket), but lastly, I have made some performance improvements for loading that list, the gist of which can be seen at: https://github.com/osulibraries/DSpace/commit/61039c5572f29283127bc6e4fa1d1f729440d63d#diff-1 Current implementation is to get all collections in the site, and then one-by-one compare the current user to see if they have submit powers. My algorithm, says, get all permissions for submit that the user has, and then add those collections to a list. If you have *A LOT* of collections like my site 2000 collections, the speed up takes you from 30 second load to 1 second load. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] call for REST API candidates for inclusion into DSpace 4.0
Hi All, I have submitted a Pull Request for the JERSEY based implementation I have been working on: https://github.com/DSpace/DSpace/pull/323 I would appreciate review, feedback, and ways to incorporate more features and improvements into it. Peter Dietz On Fri, Sep 20, 2013 at 11:10 AM, Anja Le Blanc < anja.lebl...@manchester.ac.uk> wrote: > Hi Helix, > > > I see you didn't include the Wijiti and Jorum guys in CC, I'm adding > > them again to keep them in loop because I'm not sure if they're on > > dspace-devel. > > Yes, pressed the wrong reply button :-( > Ben is certainly on the dspace-devel list, so I took him out. > > > Sorry, I probably wasn't completely clear. The commiters agreed on > > high-level requirements the API should have (listed in my first email > > in this thread) so that we can consider it for merging. We didn't > > discuss the "syntax" of the API (endpoints, parameters, formats). > > Yes, I missunderstood that bit. Somehow your high level requirements not > even contain 'it must do something' ;-) > > > These are great observations, Anja. The perfect place for them would > > be the REST API review page [1], so please put them there. > > Will do. > > > I'd put > > them there myself, I just have some questions for clarification: > > > >> * They both are based on the same underlying technology (Sakai > entitybus) - > >> which in my opinion makes it pretty hard to do any developments with > them. > >> * They both use database ids rather than handles -- we changed that > locally > > > > I think database IDs are the right choice at this time. The general > > trend lately has been to abstract external identifiers (so that we can > > have DOI or NBN or whatever instead), therefore we don't want to be > > dependent on handles internally. > > For our use case the user might be redirected from the > http://hdl.handle.net/ and should end up in our Rubi based web site > viewing the item. Wherefore we would need at least a method which > translates between handles and database ids. > Actually our REST takes both db ids and handles - if it has two parts it > is an handle otherwise db id. > > >> * Hedtek does not have any kind of authentication, which would not be > >> suitable for places with restricted access. Wijiti seems to want a user > name > >> password for everything (I am not completely positive of whether this is > >> true for a clean fresh checkout of the code.) But username passwords are > >> transmitted in the header or as part of the request. > > > > Could you please verify that in the original code? It seems we've been > > assuming Wijiti doesn't support authZ. > > We are on 1.8, so I used the 1.8.1 branch and it certainly want's > username password for everything. But I seem to have done something > wrong, even with correct credentials I always get 403. I assume the > communication with the DSpace core did not work. > (https://jspace.atlassian.net/wiki/display/DSPACEAPI/API+Documentation) > stats too that they use authentication/authorization. > > >> * For people who have to report on the usage of their repository, you > have > >> to note that neither API submits usage stats to solr (or anywhere else) > >> * For the Hedtek API not all the endpoints are implemented which are > >> 'advertised' (i.e. search and I have only looked at the once we wanted > to > >> use) > >> For a service environment I think Hedtek would be the safer choice > (except > >> for possibly bringing down the service) as there is no way for it to > modify > >> content of the repository. > > > > "bringing down service" - so it's in Hedtek's case that listing all > > items can crash Tomcat? Or did I misunderstand? > > They both do. I just tried on our staging server :-( > java.lang.OutOfMemoryError: Java heap space > java.util.Arrays.copyOfRange(Arrays.java:3221) > > Both APIs need more testing than I have done > i.e. (wijiti) > http://.../rest/communities.xml?user=x...@xxx.de&pass=yyy > works, but > http://../rest/communities/12.xml?user=x...@xxx.de&pass=yyy > returns a 403 Bad username or password > which is the wrong error message and documenation suggests that this > ought to have worked. > > > By the way, one of the guys behind the two implementations said you > > (as in the REST API "working group") never contacted them with any > > co
[Dspace-devel] [DuraSpace JIRA] (DS-1657) Adopt/Create an official DSpace REST API
Peter Dietz commented on DS-1657 Adopt/Create an official DSpace REST API I have submitted a Pull Request for a JERSEY based implementation at: https://github.com/DSpace/DSpace/pull/323 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] De-support Tomcat 5.5 in DSpace 4.0?
Our instances are on boxes that have been running as-is since 2008, thus Tomcat 5.5. I'm fine with the future DSpace release to migrate to the next standard servlet version. We're in the process of infrastructure migration, so us moving to the latest tomcat would be our plan too. So, +1 with kicking out old tomcat dependencies. Peter Dietz On Fri, Aug 2, 2013 at 3:01 PM, Mark H. Wood wrote: > On Fri, Jun 07, 2013 at 02:14:59PM -0400, Mark H. Wood wrote: > > Java EE 7 is released. Tomcat 8 will therefor be coming along > > sometime soon. Meaning that Tomcat 5.5 will reach EOL soon. > > I understand that voting on Tomcat 8 RC1 has commenced. > > -- > Mark H. Wood, Lead System Programmer mw...@iupui.edu > Machines should not be friendly. Machines should be obedient. > > > -- > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] REST API merged into DSpace 3.x
Hi Michael, Thanks for this! Our plan has been to mention this Wijiti version, and encourage people to begin or continue trying it. I know of several groups that are already using a combination of this and/or the Hedtek version to power their production DSpace instances or portions of their site. Today's REST-API discussion at OR2013 will focus more on use-cases, and thinking about how people are already using the "3rd party" REST API's, i.e. - User Interface replacement/alternative - or those who want to provide the ability to make javascript widgets for researchers to embed on their departmental website. So, some discussion is on endpoints that are one-to-one with DSpaceObjects, or endpoints that abstract some of the information to help solve the intent of the external developer, of surfacing works, authors, subjects, departments, files. Those of us here aren't concretely sure which direction, so we're happy to bring in input from everyone with interest. In terms of what will "ship" with DSpace 4.0, this group isn't that group to decide. I would say that it would take a heroic effort to build a new REST API from scratch and for it to be ready in time (i.e. Jersey / Restlet), since that deadline is the next few months. One consideration might be to agree to a "contract" of URI endpoint structure, data objects/structure, and parameter structure. Separately, I'd like to be able to version the api, so that we have a v1 in place in the near future, and perhaps have room for the implementation to evolve and improve as we get more eyeballs on it. The only thing I'll add about my thinking in terms of alternative implementations, such as Jersey, is just that they are the standard in the Java API world, so you get a lot for free, and easier learning/support curve. There is no implementation for DSpace built yet, so we can't really advocate using that yet. Peter Dietz On Thu, Jul 11, 2013 at 1:01 PM, Michael Guthrie wrote: > Hi All again > > Hot on the heels of the 3.x merge of the REST API into DSpace, we have > released a 1.8.x version as well. > > http://bitly.com/Q12Xgp > > Hope this helps the discussion today > > Cheers > > Michael > > > On 11 July 2013 06:41, Michael Guthrie wrote: > >> Hi All >> We couldn't be there for the OR2013 conference but for the panel session >> on REST API today, there is a version now of DSpace that has had the REST >> API merged into the core, allowing for deployment without the extra module, >> and thought this might add to the discussion. >> >> http://bitly.com/Q12Xgp >> >> We hope to have 1.8.x done soon. >> >> You can see it in production at Monash University's Pharmacy faculty: >> http://saber.monash.edu/discover/ >> >> It is using a REST client in Joomla, and also incorporates Jomsocial to >> build a community around the repository and commenting and rating. >> >> Have fun, >> >> >> Michael >> > > > > -- > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] In installation guide, the user "dspace" is confusing
I'm in favor of that, its much simpler. Peter Dietz On Tue, Jul 2, 2013 at 10:40 AM, Mark H. Wood wrote: > I'd like to take out the whole notion of creating a user "dspace" and > let the Tomcat installation drive this aspect. People trip over this > again and again, sometimes getting into quite a mess before seeking > help. > > Really, the step-by-step instructions are incorrect. Step 1 is > "create the DSpace user" and shows you how to create a user named > "dspace". But the procedure assumes that Tomcat is already installed > (see step 8), so the user used to run Tomcat is already created. > > Further, a lot of sites will probably just use their distro's package > manager to install Tomcat, and that will create a user for it without > regard to DSpace, probably naming it "tomcat". > > I think we should be advising people to find out what account Tomcat > uses, and chown the DSpace files to that. Having the tail wag the > 'cat is too confusing. > > -- > Mark H. Wood, Lead System Programmer mw...@iupui.edu > Machines should not be friendly. Machines should be obedient. > > > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-790) SOLR - Spider detection to match on hostname or useragent
[ https://jira.duraspace.org/browse/DS-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28426#comment-28426 ] Peter Dietz commented on DS-790: Hey [~bram], are you aware of any such lists that detect users based on DNS/hostname? I'm thinking that UserAgent is a great way, and I'm working on adding support for this (for ElasticSearch stats). But I would need some patterns to match against for hostnames. I guess IP addresses would work too, but less preferred. > SOLR - Spider detection to match on hostname or useragent > - > > Key: DS-790 > URL: https://jira.duraspace.org/browse/DS-790 > Project: DSpace > Issue Type: Improvement > Components: Solr >Affects Versions: 1.6.0, 1.6.1, 1.6.2, 1.7.0 > Environment: solr >Reporter: Peter Dietz >Assignee: Mark H. Wood > Labels: has-pull-request > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > Spiders are currently detected by matching their IP address to one listed in > the /dspace/config/spiders/ip-list-X.txt, however as spiders change IP > addresses, or the ip-list is unmaintained, then many spiders can slip > through, however they will usually keep their user agent or hostname intact. > I've noticed a sore point in my solr data, where msnbot is completely > unfiltered by solr. They have an additional ip list: > http://www.iplists.com/nw/msn.txt however it is very old, and with additional > bingbots on the horizon, it would be easier to detect, and filter them out of > the logs by user-agent, then to maintain all of the IP address ranges. The > code to do this in SOLR is unimplemented, and this ticket is a place holder > to encourage this work to filter out based on user agent / dns-hostname to be > finished. > To see all of the hits from msnbot that are unfiltered, look at: > http://localhost:8080/solr/statistics/select?q=dns:msnbot*&facet=true&facet.field=dns&facet.mincount=1&facet.limit=5000 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] Moving On
Good luck Scott! I hope you enjoy the new work your doing. You've certainly made sizable, meaningful contributions to DSpace in your time on this project, most specifically with XMLUI, so we thank you for that. We'll be sure to carry on this spirit of change and improvements for the better. Peter Dietz On Wed, Jun 5, 2013 at 12:44 PM, Mark H. Wood wrote: > Enjoy your new challenges! We'll miss you. > > -- > Mark H. Wood, Lead System Programmer mw...@iupui.edu > Machines should not be friendly. Machines should be obedient. > > > -- > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] DSpace mod and NetBeans
Hi Michael.
I've never actually solved that part of development. So I end up creating a
folder/symlink with that exact parameter looking string, and store my
Dspace. Cfg in there. ${dspace.dir}
Not ideal, but it let's me keep on going.
Lately, instead of using IDE assisted debugging with breakpoints and
variable inspection, I just have a script named respace that rebuilds
Dspace. My computer is fast enough that rebuilding is only a minute so it's
become tolerable. It probably helps that I've already lived an entire
lifetime in the debugger, and know all of the Dspace classes and variables.
Good luck
On May 31, 2013 6:15 PM, "Michael" wrote:
> I have been successful in setting up NetBeans/Maven/Postgres/Tomcat/git
> on a windows 2003 dev server to navigate, edit and compile our custom
> version of DSpace 1.8.4. Debugging is another issue.
>
> I'm trying to get it to do the same on my win7 development computer
> running NetBeans "internal" Tomcat server (with the hope that I can more
> easily figure out how to debug on that computer). Seems all is well
> except xmlui fails to start.
>
> I "run" from the DSpace-xml-ui (Manakin):: Webapp... project and tomcat
> fails to load the dspace configuration file that it is looking for.
> Here's the top part of my Apache Tomcat Log:
>
> May 31, 2013 4:52:06 PM org.apache.catalina.core.StandardContext
> listenerStart
> SEVERE: Exception sending context initialized event to listener instance
> of class org.dspace.app.util.DSpaceContextListener
> java.lang.IllegalStateException: Cannot load configuration:
>
> file:/C:/Program%20Files/Apache%20Software%20Foundation/Apache%20Tomcat%207.0.34/bin/$%7Bdspace.dir%7D/config/dspace.cfg
> at
>
> org.dspace.core.ConfigurationManager.loadConfig(ConfigurationManager.java:943)
> at
>
> org.dspace.app.util.DSpaceContextListener.contextInitialized(DSpaceContextListener.java:100)
> at
>
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4791)
> at
>
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5285)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at
>
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
> at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
> at
>
> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:657)
> at
>
> org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1637)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: java.io.FileNotFoundException: C:\Program Files\Apache
> Software Foundation\Apache Tomcat
> 7.0.34\bin\${dspace.dir}\config\dspace.cfg (The system cannot find the
> path specified)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.(FileInputStream.java:120)
> at java.io.FileInputStream.(FileInputStream.java:79)
> at
>
> sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70)
> at
>
> sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161)
> at java.net.URL.openStream(URL.java:1010)
> at
>
> org.dspace.core.ConfigurationManager.loadConfig(ConfigurationManager.java:921)
> ... 15 more
>
> The path C:\Program Files\Apache Software Foundation\Apache Tomcat
> 7.0.34\bin\${dspace.dir}\config\dspace.cfg looks like a url with a
> parameter, not an actual file path. Note "bin" has no subfolders.
> Shouldn't ${dspace.dir} have been resolved to "C:\dspace"? Even if it
> was, it would still be wrong as a path.
>
> I believe Tim Donohoe uses Netbeans to debug DSpace and I'm extremely
> jealous!
>
> Does anyone know how this path gets built and what setting or code I
> need to change?
>
> Just for the record, I followed (mostly ;-) the instructions for using
> netbeans with DSpace. Our mods are new java classes with only a couple
> of small changes to the original code base, so I'm thinking if someone
> got debugging to work on their projects, it should work for us too.
>
>
>
>
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
>
[Dspace-devel] [DuraSpace JIRA] (DS-635) Rendering MathML code in abstracts
[
https://jira.duraspace.org/browse/DS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28136#comment-28136
]
Peter Dietz commented on DS-635:
Some of Items in our repository have scientific formulas in the metadata. We
have been exploring how to render this. For instance in the metadata, it looks
like:
The positions of about 5000 spectral lines of $^{12}C_{16}O_{2}$ have been
accurately measured with a multispectrum nonlinear least squares fitting
$technique^{a}$.
The dollar-signs on the edge of a formula get rendered. Our local solution is
to render Item titles, Item Display simple, but not Item Display full (and
instead show the unrendered source).
I'm currently looking at what to do about Metadata that contains dollar signs,
but isn't formulas. i.e. FDA approval of $0.03 pills vs $1.23 pills. In which
case the dollar signs could accidentally get picked up and interpreted.
> Rendering MathML code in abstracts
> --
>
> Key: DS-635
> URL: https://jira.duraspace.org/browse/DS-635
> Project: DSpace
> Issue Type: Improvement
> Components: JSPUI, XMLUI
> Environment: Ubuntu Server 9.04
>Reporter: George Simeonov
>Assignee: Peter Dietz
>Priority: Major
>
> I tried to include ( MathML / HTML ) code in descriptions (abstracts) JSPUI,
> but in browsers is displayed only plain text. MathML is natively supported by
> Firefox and Opera browser. I have a lot of articles with complex math
> formulas in the abstracts. I think that MathML is more important than HTML5
> for example.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-635) Rendering MathML code in abstracts
[ https://jira.duraspace.org/browse/DS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Dietz reassigned DS-635: -- Assignee: Peter Dietz > Rendering MathML code in abstracts > -- > > Key: DS-635 > URL: https://jira.duraspace.org/browse/DS-635 > Project: DSpace > Issue Type: Improvement > Components: JSPUI, XMLUI > Environment: Ubuntu Server 9.04 >Reporter: George Simeonov >Assignee: Peter Dietz >Priority: Major > > I tried to include ( MathML / HTML ) code in descriptions (abstracts) JSPUI, > but in browsers is displayed only plain text. MathML is natively supported by > Firefox and Opera browser. I have a lot of articles with complex math > formulas in the abstracts. I think that MathML is more important than HTML5 > for example. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] Bizarre DSpace Browse Failure
My metadata / technical librarian / repo admin loves the browse indices. But, they're probably the only person. We keep adding additional fields, probably so they can jump directly to items keyed with special metadata. Peter Dietz On Mon, May 20, 2013 at 2:22 PM, Hilton Gibson wrote: > I tried using our browse index today (http://scholar.sun.ac.za) to find > all titles with "knowledge economy". It did not work as well as the > advanced search, which I assume is based on the solr discovery service. I > am thinking of removing the browse indexes. We have > discovery, advanced search and of course google scholar to do searches with. > > Are the browse indexes useful and accurate? > > Comments on the list welcome, I am sitting undecided, on the fence, with > this one. > > Cheers > > hg > > > On 20 May 2013 19:02, Sands Alden Fish wrote: > >> Ivan, thanks for the pointer. >> >> This is one aspect of repo administration I've never had to deal with >> in the past. It is possible that the previous tech lead on this project >> modified those settings without re-running index-init. >> >> I assume there's no issue with rerunning index-init as many times as >> needed? Do you have to rebuild the indexes after re-running that, or is >> that just taken care of as part of the process? >> >> -Sands >> >> P.S. - hg, thanks for the link, it's useful to see your process written >> out. >> >> -- >> *From:* ivan.ma...@gmail.com [ivan.ma...@gmail.com] on behalf of helix84 >> [heli...@centrum.sk] >> *Sent:* Monday, May 20, 2013 12:11 PM >> *To:* Sands Alden Fish >> *Cc:* dspace-devel@lists.sourceforge.net >> *Subject:* Re: [Dspace-devel] Bizarre DSpace Browse Failure >> >> On Mon, May 20, 2013 at 6:03 PM, Sands Alden Fish wrote: >> >>> We have Discovery turned off. Any help or hints would be appreciated. >>> The table "bi_2_dis" does not seem to be specified anywhere in the >>> codebase. >>> >> >> Hi Sands, >> >> the bi_2_dis table belongs to the second browse index >> (webui.browse.index.2) and has to be regenerated after changing that >> property. Those properties also have to be numbered sequentially with no >> gaps. >> >> I'm only pointing that out because you tried to look it up in the >> codebase, while it's in fact generated by index-init. I assume you have >> tried running index-init, have you? >> >> >> Regards, >> ~~helix84 >> >> Compulsory reading: DSpace Mailing List Etiquette >> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette >> >> >> >> -- >> AlienVault Unified Security Management (USM) platform delivers complete >> security visibility with the essential security capabilities. Easily and >> efficiently configure, manage, and operate all of your security controls >> from a single console and one unified framework. Download a free trial. >> http://p.sf.net/sfu/alienvault_d2d >> ___ >> Dspace-devel mailing list >> Dspace-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dspace-devel >> >> > > > -- > *Hilton Gibson* > Systems Administrator > JS Gericke Library > Room 1025C > Stellenbosch University > Private Bag X5036 > Stellenbosch > 7599 > South Africa > > Tel: +27 21 808 4100 | Cell: +27 84 646 4758 > http://library.sun.ac.za > http://scholar.sun.ac.za > http://ar1.sun.ac.za > http://aj1.sun.ac.za > > > -- > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-358) Discuss implications of HTML5 for DSpace
[
https://jira.duraspace.org/browse/DS-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=27961#comment-27961
]
Peter Dietz commented on DS-358:
A DSpace JIRA Review on April 17th, 2013 had us add some notes to this.
I've noticed that I've had trouble getting cocoon to spit out the proper HTML5
doctype.
{code}
{code}
DSpace/XMLUI is currently spitting out something like:
{code}
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml"; class="no-js">
{code}
You are somewhat dependent on cocoon for serializing to HTML. What we've got is
an HTML4 serializer, and I don't think there is any such thing as a HTML5
serializer for cocoon 2.
More cocoon discussion can be found at:
http://mail-archives.apache.org/mod_mbox/cocoon-dev/201201.mbox/%3c78b923726e7d59429936580cf127e943a1f4e61...@eu1rdcrdc1wx032.exi.nxp.com%3E
Non-the-less, Ohio State's DSpace instance the Knowledge Bank http://kb.osu.edu
has customized the existing HTMLserializer to give out a more trimmed doctype.
In dspace-xmlui/dspace-xmlui-api/src/main/webapp/sitemap.xmap, OSU has
customized this to be:
{code}
UTF-8
yes
{code}
And the doctype that we spit out is:
{code}
http://www.w3.org/1999/xhtml";>
{code}
Which should be fair enough. We haven't completely re-done the XMLUI layout to
be written in HTML5 by scratch, but since OSU KB is using twitter bootstrap for
much of the UI, which probably makes use of HTML5 elements, we are getting
there.
(Apologies if the formatting of this comment is butchered, I'm used to JIRA's
code macro for formatting code.)
> Discuss implications of HTML5 for DSpace
>
>
> Key: DS-358
> URL: https://jira.duraspace.org/browse/DS-358
> Project: DSpace
> Issue Type: Task
> Components: JSPUI, XMLUI
>Reporter: Stuart Lewis
>
> The possible implications of HTML5 on DSpace need to be discussed. Please use
> this JIRA ticket to add comments and discussion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] Demo Instance of (hedtek) DSpace REST API + Sample Client App
Hi All, I've updated the demo.dspace.org site to reflect some changes. 1) There is a DEMO Hedtek REST API <http://demo.dspace.org/rest-hedtek/>being hosted on the demo.dspace site now, it spits out data from the demo.dspace.org repository. This is a read-only API that outputs DSpace content in JSON or XML for various endpoints (communities, collections, items, bitstreams, eperson, groups), it also allows for Searching, and to harvest a repository over specified time ranges. 2) I've added a simple kick-the-tires REST API Client application that talks SOLELY with the above hedtek REST API. Its name for now can be called DSpace API Client Play! <http://dspace-rest-client-play.herokuapp.com/>. Instead of laboring to modify JSPUI or XMLUI to use the REST API, I figured it would be easier to test the REST API, but starting from scratch. It is built in the Java Play! Framework (if I were to do this again, I'd probably start with Ruby on Rails) . The goal of this project is quick kick the tires, and somewhat replicate the DSpace browse experience through this UI, using the REST API as the data-source. Thus far you can see top-level communities, show a specific community, browse its sub-collections, sub-communities, and get to Items. The Bitstream portion isn't built yet. So, I just wanted to let you all know about these changes, and to invite you to take a look, give feedback, and get familiar. I don't have any experience with the Wijiti DSpace API, which is why I haven't put it up on the dspace demo site. Anyone who wants to can feel free to put that up there too. Peter Dietz -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] Fwd: [GSoC Mentors Announce] Google Summer of Code 2013
Perhaps if we had more wood behind fewer arrows. (That's Larry Page speak for higher quality.) Call me crazy, but I would like to see (sanity check me please), a Hydra Head with DSpace as the backend. This gives us a Ruby on Rails app that is a consumer of our REST API. Peter Dietz On Tue, Feb 12, 2013 at 10:06 AM, Tim Donohue wrote: > > On 2/12/2013 4:10 AM, helix84 wrote: > > Tim, I don't remember, were we chosen as a mentoring organization in > 2012? > > Last year (2012), unfortunately DuraSpace just missed the cut. But, we > were a Google Summer of Code mentoring organization from 2007-2010 (as > DSpace Federation) and in 2011 (as DuraSpace). > > Last year was the first year we didn't make the cut. At the time we were > told our DuraSpace application was good, but that they decided to let in > some organizations which had never been a part of GSoC (and had to make > some tough decisions based on limited slots). So, there's never any > guarantee that we'll be accepted (even with a good application). But > we're hopeful we'd make the cut this year. > > - Tim > > > -- > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1416) NPE when removing roles from Collection workflow steps
[
https://jira.duraspace.org/browse/DS-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=27360#comment-27360
]
Peter Dietz commented on DS-1416:
-
Not as clean as a pull-request, but I've corrected this for my local repository
with:
https://github.com/osulibraries/DSpace/commit/d813c11dd3329dc862d5f2b6840551565638fd5c
I'll work on a PR when I get the time.
> NPE when removing roles from Collection workflow steps
> --
>
> Key: DS-1416
> URL: https://jira.duraspace.org/browse/DS-1416
> Project: DSpace
> Issue Type: Bug
> Components: DSpace API, XMLUI
>Affects Versions: 3.0
>Reporter: Ian Boston
>
> In the XMLUI
> If I edit a collection
> Add a role to a workflow step clicking create.
> Add a user to that role.
> save
> then delete the role from the workflow step.
> I get the following NPE:
> java.lang.NullPointerException
> at
> org.dspace.xmlworkflow.WorkflowUtils.deleteRoleGroup(WorkflowUtils.java:215)
> at
> org.dspace.app.xmlui.aspect.administrative.FlowContainerUtils.processDeleteCollectionRole(FlowContainerUtils.java:538)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:155)
> at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:243)
> at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:3237)
> The method is:
> public static void deleteRoleGroup(Context context, Collection collection,
> String roleID) throws SQLException, IOException,
> WorkflowConfigurationException {
> Workflow workflow = WorkflowFactory.getWorkflow(collection);
> Role role = workflow.getRoles().get(roleID);
> Line: 215>>>>>>> NPE on roleif(role.getScope() ==
> Role.Scope.COLLECTION){
> CollectionRole ass = CollectionRole.find(context,
> collection.getID(), roleID);
> ass.delete();
> }
> }
> You could do
> if ( role != null && role.getScope() ...
> but role should not be null ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1416) NPE when removing roles from Collection workflow steps
[
https://jira.duraspace.org/browse/DS-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=27359#comment-27359
]
Peter Dietz commented on DS-1416:
-
I've made a dummy collection on the Demo instance:
http://demo.dspace.org/xmlui/admin/collection?collectionID=51 to see this bug
in action, try to go to Assign Roles, and delete the Workflow Step.
Below, the code that hard-codes XML-Workflow.
{code}
else{
WorkflowUtils.deleteRoleGroup(context, collectionID, roleName);
}
// else if (ROLE_WF_STEP1.equals(roleName))
// {
// collection.setWorkflowGroup(1, null);
// }
// else if (ROLE_WF_STEP2.equals(roleName))
// {
// collection.setWorkflowGroup(2, null);
// }
// else if (ROLE_WF_STEP3.equals(roleName))
// {
// collection.setWorkflowGroup(3, null);
//
// }
{code}
Commit at:
https://github.com/DSpace/DSpace/commit/65f5786e9e13336122a71aa9f8ec51898901e541#L46R528
> NPE when removing roles from Collection workflow steps
> --
>
> Key: DS-1416
> URL: https://jira.duraspace.org/browse/DS-1416
> Project: DSpace
> Issue Type: Bug
> Components: DSpace API, XMLUI
>Affects Versions: 3.0
>Reporter: Ian Boston
>
> In the XMLUI
> If I edit a collection
> Add a role to a workflow step clicking create.
> Add a user to that role.
> save
> then delete the role from the workflow step.
> I get the following NPE:
> java.lang.NullPointerException
> at
> org.dspace.xmlworkflow.WorkflowUtils.deleteRoleGroup(WorkflowUtils.java:215)
> at
> org.dspace.app.xmlui.aspect.administrative.FlowContainerUtils.processDeleteCollectionRole(FlowContainerUtils.java:538)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:155)
> at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:243)
> at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:3237)
> The method is:
> public static void deleteRoleGroup(Context context, Collection collection,
> String roleID) throws SQLException, IOException,
> WorkflowConfigurationException {
> Workflow workflow = WorkflowFactory.getWorkflow(collection);
> Role role = workflow.getRoles().get(roleID);
> Line: 215>>>>>>> NPE on roleif(role.getScope() ==
> Role.Scope.COLLECTION){
> CollectionRole ass = CollectionRole.find(context,
> collection.getID(), roleID);
> ass.delete();
> }
> }
> You could do
> if ( role != null && role.getScope() ...
> but role should not be null ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1416) NPE when removing roles from Collection workflow steps
[
https://jira.duraspace.org/browse/DS-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Dietz updated DS-1416:
Status: Open (was: Received)
I can confirm this bug, it affects 1.8, and 3.0.
When using the "Original Workflow", leaving the new "XML Workflow" disabled,
this breaks. It looks like the code to processDeleteCollectionRole in
FlowContainerUtils is hard-coded to trigger the XML-Workflow code, as opposed
to the Original Workflow code.
> NPE when removing roles from Collection workflow steps
> --
>
> Key: DS-1416
> URL: https://jira.duraspace.org/browse/DS-1416
> Project: DSpace
> Issue Type: Bug
> Components: DSpace API, XMLUI
>Affects Versions: 3.0
>Reporter: Ian Boston
>
> In the XMLUI
> If I edit a collection
> Add a role to a workflow step clicking create.
> Add a user to that role.
> save
> then delete the role from the workflow step.
> I get the following NPE:
> java.lang.NullPointerException
> at
> org.dspace.xmlworkflow.WorkflowUtils.deleteRoleGroup(WorkflowUtils.java:215)
> at
> org.dspace.app.xmlui.aspect.administrative.FlowContainerUtils.processDeleteCollectionRole(FlowContainerUtils.java:538)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:155)
> at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:243)
> at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:3237)
> The method is:
> public static void deleteRoleGroup(Context context, Collection collection,
> String roleID) throws SQLException, IOException,
> WorkflowConfigurationException {
> Workflow workflow = WorkflowFactory.getWorkflow(collection);
> Role role = workflow.getRoles().get(roleID);
> Line: 215>>>>>>> NPE on roleif(role.getScope() ==
> Role.Scope.COLLECTION){
> CollectionRole ass = CollectionRole.find(context,
> collection.getID(), roleID);
> ass.delete();
> }
> }
> You could do
> if ( role != null && role.getScope() ...
> but role should not be null ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1400) Elastic Search implementation of Statistics has no documentation around how to use, enable or disable.
[ https://jira.duraspace.org/browse/DS-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Dietz resolved DS-1400. - Resolution: Fixed Documentation for this feature is available at: https://wiki.duraspace.org/display/DSDOC3x/Elastic+Search+Usage+Statistics > Elastic Search implementation of Statistics has no documentation around how > to use, enable or disable. > -- > > Key: DS-1400 > URL: https://jira.duraspace.org/browse/DS-1400 > Project: DSpace > Issue Type: Documentation > Components: Documentation, Statistics >Affects Versions: 3.0 >Reporter: Tim Donohue >Assignee: Peter Dietz > Fix For: 3.1 > > > The Elastic Search implementation of DSpace Statistics (DS-1241) has no > documentation. The code is available, but it is unclear how to do any of the > following: > * enable / disable it > * customize (if possible / necessary) > * use it in general -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] Fwd: missing empty directories in dspace-1_8_x and older
Hi, The wiki for the pre-DSpace3 has instructions on how to correct yourself. https://github.com/DSpace/DSpace-SVN-Deprecated/wiki/Fixing-%22missing-dspace-modules-jspui-src-main-webapp-directory%22 I don't like PR#105 (merge commit bringing in hundreds of changes). That one has already been closed as won't pull. Doctorland has made another pull-request, that is a single-commit, and creates 7 new files that makes git track these empty directories. I would bless/approve this commit. https://github.com/DSpace/DSpace/pull/107 I do recognize that this affects a previous branch than our latest, but as-we-speak its our latest stable version of DSpace. At my University, we based our 1.8 upgrade off of DSpace/DSpace 1.8.x, and we had to make this same exact correction. Its time consuming, and annoying, and easily preventable with this PR. Peter Dietz On Mon, Oct 22, 2012 at 11:10 AM, João Melo wrote: > Hi Helix, > > as far as 1.8.x version doesn't become obsolete this kind of pulls can > happen. It's a weird problem for DSpace starters, however, i agree with > you. > > On 19 October 2012 15:02, helix84 wrote: > >> Hello, I'm forwarding this here for discussion. >> It started when we migrated to Git. One thing we overlooked is that >> Git doesn't manage empty directories. Of you have empty directories >> and commit them, they won't be there if you clone the repo. The >> problem in our case is, that maven needs these empty directories, so >> any old version migrated to Git from SVN won't build until you apply >> the workaround we documented here: >> >> >> https://wiki.duraspace.org/display/DSPACE/Development+with+Git#DevelopmentwithGit-CommonDSpaceGit/GitHubIssues >> >> We cannot fix the Git history now. We announced that the DSpace/DSpace >> repo on GitHub is official and there have been many forks. If we >> decided to rewrite the history, all of those forks would have to be >> thrown away and that's just not viable. >> >> Yesterday, Jonathan Harker noticed the problem and sent pull request >> #105 [1], which was meant to add a commit to the dspace-1_8_x branch, >> that would fix that if you checked out any later commit. I closed it >> only for formal problems, not because I disagree with the idea. I'm >> taking the idea here to discuss. >> >> Obviously, this solution isn't systemic and introduces different >> behaviour. On one hand we'd have working mvn package for all commits >> after this one. On other hand, we'd still have mvn package throwing >> and error for the commits before it in this branch and for all commits >> in the older branches. Status quo is at least consistent and >> documented. What do you think? >> >> [1] https://github.com/DSpace/DSpace/pull/105 >> >> Regards, >> ~~helix84 >> >> On Fri, Oct 19, 2012 at 3:40 PM, Tim Donohue >> wrote: >> > This discussion should probably take place on dspace-devel. >> > >> > I'm honestly not sure how many folks this even effects. If it does annoy >> > several folks, then I agree the effort may be worth it to clean this up >> in >> > the branches. But, if most folks don't even encounter this, it may not >> be >> > worth the effort. >> > >> > I know we did write up the workaround on our Git instructions: >> > >> https://wiki.duraspace.org/display/DSPACE/Development+with+Git#DevelopmentwithGit-CommonDSpaceGit/GitHubIssues >> > >> > - Tim >> > >> > >> > On 10/19/2012 1:16 AM, helix84 wrote: >> >> >> >> Hi Tim, >> >> >> >> what do you think of the idea of adding the missing empty directories >> >> (required to build) to the HEAD of the dspace-1_8_x branch (and >> >> possibly older branches)? >> >> >> >> https://github.com/DSpace/DSpace/pull/105 >> >> >> >> Obviously, checking out any older commit from the branch would still >> >> need creating those directories, we can't change that now and it's >> >> documented. This change would potentialy introduce more confusion, >> >> becase in a given branch commits after some commit would build >> >> differently than before it. >> >> >> >> Do we want to make this change? >> >> >> >> Regards, >> >> ~~helix84 >> >> >> > >> >> >> -- >> Everyone hates slow websites. So do we. >> Make your web apps faster wi
[Dspace-devel] [DuraSpace JIRA] (DS-956) Skip from Item page to next Item in Browse results without having to return to Browse results page
[ https://jira.duraspace.org/browse/DS-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Dietz updated DS-956: --- Attachment: Screen Shot 2012-10-11 at 2.31.36 PM.png I've implemented a very basic form of this feature request, which does allow paging from one item to the next. I haven't taken into account any sort of state or scope (i.e. search results or browse-by-title). But it iterates through the collection. You can see the diff which accomplishes this on our OSU repository. (This won't apply to DSpace:DSpace, but to our local instance) https://github.com/osulibraries/DSpace/compare/osulibraries:osukb...osulibraries:item-paging > Skip from Item page to next Item in Browse results without having to return > to Browse results page > -- > > Key: DS-956 > URL: https://jira.duraspace.org/browse/DS-956 > Project: DSpace > Issue Type: New Feature > Components: JSPUI >Reporter: Sue Walker-Thornton >Priority: Major > Attachments: Screen Shot 2012-10-11 at 2.31.36 PM.png > > > We would like to see a new feature in DSpace where a User could "skip" from > the Item short (or long) listing to the next Item in either Browse or Search > results without having to return to the Browse or Search results page. Let's > say I do a search from the DSpace home page on "rocket". I get a list of all > Items in DSpace that contain the word rocket, either in the metadata or in a > filtered bitstream. Say I click on the first Item in the list and the Item > short-listing page is displayed. We would like to be able to review that > Item, then "skip" to the next Item that was returned in the Browse or Search > results, WITHOUT HAVING TO GO BACK TO THE BROWSE OR SEARCH RESULTS PAGE. > Optimally, I'd like to see an icon or button that says "Next Item" or > something like that. Once I've scrolled to the next item, then there should > be a "Previous Item" and a "Next Item" icon or button, if applicable. This > would be SOO cool! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] Tables in configuration doco. are hard to read
Hi Mark, I've updated the statistics configuration docs the other day, and I noticed the same issue, that the configurations all get lost in a big mess of repeated content. To the statistics page, I inserted a blank row in the table between entries. If bold/highlighting is clearer, then we can go that direction. Peter Dietz On Thu, Oct 11, 2012 at 10:34 AM, Mark H. Wood wrote: > https://wiki.duraspace.org/display/DSDOC3x/Configuration > > These are a kind of multilevel table: three rows make up one complete > entry. There's no distinction among the rows so it's hard to scan > down the entries. > > Elsewhere in the documentation I've seen such tables formatted with a > highlight on the first line of each entry. I'd like to suggest doing > that on the Configuration page. > > -- > Mark H. Wood, Lead System Programmer mw...@iupui.edu > Asking whether markets are efficient is like asking whether people are > smart. > > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-421) Setting solr.metadata.item.X property to an unqualified field generates exception in SolrLogger.post on item view and prevents Solr from logging the event
[ https://jira.duraspace.org/browse/DS-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25875#comment-25875 ] Peter Dietz commented on DS-421: While looking through SolrLogger, I've noticed that the code to support stuffing metadata into Solr stats is still possible. https://github.com/DSpace/DSpace/blob/deb732e3cb2f36325cfda8aa28989695bfbd4cab/dspace-stats/src/main/java/org/dspace/statistics/SolrLogger.java#L137 Even though its been removed from dspace.cfg. I would recommend removing all traces of metadataStorageInfo, IDEA says this would affect a number of files. > Setting solr.metadata.item.X property to an unqualified field generates > exception in SolrLogger.post on item view and prevents Solr from logging the > event > -- > > Key: DS-421 > URL: https://jira.duraspace.org/browse/DS-421 > Project: DSpace > Issue Type: Bug > Components: DSpace API >Affects Versions: 1.6.0 >Reporter: Scott Hanrath >Assignee: Mark Diggory > Fix For: 1.6.0 > > > Setting a solr.metadata.item.X property to an unqualified field (e.g., > dc.title rather then dc.title.alternative) generates an exception in > SolrLogger.post on item view. The ArrayIndexOutOfBoundsException appear to > prevent Solr from logging the event. > The stacktrace from the logs is: > java.lang.ArrayIndexOutOfBoundsException: 2 > at org.dspace.statistics.SolrLogger.post(SolrLogger.java:216) > at > org.dspace.statistics.SolrLoggerUsageEventListener.receiveEvent(SolrLoggerUsageEventListener.java:48) > at > org.dspace.services.events.SystemEventService.fireLocalEvent(SystemEventService.java:154) > at > org.dspace.services.events.SystemEventService.fireEvent(SystemEventService.java:97) > at > org.dspace.app.xmlui.cocoon.UsageLoggerAction.logDspaceObject(UsageLoggerAction.java:61) >[...] > This is similar to DS-419 in that a metadata field like 'schema.element' is > being split into an array and the methods is then trying to access > non-existent 3rd element of the array (i.e., array[2], representing the > qualifier) without checking the array length first. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.duraspace.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1241) Statistics implementation in Elastic Search
[ https://jira.duraspace.org/browse/DS-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25728#comment-25728 ] Peter Dietz commented on DS-1241: - once you've rebuilt, with this. The elastic-search stats is visible from path /stats i.e. http://localhost:8080/dspace/handle/123456789/1/stats > Statistics implementation in Elastic Search > --- > > Key: DS-1241 > URL: https://jira.duraspace.org/browse/DS-1241 > Project: DSpace > Issue Type: New Feature >Reporter: Peter Dietz >Assignee: Peter Dietz > Fix For: 3.0 > > Attachments: Screen Shot 2012-08-10 at 5.10.52 PM.png > > > Work at Ohio State University Libraries for the Knowledge Bank, has had us > demanding more out of statistics. We have worked building a statistics > dashboard in SOLR, but ran into performance issues. We have since started > from the ground up (to a degree), and built an implementation of storing > UsageEvent statistics into Elastic Search. I can't really speak about > comparing SOLR to Elastic Search, but that we (OSU) prefers Elastic Search, > and that this is our implementation that we'd like to contribute. > This contribution will include the ElasticSearch UsageEvent listener, a > standalone ElasticSearch client, and some modifications to XMLUI to view a > statistics portal that has statistics from this solution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.duraspace.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1241) Statistics implementation in Elastic Search
[ https://jira.duraspace.org/browse/DS-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25727#comment-25727 ] Peter Dietz commented on DS-1241: - Cleaned up implementation sitting in repository at: https://github.com/peterdietz/DSpace/commits/elastic-search-stats/ Will create pull request after building a tool to ease import of data from SOLR / dspace.log > Statistics implementation in Elastic Search > --- > > Key: DS-1241 > URL: https://jira.duraspace.org/browse/DS-1241 > Project: DSpace > Issue Type: New Feature > Reporter: Peter Dietz > Assignee: Peter Dietz > Fix For: 3.0 > > Attachments: Screen Shot 2012-08-10 at 5.10.52 PM.png > > > Work at Ohio State University Libraries for the Knowledge Bank, has had us > demanding more out of statistics. We have worked building a statistics > dashboard in SOLR, but ran into performance issues. We have since started > from the ground up (to a degree), and built an implementation of storing > UsageEvent statistics into Elastic Search. I can't really speak about > comparing SOLR to Elastic Search, but that we (OSU) prefers Elastic Search, > and that this is our implementation that we'd like to contribute. > This contribution will include the ElasticSearch UsageEvent listener, a > standalone ElasticSearch client, and some modifications to XMLUI to view a > statistics portal that has statistics from this solution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.duraspace.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1241) Statistics implementation in Elastic Search
[ https://jira.duraspace.org/browse/DS-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Dietz updated DS-1241: Attachment: Screen Shot 2012-08-10 at 5.10.52 PM.png > Statistics implementation in Elastic Search > --- > > Key: DS-1241 > URL: https://jira.duraspace.org/browse/DS-1241 > Project: DSpace > Issue Type: New Feature > Reporter: Peter Dietz > Assignee: Peter Dietz > Fix For: 3.0 > > Attachments: Screen Shot 2012-08-10 at 5.10.52 PM.png > > > Work at Ohio State University Libraries for the Knowledge Bank, has had us > demanding more out of statistics. We have worked building a statistics > dashboard in SOLR, but ran into performance issues. We have since started > from the ground up (to a degree), and built an implementation of storing > UsageEvent statistics into Elastic Search. I can't really speak about > comparing SOLR to Elastic Search, but that we (OSU) prefers Elastic Search, > and that this is our implementation that we'd like to contribute. > This contribution will include the ElasticSearch UsageEvent listener, a > standalone ElasticSearch client, and some modifications to XMLUI to view a > statistics portal that has statistics from this solution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.duraspace.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1241) Statistics implementation in Elastic Search
Peter Dietz created DS-1241: --- Summary: Statistics implementation in Elastic Search Key: DS-1241 URL: https://jira.duraspace.org/browse/DS-1241 Project: DSpace Issue Type: New Feature Reporter: Peter Dietz Assignee: Peter Dietz Fix For: 3.0 Work at Ohio State University Libraries for the Knowledge Bank, has had us demanding more out of statistics. We have worked building a statistics dashboard in SOLR, but ran into performance issues. We have since started from the ground up (to a degree), and built an implementation of storing UsageEvent statistics into Elastic Search. I can't really speak about comparing SOLR to Elastic Search, but that we (OSU) prefers Elastic Search, and that this is our implementation that we'd like to contribute. This contribution will include the ElasticSearch UsageEvent listener, a standalone ElasticSearch client, and some modifications to XMLUI to view a statistics portal that has statistics from this solution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.duraspace.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] SpringUI : First contact
>From what I'm aware of, Twig is a templating language for PHP. How will this incorporate into Java? Also, one of the more annoying pain-points in Yet-Another-UI, is amount of code duplication into your UI that is currently required, when communicating with the DSpace-API. There was a conversation about creating "Business Services" to handle centralizing these frequently re-used API to UI code. So I am curious if you've thought about how you would handle the situation where XMLUI or JSPUI or WEBMVC or SPRINGUI all have an exact same piece of code in the UI, and how you might address somehow moving that into a re-usable core. Just my two cents, but if I were to embark on a new UI, I would want to have an ORM (which might be scope creep). Also, I would weigh the cost/benefit of straight Java (DSpace-API), vs querying REST, vs Solr. Also, there are other frameworks to consider, such as Play! framework which is built in Java, or something like Ruby on Rails where you can query the Rest API / Solr for the data. There is also the possibility of JRuby, which is ruby implemented in the JVM, which means if you needed to make Java calls to DSpace-API, you still could. I found that the documentation for Spring's MVC UI system was very sparse or hard to find, and I felt like you had to fight to make it work, in contrast with other frameworks that are very well documented and have a very healthy user-base that provide lots of tutorials and learning for others who might want to join later. i.e. Will University X that has limited IT resources be able to staff someone (possibly a student) who can customize this UI? I agree very much that cocoon/XMLUI/XSLT is a challenge, I just hope you weigh that you not just find a system that "works better than XMLUI", but perhaps is actually a good framework for development. Especially given that it will require a considerable investment of time and resources. Peter Dietz On Thu, Jul 19, 2012 at 11:12 PM, DSpace @ Lyncode wrote: > Hi all, > > some of the current lyncode developments for DSpace, in fact, begin by > some specific requirements of the SpringUI, that is, an under development > UI for DSpace. As we are willing to develop a robust, wide accepted UI and > giving it to the DSpace community as a code contribution, we would like to > have, firstly, some feedback from the DSpace devel team. > > Let me invite you to read the following draft: > https://wiki.duraspace.org/display/~lyncode/SpringUI > > As you could see at the end of the referred page, our contact with the > DSpace community in this specific will start by *"**1. Compile an about > page with all necessary info"*. So, is there anything left to say? > > We would be pleased, based on your expertise, to listen to your > advices/doubts. > > -- > > Thanks, DSpace @ Lyncode > DSpace Department > *Lyncode*: Official website <http://www.lyncode.com/> > > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] [Dspace-tech] DSpace REST API
I've finally gotten around to building this dspace-rest module. So here are
some technical notes on my getting started.
The only surprise was to have to implement a method in dspace-api
ItemIterator.skip()
Otherwise the module/pom wiring went pretty smoothly. I've pasted my git
diff's to both dspace-source, and to dspace-rest into a GitHub Gist:
https://gist.github.com/3109012
Once maven compiled successfully, I edited my IntelliJ Tomcat Deploy
configuration to add the dspace-rest:war.
Then, I ran into HTTP 500 errors when trying to view data from the rest
api. It was as helix mentioned that by default it
wants /devel/dspace/config/dspace.cfg.
To make it use my real dspace.cfg, I had to edit
dspace-rest/src/main/webapp/WEB-INF/web.xml
dspace-config
-${dspace.dir}/config/dspace.cfg
+/dspace/config/dspace.cfg
Additionally, I found that hard-coding the above dspace-config setting
wasn't taking, and found that I also had to comment out some directory
overriding...
dspace-rest/src/main/java/org/dspace/rest/servlet/DS16DirectServlet.java
// for dev testing only COMMENT IN WORKING ENVIRONMENT
-if (config.contains("dspace.dir")) {
-config = "/devel/dspace/config/dspace.cfg";
-}
+//if (config.contains("dspace.dir")) {
+//config = "/devel/dspace/config/dspace.cfg";
+//}
After that, things started working, and I could use the REST API to get
real data.
Once I have some experience with the rest-api and build some psuedo-client
app then I'll hopefully have some more feedback.
But, cheers to HedTek, I'm glad that you've been able to take the
initiative to make some progress on getting us closer to a usable REST API.
I read the README, and there is a fair amount of limitations / known
issues. So hopefully we can continue to polish what you've built here, and
hopefully that can be called REST v1.0, and then as that gets used, and we
have more effort around a refactoring or a rewrite, maybe we can work on a
REST v2.0, especially as you mentioned some technical difficulties with
working with the Sakai architecture.
I will admit that having not managed the evolution of an API between
versions. I'm not sure if you would rename the API from v1 to v2 when you
do underneath implementation changes (i.e. compatible), and preserve the
existing endpoints and functionalities, or do you change the Rest API
version number when you change the endpoints / returned-data format. I'm
guessing the latter.
Peter Dietz
On Wed, Jul 11, 2012 at 2:30 AM, helix84 wrote:
> On Wed, Jul 11, 2012 at 8:20 AM, Hayden Young
> wrote:
> > Hi
> >
> > Okay we'll research these issues further and come up with some solutions.
> >
> > So the compiled version of the REST API does work despite the mismatches
> and
> > some build issues?
>
> Yes, it does. I didn't find any problems so far (only the conceptual
> problem with listing users I mentioned).
>
> Regards,
> ~~helix84
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Dspace-devel mailing list
> Dspace-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] [DuraSpace JIRA] (DS-1151) good blog
I deleted this spam. Peter Dietz On Mon, Apr 2, 2012 at 4:37 AM, aditpunya (Created) (DuraSpace JIRA) < no-re...@duraspace.org> wrote: > good blog > - > > Key: DS-1151 > URL: https://jira.duraspace.org/browse/DS-1151 > Project: DSpace > Issue Type: New Feature > Components: Documentation >Reporter: aditpunya > > > Kata kata Mutiara, Psikologi Remaja, Arti Hidup, Tutorial Web dan Blogging > - Jakarta > > http://aditpunya.blogspot.com/ > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators: > https://jira.duraspace.org/secure/ContactAdministrators!default.jspa > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > > > -- > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1151) good blog
[ https://jira.duraspace.org/browse/DS-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Dietz deleted DS-1151: > good blog > - > > Key: DS-1151 > URL: https://jira.duraspace.org/browse/DS-1151 > Project: DSpace > Issue Type: New Feature >Reporter: aditpunya > Labels: -, Arti, Blogging, Hidup,, Jakarta, Kata, Mutiara,, > Psikologi, Remaja,, Tutorial, Web, dan, kata > > Kata kata Mutiara, Psikologi Remaja, Arti Hidup, Tutorial Web dan Blogging - > Jakarta > http://aditpunya.blogspot.com/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.duraspace.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] [Dspace-commit] DSpace codebase will be moving to GitHub. It's official!
As I thought about this a bit more, I did somewhat have a change of heart, and kind of think we ought to "properly" redo it. Imagine when DSpace migrates to xyz-version-control in a decade. We'll all be emeritus, and wondering where our place in history is. And the future people migrating the code will be like, hey, home come there's two different mappings for authors. Another possible question, is people who have svn commits, but will not be creating github accounts, those commits need to be swallowed by a user. So either ping everyone else to be like, hey, can you create an account, otherwise we dump all their commit attribution onto another user. I'm not sure what happens if you have a partial author mapping. And to address the, hey, your broke my fork of you. We could leave DSpace/DSpace renamed to DSpace/DSpace-pre-official until everyone un-forks it, and then we just spend the half-day fixing forks. So, consider me talked-in-and-out of shall we. Peter Dietz On Fri, Mar 16, 2012 at 4:39 PM, Mark Diggory wrote: > > > On Wed, Mar 14, 2012 at 11:53 AM, Peter Dietz wrote: > >> Hi All, >> >> Since we're now ready to migrate all of the remainder code to GitHub, two >> questions have popped up. >> >> 1) Should we stick with the existing Github.com/dspace/dspace repository, >> or should we reimport (a fresh git svn clone) so that we can use the author >> mapping to make old commits point to a user's GitHub profile? By pushing >> that change, it would make the current repo incompatible with anyone who >> has forked it, as the reimport would have completely different commitID's. >> > > I think we should drop the existing repo and reimport with corrected > authors. Unless there is any possible means to just update the existing > repo with the authors. Yes this will be a pain for those of us who have > forked... but were actually the ones capable of managing this migration. > > >> >> 2) What should we do about languages? We have >> dspace-xmlui-lang<http://scm.dspace.org/svn/repo/modules/dspace-xmlui-lang/trunk/src/main/webapp/i18n/> >> and >> dspace-api-lang<http://scm.dspace.org/svn/repo/modules/dspace-api-lang/trunk/src/main/resources/> >> I >> don't imagine that people like having to manage two separate language >> files. So would we want to consolidate that into a single project? If so, >> anyone up to doing the work for that refactoring? Where would >> messages/language extensions for modules fit? >> > > Each project is "separate" and meant to be updated separately. If we want > to merge and refocus this so that language updates are part of minor > releases, I'm ok as it will probably lead to less confusion for the > community. This means that dspace-api-lang would go under > dspace-api/src/main/resources and that dspace-xmlui-lang would go under > dspace-xmlui/src/main/webapp/ > > Finally, I want to toss in that my Maven project consolidation coding > combined with the above will really simplify dspace build... > https://github.com/mdiggory/DSpace/tree/maven-project-consolidation > > Mark > > -- > [image: @mire Inc.] > *Mark Diggory *(Schedule a > Meeting<https://www.google.com/calendar/selfsched?sstoken=UUdDSzJzTTlOUE1mfGRlZmF1bHR8MzgwMmEwYjk1NDc1NDQ1MGI0NWViYjYzZjExZDI3Mzg> > ) > *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010* > *Esperantolaan 4, Heverlee 3001, Belgium* > http://www.atmire.com > > > -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] Thoughts on Git workflow
Hi Mark, I see a potential for Git to facilitate a workflow that denies us early profit from (anyone with access to the repo. can start to review, use, and build on your work), because you get (your work is protected from mishap) and (you can easily roll back changes that didn't work out) by committing locally without sharing. I think that would be a mistake. I'd like to encourage everyone to frequently ask: "what do I have that's > ready (or easily could be)", to organize work so that there is often a non-null answer to that question, and to move small units of work up the workflow > early So, git committing locally and never pushing to a publicly accesible remote could be a problem introduced by this. But its so easy to have your personal fork of a project, and push your feature branch there. Atleast before locking your computer for the day do a git push my-public-repo my-crazy-feature. I think that practice will show us that committing early and committing often (and then pushing to your public remote), will give you benefits of being able to collaborate with others. Also, to make tidy commits that only targets the relevant part of code that you changed with good intent. I use git gui and it lets me easily stage hunks and lines for a commit. So although I made have added some during development things like: log.info(dso.getName()); I wouldn't commit those lines. For Chris Wilper's take that you might also want to squash your intermediate commits into less verbose ones for public consumption, that probably good, but I'm not in the habit of doing that. But with DSpace going to GitHub, that is new territory for me to have commits for public consumption, as opposed to commits that are good enough for sharing with my project team. Peter Dietz On Fri, Mar 9, 2012 at 11:06 AM, Mark H. Wood wrote: > On Fri, Mar 09, 2012 at 10:36:58AM -0500, Chris Wilper wrote: > [snip] > > The workflow I like to follow is: While the work is in a local branch, > > commit early and often so I can rollback easily if I do something dumb > > a couple hours from now. Then, before pushing to origin, do surgery on > > the commits via "git rebase -i' so they're: > > a) in good-sized, meaningful chunks for other people to grok. Ideally > > each chunk adds something useful and is well-tested, especially if > > you're merging to master. This is the point where you can 'squash' all > > those 'minor tweak' commits so people reviewing your changes or > > browsing the repo history down the road don't have to wade through all > > of them. > > This is a good point, and one that I hadn't considered (because I'm > such a Git noob). Working with Git is different from working with > e.g. SVN because push/pull carries along all of the intermediate > history from your local repo, while 'svn diff' doesn't. I've been > thinking in terms of committing once a day (lock my progress when I > lock my desk) but that would often make for some puzzling history if > shared. Gotta spend some more quality time with _Pro Git_ this > weekend. > > I do tend to rely on my IDE's organic local history facility to > protect me from small oopses during the day, rather than the VCS, but > that may change. Something to think about. > > -- > Mark H. Wood, Lead System Programmer mw...@iupui.edu > Asking whether markets are efficient is like asking whether people are > smart. > > > -- > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] [Dspace-commit] DSpace codebase will be moving to GitHub. It's official!
Hi All, Since we're now ready to migrate all of the remainder code to GitHub, two questions have popped up. 1) Should we stick with the existing Github.com/dspace/dspace repository, or should we reimport (a fresh git svn clone) so that we can use the author mapping to make old commits point to a user's GitHub profile? By pushing that change, it would make the current repo incompatible with anyone who has forked it, as the reimport would have completely different commitID's. 2) What should we do about languages? We have dspace-xmlui-lang<http://scm.dspace.org/svn/repo/modules/dspace-xmlui-lang/trunk/src/main/webapp/i18n/> and dspace-api-lang<http://scm.dspace.org/svn/repo/modules/dspace-api-lang/trunk/src/main/resources/> I don't imagine that people like having to manage two separate language files. So would we want to consolidate that into a single project? If so, anyone up to doing the work for that refactoring? Where would messages/language extensions for modules fit? Peter Dietz On Thu, Mar 8, 2012 at 5:14 PM, Tim Donohue wrote: > Hello developers, > > By a unanimous decision on 'dspace-devel', the DSpace codebase will be > moving to GitHub in the near future. > > By my tally, the results were: > > 20 developers/committers in favor of migrating (+1 vote) > 0 developers/committers unsure about migrating (0 vote) > 0 developers/committers against migrating (-1 vote) > > I will now be working with the Committer team to begin this migration > process. The migration will likely happen in a series of stages in the > coming weeks. > > I've started a wiki page to begin tracking the migration process: > https://wiki.duraspace.org/display/DSPACE/Migration+to+GitHub > > (Others are encouraged to add to / enhance this page, as I'm sure there > are things I've forgotten. Right now, just some initial steps are listed > there) > > The vast majority of this migration process should happen "behind the > scenes" (most developers won't notice anything until the end). But, once > we get closer to completion, we will announce the date at which all > development is now taking place on GitHub. We will also create some > developer documentation around using the new DSpace GitHub. > > If anyone has any questions, or wants to help out in any way (especially > with creating eventual DSpace GitHub documentation), please let us know! > > - Tim (on behalf of the Committers Team) > > > On 2/29/2012 9:58 AM, Tim Donohue wrote: > > Hi All, > > > > As I've previously stated, today we are opening the vote for whether > > DSpace should move its codebase from SVN to GitHub. More information on > > what this means is below (see "What does this Migration to GitHub Mean?" > > section) > > > > You may vote by responding to this email thread with one of the > following: > > > > +1 = I vote to migrate to GitHub > > 0 = I'm neutral (I don't really care one way or the other) > > -1 = I'd rather DSpace codebase stay on SVN > > > > Based on our Voting for Procedural/Policy Changes, this vote will pass > > if we receive more positive (+1) than negative (-1) votes. > > https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures > > > > VOTING WILL BE OPEN FOR ONE WEEK, UNTIL 20:00UTC ON WEDNESDAY, MARCH 7. > > > > > > = What Does this Migration to GitHub Mean? = > > > > Essentially, if we vote to migrate the DSpace Codebase to GitHub, the > > following changes will occur: > > > > 1. All DSpace projects/modules/codebases that are still in active > > development will be migrated to https://github.com/DSpace/ > > > > 2. The existing SVN codebases will be "archived" and made READ-ONLY (no > > more changes or future releases will occur in SVN). This SVN archive > > will likely also be moved to: https://svn.duraspace.org/ (we can setup a > > redirect such that scm.dspace.org will redirect to the archived > location). > > > > 3. All future development, releases (tags) & branches will occur in the > > DSpace GitHub projects. This means that any active DSpace developers > > will need to begin using this codebase instead of SVN. > > > -- > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > ___ > Dspace-commit mailing list > dspace-com...@lists.sourc
Re: [Dspace-devel] VOTING OPEN: Should DSpace move codebase to GitHub?
+1 Tim, thanks for initiating the voting. Peter Dietz On Wed, Feb 29, 2012 at 10:58 AM, Tim Donohue wrote: > Hi All, > > As I've previously stated, today we are opening the vote for whether > DSpace should move its codebase from SVN to GitHub. More information on > what this means is below (see "What does this Migration to GitHub Mean?" > section) > > You may vote by responding to this email thread with one of the following: > > +1 = I vote to migrate to GitHub > 0 = I'm neutral (I don't really care one way or the other) > -1 = I'd rather DSpace codebase stay on SVN > > Based on our Voting for Procedural/Policy Changes, this vote will pass > if we receive more positive (+1) than negative (-1) votes. > https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures > > VOTING WILL BE OPEN FOR ONE WEEK, UNTIL 20:00UTC ON WEDNESDAY, MARCH 7. > > > = What Does this Migration to GitHub Mean? = > > Essentially, if we vote to migrate the DSpace Codebase to GitHub, the > following changes will occur: > > 1. All DSpace projects/modules/codebases that are still in active > development will be migrated to https://github.com/DSpace/ > > 2. The existing SVN codebases will be "archived" and made READ-ONLY (no > more changes or future releases will occur in SVN). This SVN archive > will likely also be moved to: https://svn.duraspace.org/ (we can setup > a redirect such that scm.dspace.org will redirect to the archived > location). > > 3. All future development, releases (tags) & branches will occur in the > DSpace GitHub projects. This means that any active DSpace developers > will need to begin using this codebase instead of SVN. > > > -- > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1109) Incorporate Hedtek Improvements to REST-API
[ https://jira.duraspace.org/browse/DS-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24262#comment-24262 ] Peter Dietz commented on DS-1109: - Thanks for testing this Samuel. I've created a Github repo for dspace-rest : https://github.com/DSpace/dspace-rest I'm in the process of merging the hedtek contributions. But I haven't vetted any of it. So I appreciate looking into it. If post/put is disabled, then this might bring in lots of regressions. > Incorporate Hedtek Improvements to REST-API > --- > > Key: DS-1109 > URL: https://jira.duraspace.org/browse/DS-1109 > Project: DSpace > Issue Type: Code Task > Components: REST API (experimental) >Reporter: Peter Dietz > > A group of developers at Hedtek contacted the mailing list making us aware of > their improvements they have made to the REST-API. Their improvements include > tests, and other bug fixes to improve stability of the REST api. Their > improvements have been made to their Git repository, which isn't quite a > clone of the svn project for the dspace rest project. > My / PeterDietz's question... > Shall the dspace-rest project be moved to Github to make it easier for > community contributions? Including to merge in these improvements from > Hedtek. DSpace is potentially moving all code to GitHub, and if so, it would > make sense for modules to move there as well anyways. Tim has recently moved > the dspace-replicate module code there. > If so, then I have no problem stitching together the history of our code > history from SVN, and their disjoint work in their github. From then on, > hedtek can fork the future consolidated git repository, and continue > development as they had been. The next benefit is that DSpace can then merge > in their improvements much easier. Merge, cherry-pick, or Pull-Request. > Subject: [Dspace-devel] Testing the DSpace REST API > From: Mark van Harmelen > Hi everyone > Through Jorum [1] we've been doing some JISC [2] funded work on testing the > DSpace REST API. To date we have tested most of the 'read' side of the API, > later we may be moving onto the 'write' side. > You can find out what we have done so far at > http://hedtek.com/2011/dspace-rest-api-testing/ including the URL of our > github repo (that contains slightly modified code for the API and our tests). > What we have found out about the API so far appears in the sole/first comment > on the blog post. > I am the sole Hedtek person on this list, if you want to ask questions or > comment, I will pick them up, but even better please to cc them to > hed...@googlegroups.com > Thanks/regards > mark > [1] http://www.jorum.ac.uk/ > [2] http://www.jisc.ac.uk/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.duraspace.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1121) Searches interspersed with a minus (separated by spaces) will exclude the following term. (AND NOT)
[ https://jira.duraspace.org/browse/DS-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Dietz updated DS-1121: Attachment: DS-1121-hacking-DSQuery-to-strip-interspersed-dashses.patch Screen Shot 2012-02-08 at 5.57.54 PM.png A quick-and-dirty patch that will strip out interspersed dashes from queries. > Searches interspersed with a minus (separated by spaces) will exclude the > following term. (AND NOT) > --- > > Key: DS-1121 > URL: https://jira.duraspace.org/browse/DS-1121 > Project: DSpace > Issue Type: Bug > Components: DSpace API >Affects Versions: 1.8.0, 1.8.1 >Reporter: Peter Dietz >Assignee: Peter Dietz > Fix For: 3.0 > > Attachments: > DS-1121-hacking-DSQuery-to-strip-interspersed-dashses.patch, Screen Shot > 2012-02-08 at 4.30.51 PM.png, Screen Shot 2012-02-08 at 4.31.03 PM.png, > Screen Shot 2012-02-08 at 5.57.54 PM.png > > > I have confirmed that this problem exists... Here's the original report. > -- In an email to dspace-tech, Jessica Lindholm writes: > Dear all, > I would like some advice on Boolean operators and their implications on > search / search results. > > Some publications have a minus sign in titles, e.g. in Chronic intraoral pain > - assessment of diagnostic methods and prognosis > http://hdl.handle.net/2043/12563. > > This gives us a problem when searching for the item. It coincides with '-' > minus being the operator for AND NOT, so we all of a sudden look for stuff > without specific words. A simple free-text search matching the title above > leads to zero hits. And users tend to e.g. copy a title from a reference list > to the search box. > > Has anyone encountered the same problem? We have looked around and haven't > found a solution (stopwords, tokens, queries). > > We are using AND as standard operator for all searches, i.e. we have that > changed in config.xml (from default OR). If we had used OR as default the > problem wouldn't appear, and possibly this opens up for a logical slip in the > system (or by me, which is not unlikely at all). Google uses the same > operator, but handling it differently when surrounded by whitespaces. > > Is this a possible bug encountered? > > We would preferably like to change the Boolean operators to usage of > capitalised AND NOT, AND etc instead of -,+. Believing this would solve the > issue. Is this possible (Java okay)? > > However when matching exact, using quotation marks both the searches: > "Chronic intraoral pain assessment of diagnostic methods and prognosis" > (minus excluded) and "Chronic intraoral pain - assessment of diagnostic > methods and prognosis" works fine. So the minus is treated to some extent. > > Looking forward to understand better, > > Jessica Lindholm > > Ps Malmo university is using DSpace (1.8.*) XMLUI as our institutional > repository. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.duraspace.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1121) Searches interspersed with a minus (separated by spaces) will exclude the following term. (AND NOT)
Searches interspersed with a minus (separated by spaces) will exclude the following term. (AND NOT) --- Key: DS-1121 URL: https://jira.duraspace.org/browse/DS-1121 Project: DSpace Issue Type: Bug Components: DSpace API Affects Versions: 1.8.1, 1.8.0 Reporter: Peter Dietz Assignee: Peter Dietz Fix For: post-1.8.x Attachments: Screen Shot 2012-02-08 at 4.30.51 PM.png, Screen Shot 2012-02-08 at 4.31.03 PM.png I have confirmed that this problem exists... Here's the original report. -- In an email to dspace-tech, Jessica Lindholm writes: Dear all, I would like some advice on Boolean operators and their implications on search / search results. Some publications have a minus sign in titles, e.g. in Chronic intraoral pain - assessment of diagnostic methods and prognosis http://hdl.handle.net/2043/12563. This gives us a problem when searching for the item. It coincides with '-' minus being the operator for AND NOT, so we all of a sudden look for stuff without specific words. A simple free-text search matching the title above leads to zero hits. And users tend to e.g. copy a title from a reference list to the search box. Has anyone encountered the same problem? We have looked around and haven't found a solution (stopwords, tokens, queries). We are using AND as standard operator for all searches, i.e. we have that changed in config.xml (from default OR). If we had used OR as default the problem wouldn't appear, and possibly this opens up for a logical slip in the system (or by me, which is not unlikely at all). Google uses the same operator, but handling it differently when surrounded by whitespaces. Is this a possible bug encountered? We would preferably like to change the Boolean operators to usage of capitalised AND NOT, AND etc instead of -,+. Believing this would solve the issue. Is this possible (Java okay)? However when matching exact, using quotation marks both the searches: "Chronic intraoral pain assessment of diagnostic methods and prognosis" (minus excluded) and "Chronic intraoral pain - assessment of diagnostic methods and prognosis" works fine. So the minus is treated to some extent. Looking forward to understand better, Jessica Lindholm Ps Malmo university is using DSpace (1.8.*) XMLUI as our institutional repository. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.duraspace.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] Does cocoon care where an http request originates?
Hi Joseph, It looks like both ORIGIN and TARGET are within the same domain, so you shouldn't have any cross-site security blockers. But from within the same domain, your XHR would/should get the same exact thing from a URL as the browser would. The standard use-case of an XHR would be to hit your json/xml endpoint, as opposed to your fully rendered XHTML site. I think within-same-domain means that you can also communicate across webapps at different contexts on the same domain. i.e. http://localhost/xmlui, can make a request to http://localhost/rest Peter Dietz On Thu, Jan 26, 2012 at 1:03 AM, Joseph wrote: > Dear DSpace Developers, > > Quick question: Does cocoon care where an http request originates? > > Specifically, if I send a request from within a dspace page (ORIGIN)to > another know dspace page(TARGET) using the javascript XMLHttpRequest() > would TARGET run though all the aspects to generate the DRI and then the > DRI processed by the theme resulting in the same code being generated (and > then returned) just as if I had made the request with a normal browser? > > Thank You, > -Joseph > > > -- > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] Testing the DSpace REST API
Reviving this issue... @Bojan, I'd like to merge in Hedtek's contributions to dspace-rest. I don't think a static copy/paste of their work would be sufficient, especially since they appear to still be somewhat actively developing their instance of the module. To accomplish this, I'd like to convert our current dspace-rest module from SVN to GIT for version control tracking. Then, merge hedtek's improvements into dspace-rest, and host it on github. I think moving to GitHub is best for the rest project to get community contribution, like from Hedtek. I've made a JIRA issue about merging in these improvements: https://jira.duraspace.org/browse/DS-1109 Peter Dietz On Fri, Dec 2, 2011 at 11:58 AM, Mark van Harmelen wrote: > Hi Bojan and Peter > > Yes, please, incorporate our tests into your codebase as well. > > We are just adding the DSpace licence as I write so everything is in a > good state for you to incorporate the tests into the DSpace codebase as > open source (but please tell us if we need to do anything else). > > > Peter's plan for forking etc is good. > > We seem to have found some colleagues who are interested in working on > tests as well, let's hope that that takes off. > > Sorry if your mail to hed...@googlegroups.com bounced, we have fixed that > now :) > > regards > mark > > On Fri, Dec 2, 2011 at 4:24 PM, Peter Dietz wrote: > >> @Hedtek, >> Cheers for the development effort! >> >> >> There's nothing like an application to help motivate a project, and a >> little funding helps too. >> >> >> @Bojan, >> I think a better path to pick up on these commits wouldn't be to try to >> make a super-commit with the diff and pull it back to SVN. I think moving >> dspace-rest to github, and helping hedtek rebase their commits off of that >> to make a proper fork would be best. So that, after we get a chance to >> review the code, then we can either merge all the commits (preserving >> hedtek's authorship). Thus making it really easy for anyone to kick the >> tires, fix a few things, and contribute back. >> >> Peter Dietz >> >> >> >> >> On Fri, Dec 2, 2011 at 8:28 AM, Bojan Suzic wrote: >> >>> Hi Mark, >>> >>> this looks like a major contribution to the REST module! Thanks for the >>> effort invested! >>> I see you have posted several bug fixes in your repo. I will take a look >>> at the changes and try to integrate them in the current branch. Are you >>> interested to have the tests integrated too? >>> >>> Kind regards >>> Bojan >>> >>> >>> >>> Am 02.12.2011 13:30, schrieb Mark van Harmelen: >>> > Hi everyone >>> > >>> > Through Jorum [1] we've been doing some JISC [2] funded work on testing >>> > the DSpace REST API. To date we have tested most of the 'read' side of >>> > the API, later we may be moving onto the 'write' side. >>> > >>> > You can find out what we have done so far at >>> > http://hedtek.com/2011/dspace-rest-api-testing/ including the URL of >>> > our github repo (that contains slightly modified code for the API and >>> > our tests). >>> > What we have found out about the API so far appears in the sole/first >>> > comment on the blog post. >>> > >>> > I am the sole Hedtek person on this list, if you want to ask questions >>> > or comment, I will pick them up, but even better please to cc them to >>> > hed...@googlegroups.com <mailto:hed...@googlegroups.com> >>> > >>> > Thanks/regards >>> > mark >>> > >>> > [1] http://www.jorum.ac.uk/ >>> > [2] http://www.jisc.ac.uk/ >>> > >>> > -- >>> > Dr Mark van Harmelen >>> > School of Computer Science, University of Manchester, UK and Hedtek Ltd >>> > >>> > cell/mobile+44 7830 212 464 / 07830 212 464 >>> > skype markvanharmelen >>> > web http://hedtek.com >>> > >>> > Hedtek Ltd is a limited company registered in England and Wales, Co Reg >>> > No 631 >>> > >>> > >>> > >>> > >>> -- >>> > All the data continuously generated in your IT infrastructure >>> > contains a definitive record of customers, application performance, >>> >
[Dspace-devel] [DuraSpace JIRA] (DS-1109) Incorporate Hedtek Improvements to REST-API
Incorporate Hedtek Improvements to REST-API --- Key: DS-1109 URL: https://jira.duraspace.org/browse/DS-1109 Project: DSpace Issue Type: Code Task Components: REST API (experimental) Reporter: Peter Dietz A group of developers at Hedtek contacted the mailing list making us aware of their improvements they have made to the REST-API. Their improvements include tests, and other bug fixes to improve stability of the REST api. Their improvements have been made to their Git repository, which isn't quite a clone of the svn project for the dspace rest project. My / PeterDietz's question... Shall the dspace-rest project be moved to Github to make it easier for community contributions? Including to merge in these improvements from Hedtek. DSpace is potentially moving all code to GitHub, and if so, it would make sense for modules to move there as well anyways. Tim has recently moved the dspace-replicate module code there. If so, then I have no problem stitching together the history of our code history from SVN, and their disjoint work in their github. From then on, hedtek can fork the future consolidated git repository, and continue development as they had been. The next benefit is that DSpace can then merge in their improvements much easier. Merge, cherry-pick, or Pull-Request. Subject: [Dspace-devel] Testing the DSpace REST API From: Mark van Harmelen Hi everyone Through Jorum [1] we've been doing some JISC [2] funded work on testing the DSpace REST API. To date we have tested most of the 'read' side of the API, later we may be moving onto the 'write' side. You can find out what we have done so far at http://hedtek.com/2011/dspace-rest-api-testing/ including the URL of our github repo (that contains slightly modified code for the API and our tests). What we have found out about the API so far appears in the sole/first comment on the blog post. I am the sole Hedtek person on this list, if you want to ask questions or comment, I will pick them up, but even better please to cc them to hed...@googlegroups.com Thanks/regards mark [1] http://www.jorum.ac.uk/ [2] http://www.jisc.ac.uk/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.duraspace.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-927) REST-API All item submitter information is returned for an item request, even for an anonymous request.
[ https://jira.duraspace.org/browse/DS-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=23925#comment-23925 ] Peter Dietz commented on DS-927: In a recent DSpace Developers meeting, we agreed that full details about the user should not be available to unauthenticated user, so we'll need to swap the user information, with just a user ID. Regarding getting some central service to take care of determining which data to make available to each UI, we discussed this in the 2012/01/18 developer meeting, and we'd like to get some refactoring to the DSpace code base before 3.0 to move commonly-repeated-code out of the UI's, and into some common business service. Thus, REST shouldn't have to reimplement how to accomplish each piece of functionality. > REST-API All item submitter information is returned for an item request, even > for an anonymous request. > --- > > Key: DS-927 > URL: https://jira.duraspace.org/browse/DS-927 > Project: DSpace > Issue Type: Bug > Components: REST API (experimental) >Reporter: Robin Taylor > > If I enter a request for a specific item eg. > http://localhost:8080/rest/items/58.xml the response includes all the ePerson > information for the person that submitted the request. This info is not > visible in the UI and I suspect should not be exposed here, at least not to a > non-administrator. > > robin.tay...@ed.ac.uk > Robin > Robin Taylor > > 1 > en > Taylor > robin.tay...@ed.ac.uk > > false > false > 7 > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.duraspace.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] DSpace & IDEs - Features, Observations, and Recommendations
Hi Patrick, I would say my DSpace activities fall into two camps: - Configuration updates, as requested by a user (updating input-forms.xml, dspace.cfg, Messages.properties) I do the configuration updates mostly all through vim, or FTP. A user gives me an updated input-form, I upload it to the server, and restart tomcat. Or a user needs me to change a setting in the DSpace config, I ssh into the server, and use vim to edit the file, then restart tomcat. Our repository admins use oxygen to edit the input-form xml file. - Development, Java / XSLT I have a clone of our production environment on my local computer, where I do my active development. I use IntelliJ IDEA because (like Eclipse or NetBeans) it allows me to explore the code, and as you type something like "Community" in your IDE, the autocomplete feature looks at all the methods available in that class, or on an object, as well as the documentation. This is very handy, and very intuitive. Another fantastic feature of IDEA atleast, is its tomcat integration and debugging. If I'm working on a feature in Java in XMLUI, I have a green button I click that rebuilds everything, restarts tomcat, and opens my browser to my development instance of DSpace. When I notice that there is something going wrong, I go back to the code and fix it, then I click a blue button that rebuilds and restarts tomcat. The blue button rebuilds and restarts DSpace in less than 30 seconds. When I run into really hairy problems, IDEA can let me add breakpoints to the code, and do full debugging. The breakpoints pause execution of the page, and show me all of the variables, their values, and let me see which execution path is taken, i.e. did the code go into my IF block? You can't debug XSLT development, but that doesn't bother me. I hope I answered your question... Peter Dietz On Fri, Jan 13, 2012 at 1:58 PM, Patrick Etienne < patrick.etie...@library.gatech.edu> wrote: > Greetings again all, (seems I've been writing in a good bit lately) > > I'm writing in again to both Techs and Devs in hopes that folks might have > time at some point to say a little something about different aspects of > their experience with integrating their DSpace work into various IDEs. This > primarily comes about as a result of > DS-921<https://jira.duraspace.org/browse/DS-921>and the accompanying > Confluence page on Tips > for IDE > Integration<https://wiki.duraspace.org/display/DSPACE/Developer+Guidelines+and+Tools>. > Long story short, I had no idea that the majority of DSpace committers / > developers were using either IntelliJ or NetBeans for their IDE over > Eclipse (I think this explains why there is so little DSpace/Eclipse > documentation). My normal responsibilities within DSpace development at my > institution primarily focus on either configuration management for our many > DSpace instances or Manakin development (xslt), but I often find that I > would like to be more knowledgable about the inner workings of DSpace and > that a solid integration of DSpace into an IDE would facilitate this, which > brings me to the point of this email. One of the tools I use most > frequently in Eclipse is oXygen <http://www.oxygenxml.com/>. I'm aware > that oXygen has no IntelliJ or NetBeans plugin, so am wondering whether > those of you who use IntelliJ or NetBeans might be familiar with their > innate capabilities in comparison to oXygen or if perhaps you might be > aware of plugins for those IDEs that have similar features. The other > question I have concerning IntelliJ and NetBeans is what experience folks > might have with integration into Jira. I'm aware that Atlassian has plugins > for both Eclipse and IntelliJ, but nothing for NetBeans. > > This is not a major issue, but more of just a discussion that I believe > some people may be interested in when people have time to write in. Any > time that you would take to speak about your experience with these issues > would be greatly appreciated. > > Many Thanks, > > - Patrick E. > > -- > Patrick K. Etienne > Systems Analyst > Georgia Institute of Technology > Library & Information Center > (404) 385-8121 > > > > > -- > RSA(R) Conference 2012 > Mar 27 - Feb 2 > Save $400 by Jan. 27 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev2 > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] Bulk Upload in with Zipped SAF
Hi Joseph, I found this old thread, but I was just thinking about this today. The SimpleArchiveFormat seems to work fine as a format (easy to create from having a directory of files, and a spreadsheet), but once you've created your package, you still need to transfer the package to a server, and run dspace-import on it from the command line. The DSpace XMLUI batch metadata edit works really well, but doesn't allow you to add new files. I'm thinking that the portion of XMLUI that controls batch metadata editing, could be modified to swing handling bitstreams/files. Instead of uploading a csv, you would upload a zip containing the directory structure of csv + content files. Perhaps a smaller change, if possible, would be to add a filename-path column to the batch metadata editting, and then DSpace could attempt to fetch the content files from the network. such as http://PetersComputer.lib.ohio-state.edu/batch/SenateCollection/ABCD123.pdf I've looked into SWORD, but from my basic understanding, it is expecting a METS package. Or perhaps I have it wrong, and DSpace is expecting METS from sword. Peter Dietz On Wed, Aug 31, 2011 at 9:11 AM, Joseph wrote: > Dear DSpace-Devel, > > I'm pretty sure you can upload many items, as a zip file that contains a > the simple archive format directory structure. > Can you do a bulk upload with a zipped SAF through the XMLUI? > > If not strict XMLUI, can SWORD or some other tool do this through some > sort of web interface? > > Thank You, > Joseph > > > > > -- > Special Offer -- Download ArcSight Logger for FREE! > Finally, a world-class log management solution at an even better > price-free! And you'll get a free "Love Thy Logs" t-shirt when you > download Logger. Secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > ___ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-920) Collapsible Community/Collection Treeview jQuery plugin
[ https://jira.duraspace.org/browse/DS-920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Dietz reassigned DS-920: -- Assignee: Peter Dietz > Collapsible Community/Collection Treeview jQuery plugin > --- > > Key: DS-920 > URL: https://jira.duraspace.org/browse/DS-920 > Project: DSpace > Issue Type: New Feature > Components: XMLUI >Reporter: Colin Gormley > Assignee: Peter Dietz > Attachments: treeview.patch > > > This patch adds jQuery Treeview functionality > (http://bassistance.de/jquery-plugins/jquery-plugin-treeview/) to the > communities and collections views in XMLUI Reference theme. > This patch is intended to improve the UI, especially when navigating larger > numbers of communities and collections. > For more detailed information, please see > http://developer.edina.ac.uk/projects/jorumdspace/wiki/Collection_Browse_tree > To see the collapsible tree in action, visit the Jorum customised version of > DSpace 1.5.2 at http://open.jorum.ac.uk > Note that this functionality hasn't been added to any of the other sample > XMLUI themes or to the JSPUI. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.duraspace.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1044) Select Collection step limits length of collection name, leading to difficulty in picking the correct collection.
[ https://jira.duraspace.org/browse/DS-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Dietz updated DS-1044: Affects Version/s: 1.8.1 1.8.0 > Select Collection step limits length of collection name, leading to > difficulty in picking the correct collection. > - > > Key: DS-1044 > URL: https://jira.duraspace.org/browse/DS-1044 > Project: DSpace > Issue Type: Bug > Components: XMLUI >Affects Versions: 1.7.0, 1.7.1, 1.7.2, 1.8.0, 1.8.1 >Reporter: Peter Dietz >Assignee: Peter Dietz > Fix For: post-1.8.x > > Attachments: DS-1044-select-collection-limit-name-length.patch, > select-collection-full-length.png, select-collection-truncated-text.png > > > When a user picks a collection in the submission process from the dropdown > list of all collections a string-length of max 50 is set somewhere. Users end > up trying to distinguish their collection to submit to from drop down option > values looking like this: > http://di.tamu.edu/DRI/1.0/"; class="ds-form-content"> > class="ds-select-field" name="handle" title="Select the collection you wish > to submit an item to."> > Select a collection... > Student Essays / Utbildningsvetenskap med > inrik... > Student Essays / Utbildningsvetenskap med > inrik... > Student Essays / Utbildningsvetenskap med > inrik... > which is far from optimal. > The collection names seem to be shortened only in this particular display. > Anyone with ideas how to solve this, rather than shortening names of > collections? > Kind regards > Jessica Lindholm -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.duraspace.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] [DuraSpace JIRA] (DS-1044) Select Collection step limits length of collection name, leading to difficulty in picking the correct collection.
[ https://jira.duraspace.org/browse/DS-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Dietz closed DS-1044. --- > Select Collection step limits length of collection name, leading to > difficulty in picking the correct collection. > - > > Key: DS-1044 > URL: https://jira.duraspace.org/browse/DS-1044 > Project: DSpace > Issue Type: Bug > Components: XMLUI >Affects Versions: 1.7.0, 1.7.1, 1.7.2, 1.8.0, 1.8.1 >Reporter: Peter Dietz >Assignee: Peter Dietz > Fix For: post-1.8.x > > Attachments: DS-1044-select-collection-limit-name-length.patch, > select-collection-full-length.png, select-collection-truncated-text.png > > > When a user picks a collection in the submission process from the dropdown > list of all collections a string-length of max 50 is set somewhere. Users end > up trying to distinguish their collection to submit to from drop down option > values looking like this: > http://di.tamu.edu/DRI/1.0/"; class="ds-form-content"> > class="ds-select-field" name="handle" title="Select the collection you wish > to submit an item to."> > Select a collection... > Student Essays / Utbildningsvetenskap med > inrik... > Student Essays / Utbildningsvetenskap med > inrik... > Student Essays / Utbildningsvetenskap med > inrik... > which is far from optimal. > The collection names seem to be shortened only in this particular display. > Anyone with ideas how to solve this, rather than shortening names of > collections? > Kind regards > Jessica Lindholm -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.duraspace.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
