1 Feb 09:28
Re: [fcrepo-dev] Fedora validation enhancements - FCREPO-1026
That
status code does seem appropriate - I guess there could be a question as to
whether we should provide a code outside rfc2616 but it certainly would be more
informative than 400 (and some of the other rfc4918 codes could be useful in the
future if we supported full transactioning and any locking capabilities outside
the current optimistic concurrency support).
The
REST API documentation doesn't in fact in general specify error codes (apart
from setDatastreamVersionable) and I believe most of the integration tests just
test for a failure.
So
would this in fact constitute an API change to move away from 500 to eg 422 for
invalid FOXML (and for the new object validation failure)? My preference
would be to go for this in 3.6, clearly documenting it in the release
notes.
Steve
-----Original Message-----
From: ajs6f-4Ng6DfrEGID2fBVCVOL8/A@public.gmane.org [mailto:ajs6f-4Ng6DfrEGID2fBVCVOL8/A@public.gmane.org]
Sent: 27 January 2012 16:31
To: fedora-commons-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [fcrepo-dev] Fedora validation enhancements - FCREPO-1026
From: ajs6f-4Ng6DfrEGID2fBVCVOL8/A@public.gmane.org [mailto:ajs6f-4Ng6DfrEGID2fBVCVOL8/A@public.gmane.org]
Sent: 27 January 2012 16:31
To: fedora-commons-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [fcrepo-dev] Fedora validation enhancements - FCREPO-1026
Whether or not we can (or want to) do this for 3.6, I agree that a 400-series error is more appropriate here, since the system is able to respond correctly and the problem is at a different semantic level than the HTTP protocol.
Perhaps a 422 (Unprocessable Entity)? Unfortunately, this is a WebDAV extension, but the semantics very good for this case. See: http://tools.ietf.org/html/rfc4918.The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.
---
A. Soroka
Software and Systems Engineering
Online Library Environment
the University of Virginia LibraryOn Fri, Jan 27, 2012 at 5:20 AM, Stephen Bayliss <stephen.bayliss <at> acuityunlimited.net> wrote:<snipped>* HTTP response code for REST API operations: Currently if an ingest fails XML validation this is reported via HTTP status code 500 (Server Error). To maintain consistency with the existing behaviour, object validation failures will also result in this code, with the text of the exception containing details of the validation failure. I'd suggest that maybe 400 - Bad Request [1] might be more appropriate for both of these; but this would essentially represent a REST API change - would that be acceptable for a Fedora 3.6 release? If this change was made I'd suggest implementing this by catching ObjectValidityException at the API level, and extending this exception to contain details of the validation failure for the response body (rather than the 500 exception reporting that occurs currently).<snipped>
------------------------------------------------------------------------------ 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
_______________________________________________ Fedora-commons-developers mailing list Fedora-commons-developers@... https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
On 13 Feb 2012, at 11:33 PM, Chris Wilper wrote:
> Aha! I thought I remembered you mentioning you had been running maven 3, so I tried it with that and it worked
fine. Normally, I use maven 2, and so does Bamboo.
>
> > It shouldn't be that the DuraSpace repo needs to be listed
> > in both places: that would defeat the point of having
> > pluginRepositories separate from the general artifact repo.
>
> Right; the significant thing is really that it works with maven2 in trippi's pom and it's listed in the
<repositories> section there. But it's not listed in the <repositories> section in fedora-client's pom.
>
> When I move it to <repositories> in fedora-client's pom, it works in maven2, but not maven3. But if it's
listed under both sections, it works in both maven2 and maven3.
>
> So if we want to support both major versions of maven, it seems like it really does need to go in both places.
>
> Ahh, maven.
>
> - Chris
>
> On Sun, Feb 12, 2012 at 11:43 AM, Edwin Shin
<
RSS Feed