Hi, in an effort to share as much information as we have, here's our
latest thinking on this. However, do note, I'm talking about an
esoteric/intermittent error that looks just like the much more
straightforward error that Peter mentions below. It is well worth your
time to troubleshoot as Peter
Very odd indeed. I seem to have confirmed that it is a permissions issue -
but using chown to make dspace the owner did not do the trick. I made the
asset directory world-writeable (don't do this on yours) and uploaded a
file. the new file was owned by tomcat6. Did I miss something in the dspace
On Fri, May 3, 2013 at 10:20 PM, Will Clarke clark...@wfu.edu wrote:
Very odd indeed. I seem to have confirmed that it is a permissions issue -
but using chown to make dspace the owner did not do the trick. I made the
asset directory world-writeable (don't do this on yours) and uploaded a
Hi, Everyone:
I haven't heard from anyone concerning my question on Atom and RSS feeds (see
below). So, unless someone wants to chime in at the last minute, I am going to
assume that there is no answer.Thanks, anyway.
George Kozak
Digital Library Specialist
Cornell University Library
Hi George,
I don't have any help for you at this time, just a few
observations/confirmations:
Your configuration is indded the default:
https://github.com/DSpace/DSpace/blob/dspace-1_8_x/dspace/config/dspace.cfg#L1124
I have tested two 3.x instances (including demo) and a 1.8.2 instance
and all
Thanks, Helix...That is of help.
George Kozak
Digital Library Specialist
Cornell University Library Information Technologies (CUL-IT)
218 Olin Library
Cornell University
Ithaca, NY 14853
607-255-8924
-Original Message-
From: ivan.ma...@gmail.com [mailto:ivan.ma...@gmail.com] On Behalf Of
I did a quick experiment to try to remove the author elements. It
failed, but I don't understand why (I suspect caching).
I tried to turn caching off:
webui.feed.cache.size = 0
webui.feed.cache.age = 0
And I set:
webui.feed.item.author = dc.nonexistent
webui.feed.item.author is used to fill the
It was a caching issue, indeed. But Cocoon cache was the culprit, not
the feed cache.
Here's the result of the experiment in atom 1.0:
author
name/
/author
Is this what you wanted?
Regards,
~~helix84
Compulsory reading: DSpace Mailing List Etiquette
You didn't ask about this, but since I already mentioned it, the
reason why the field labels weren't displayed in my tests was that it
doesn't work in XMLUI in DSpace 1.8, nor in 3. If yours works, you
must be using JSPUI.
You can find details in the bug I filed:
Folks - Sorry if this has been covered before, but I would like to access
http://(my dspace server):8080/solr/
from my PC (on the same network). Right now it gives me a 403 error and
says, Access to the specified resource has been forbidden.
How can I fix this?
Thanks!
Marl
Hi Mark,
I described that here:
https://wiki.duraspace.org/display/DSPACE/Solr
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to
Thanks, helix84. I have seen this document before, but under the Bypassing
localhost restrictions permanently, do I just add that code fragment to
the server.xml file? I'm running 3.0 on Ubuntu 12.04.
On Fri, May 3, 2013 at 6:45 PM, helix84 heli...@centrum.sk wrote:
Hi Mark,
I described that
You should modify the solr Context element (either in server.xml) or in the
context fragment file. But that's written there - if it's unclear, feel
free to rewrite it for clarity.
On May 4, 2013 12:57 AM, Mark Ehle marke...@gmail.com wrote:
Thanks, helix84. I have seen this document before, but
This is what I added to the server.xml file when I installed dspace:
!-- Define a new context path for all DSpace web apps --
Context path=/xmlui docBase=/dspace/webapps/xmlui
allowLinking=true/
Context path=/sword docBase=/dspace/webapps/sword
allowLinking=true/
Context
Just insert Valve and Parameter into the last Context (that has solr path)
On May 4, 2013 1:07 AM, Mark Ehle marke...@gmail.com wrote:
This is what I added to the server.xml file when I installed dspace:
!-- Define a new context path for all DSpace web apps --
Context path=/xmlui
Thanks, Helix...
I'll experiment and let everyone know what I find.
George Kozak
Digital Library Specialist
Cornell University Library Information Technologies (CULIT)
218 Olin Library
Cornell University
Ithaca, NY 14853
607-255-8924
From:
So it looks like this now:
Context path=/solr docBase=/dspace/webapps/solr allowLinking=true
Valve
className=org.apache.catalina.valves.RemoteAddrValve allow=192.168.1.*,
127.0.0.1/
Parameter name=LocalHostRestrictionFilter.localhost
value=false override=false /
That looks correct. I assume you also restarted Tomcat. While changes to
context fragments would be detected automatically, changes to server.xml
aren't.
If it still doesn't work, I don't know why. What about commenting out the
solr Context element in server.xml and putting it into a context
Also try replacing the wildcard with a single IP.
Are you sure that the dspace server sees your IP as 192.168.1.x? I.e. are
you on the same subnet as the dspace server? If you're accessing from home,
you need to use your public IP because the private IP has to go through NAT.
On May 4, 2013 1:24
That means you made solr inaccessible to dspace - the localhost address
doesn't work for some reason. Most likely you have ipv6 enabled on the
dspace server, so it's trying to use an ipv6 localhost address to connect,
but AFAIK remoteaddrvalve doesn't understand ipv6. So the workaround would
be to
20 matches
Mail list logo
