-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've run into this as well this week. I think it would be safe to call this a "bug". I did a quick scan in the SouceForge bug tracker (http://sourceforge.net/tracker/?group_id=177054&atid=879703) and didn't see it, so you might want to submit an issue. Peter On 4/24/07 8:54 AM, Lennaert van der Linden wrote:

Hi, When trying to get a datastream by a Fedora URL, e.g. http://example.org/fedora/get/id:1/DC, for a datastream that doesn't exist (anymore) Fedora returns an empty object instead of a http 404 error. The header returned by fedora is: HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Pragma: No-cache Cache-Control: no-cache Expires: Thu, 01 Jan 1970 01:00:00 CET Content-Length: 0 Date: Tue, 24 Apr 2007 12:50:04 GMT Is this a known issue and is there a workaround? Regards, Lennaert

- -- Peter Murray http://www.pandc.org/peter/work/ Assistant Director, New Service Development tel:+1-614-728-3600;ext=338 OhioLINK: the Ohio Library and Information Network Columbus, Ohio The Disruptive Library Technology Jester http://dltj.org/ Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGMiS84+t4qSfPIHIRApa8AJ9FO7SnsjFbYHonc+sGqzu6+m8M3QCgx1kn Le0LxWWKLFY9JS78djxbGZ8= =16ch -----END PGP SIGNATURE-----

Lynna,

Thanks for the contribution!  I've tested this locally and
it works great...it's now been applied to the DirIngest
trunk.

Cheers,
Chris

-----Original Message-----
From: Lynna Cekova [mailto:lynna-hbROQncn9SD2fBVCVOL8/A@public.gmane.org]
Sent: Tue 5/8/2007 11:18 AM
To: fedora-commons-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Cc: Chris Wilper; Internal OhioLINK Team for DRC Development
Subject: A patch for Diringest 1.1, allowing the user a local (non http) input option

Hi all,

Attached is a modified fedora.services.diringest.IngestSIP.java file,
which I would like to offer for the Fedora Diringest trunk. If the
default IngestSIP.java file is replaced with this one, the user can
choose between the input files (SIP and optional crules) being remote to
Diringest and uploaded by http to Diringest's server (present Diringest
default), or specifying the input files as local (being on the same
machine as Diringest), so that no http upload is needed.

The default url http://host:8080/diringest/ingestSIP  will still open
the default Diringest page, where the user can select the SIP and crules
files, which are then uploaded to Diringest via http, transformed and
ingested into Fedora.   The url  
http://host:8080/diringest/ingestSIP?local=yes (modification, not in the
original Diringest), on the other hand, will open a similar page where
the user needs to manually enter the file paths (the files being on the
same machine where Diringest is running), and the files will be directly
transformed and ingested to Fedora, without an http upload. The original
input files will not be deleted after having been transformed.

I had to make such a modification for the needs of OhioLINK, where we
work with very large inputs, located on the same server as Diringest, to
save time, space, and bandwidth. Others with similar needs and
conditions can benefit from the local input option as well. The change
does not remove any existing Diringest features, but adds an additional
one.

Please, let me know if you have any questions.

Best,

Lynna Cekova
Systems Developer
OhioLINK

Hi Lynna,

While testing your patch, I tried both configurations (setting
the pid namespace in diringest.properties and not)
with a fresh Fedora 2.2 and wasn't able to reproduce this.

- Chris

-----Original Message-----
From: fedora-commons-users-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org on behalf of Lynna Cekova
Sent: Mon 4/30/2007 11:05 AM
Cc: fedora-commons-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; fedora-commons-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: [Fedora-commons-users] Diringest problem with Fedora 2.2

Hello,

When using Diringest 1.1 to upload files to a Fedora 2.2. repository, I
get the following error:

java.io.IOException: Error getting remote pid list: Error parsing
pidList: Premature end of file.

I have no such problems with the same Diringest instance and a Fedora
2.1. installation. The only time I have seen this problem before was
when I was trying to ingest files to a Fedora 2.1.1 installation that
used a custom PID generator. Reverting to the default Fedora 2.1.1
generator solved the problem.

This particular Fedora 2.2. repository is a default installation. Does
anyone have any thoughts?

Thanks,
Lynna

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Fedora-commons-users mailing list
Fedora-commons-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/fedora-commons-users

The NSDL uses it extensively in a "leader-follower" configuration
for failover purposes.

-----Original Message-----
From: fedora-commons-users-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org on behalf of ranju upadhyaya
Sent: Tue 5/8/2007 11:06 AM
To: fedora-commons-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: [Fedora-commons-users] Journaling

Hi all,

just wondering if anybody has used the Journaling module of FEDORA?

Regards.

Ranju Upadhyay.
Irish Virtual Research Library and Archive.

_________________________________________________________________
Make free PC-to-PC calls with no loss of life!
http://www.communicationevolved.com/en-ie/


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Fedora-commons-users mailing list
Fedora-commons-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/fedora-commons-users

Hi Graeme,

It sounds like somehow your repository was configured to
forward to SSL, even though that's not what you intended.

You can either re-run the install script (do a fresh Fedora
install, removing the old one first) or shut down tomcat
and modify the Fedora webapp's WEB-INF/web.xml file and
remove the element or elements that contain the
string "CONFIDENTIAL". This is the part that tells the
servlet container to forward requests to the https port.

You're right about needing the client to have a certificate
when using SSL.  It needs to have a "truststore" file that
says it trusts the server certificate.  The fedora-admin.bat/.sh
script includes the correct -D directives to the java program
so that the example certificate can be found at runtime.  So I'd
look at those for examples for making use of the truststore from
your own app.

- Chris

-----Original Message-----
From: fedora-commons-users-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org on behalf of Graeme West
Sent: Tue 5/8/2007 7:46 PM
To: fedora-commons-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: [Fedora-commons-users] Forcing non-SSL access through Fedora Adminclient & web

Hi folks,
When connecting to my Fedora 2.2 test installation via the non-SSL 
port through a browser, I am instantly bounced to the SSL port. I'm 
pretty sure I specified during installation that SSL should not be 
required for either API-A or API-M, but it does this regardless. 
What's the best way to change this behaviour, through XACML policies 
or otherwise?

Also, I get a related error when connecting using the Fedora 
Administrator GUI client. I assume this is because I don't yet have a 
proper SSL certificate (I'm using the one included with Fedora for 
now) and Java is being strict about certificate validation. The error 
is:

"org.apache.axis.AxisFault;  ; nested exception is: 
javaxnet.ssl.SSLHandshakeException:  
sun.security.validator.ValidatorException: PKIX path building failed: 
sun.security.provider.certpath.SunCertPathBuilderException: unable to 
find valid certification path to requested target"

It does this even if I specify HTTP in the protocol field, which I 
take to mean that API-M accesses are also being bounced to the HTTPS 
service.

It'd be great if someone could verify that my thinking on this is 
correct, or point out what's actually happening here. I'd like to be 
able to force all accesses to be made through HTTP at the moment for 
testing purposes.

Thanks in advance.

Graeme West


--
Graeme West
Spoken Word Services, Glasgow Caledonian University
graeme.west-5Rjtdvhr3sG1Qrn1Bg8BZw@public.gmane.org