[dspace-tech] Setting Item to private using REST or Database updates
Hello DSpace Community, I upload items to DSpace using a self-written production tool for our publications which compiles TeX files and uploads the pdf to DSpace using the REST API. These publications should be private at first until the TeX file authors have approved the publication. This works perfectly by making the item "private" using the webinterface. But I need to integrate this functionality to our production tool. Is this possible with the REST API? I haven't found anything in the REST API docs. Alternatively, I could modify some flags directly in the postgresql database. I've found out that the "discoverable" flag changes when making an item privat, but the item does not become private when setting the flag manually. Are there some other flags I need to set or do I need to trigger some function to hide the item in the collection? Best regards, Christoph -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/de9b4a52-caa0-4be6-be2e-118c6edffb2e%40googlegroups.com.
Re: [dspace-tech] DSpace 6.3 REST-API stopped working in Ubuntu 18.04 and 18.10
:
Disabling contextual LOB creation as createClob() method thre
w error : java.lang.reflect.InvocationTargetException
2018-10-24 15:18:03,112 INFO org.hibernate.type.BasicTypeRegistry @
HHH000270: Type registration [pg-uuid] overrides previous :
org.hibernate.type.PostgresU
UIDType@376076dd
2018-10-24 15:18:03,112 INFO org.hibernate.type.BasicTypeRegistry @
HHH000270: Type registration [java.util.UUID] overrides previous :
org.hibernate.type.UU
IDBinaryType@7f4b7480
2018-10-24 15:18:03,137 INFO
org.hibernate.engine.transaction.internal.TransactionFactoryInitiator @
HHH000399: Using default transaction strategy (direct J
DBC transactions)
2018-10-24 15:18:03,137 INFO
org.hibernate.hql.internal.ast.ASTQueryTranslatorFactory @ HHH000397:
Using ASTQueryTranslatorFactory
2018-10-24 15:18:03,141 WARN net.sf.ehcache.CacheManager @ Creating a new
instance of CacheManager using the diskStorePath "/tmp" which is already
used by a
n existing CacheManager.
The source of the configuration was
net.sf.ehcache.config.generator.ConfigurationSource$URLConfigurationSource@22badb6f.
The diskStore path for this CacheManager will be set to
/tmp/ehcache_auto_created_1540394283141.
To avoid this warning consider using the CacheManager factory methods to
create a singleton CacheManager or specifying a separate ehcache
configuration (ehca
che.xml) for each CacheManager instance.
2018-10-24 15:18:03,143 INFO org.hibernate.cache.spi.UpdateTimestampsCache
@ HHH000250: Starting update timestamps cache at region:
org.hibernate.cache.spi.
UpdateTimestampsCache
2018-10-24 15:18:03,143 INFO
org.hibernate.cache.internal.StandardQueryCache @ HHH000248: Starting
query cache at region: org.hibernate.cache.internal.Stand
ardQueryCache
2018-10-24 15:18:03,145 FATAL org.dspace.core.Context @ Cannot obtain the
bean which provides a database connection. Check previous entries in the
dspace.log
to find why the db failed to initialize. The schema validator returned:
Error activating Bean Validation integration
I also tried a fresh install of ubuntu 17.10, fresh postgres database and
fresh DSpace 6.3.
REST-API worked as expected. After an update to ubuntu 18.04, it fails
again.
Seems to me that REST-API is broken with ubuntu 18.04 and above.
Best regards,
Christoph
Am Dienstag, 23. Oktober 2018 16:31:53 UTC+2 schrieb Tim Donohue:
>
> Hi Christoph,
>
> You should check your DSpace log files ([dspace]/log/dspace.log.*) for
> additional errors, but based on the line numbers in your error, it looks
> like it fails here:
>
> https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace-api/src/main/java/org/dspace/core/Context.java#L170
>
> Just above that section of code is where DSpace attempts to find the
> Spring bean that will provide the database connection. It looks to me like
> DSpace likely is not able to find that bean (there likely will be FATAL
> errors in your dspace.logs about that).
>
> It's hard to say exactly what is wrong, but it's highly likely that
> either..
>
> * Your DSpace database configuration is not correct (maybe something
> changed in how your database is installed?)
> * Or, your Spring configuration files are running into conflicts or errors
> (which can occur if you have mixed Spring configs from DSpace 5.x and 6.x
> in the same folder). If this is the problem, you can safely delete the
> [dspace]/config/spring/ folder, and then rebuild & redeploy DSpace ("mvn
> package", followed by "ant update") to correct your configuration.
>
> Hopefully that gives you some hints on getting this fixed!
>
> Tim
>
> On Tue, Oct 23, 2018 at 8:13 AM Christoph Weber > wrote:
>
>> Hello DSpace Community,
>>
>> I cannot get the DSpace 6.3 REST-API working in Ubuntu 18.04 and 18.10.
>> The REST-API worked in Ubuntu 17.10, but after upgrading or installing a
>> later version, it stopped working.
>>
>> The Tomcat Web Application Manager gives me "FAIL - Application at
>> context path [/rest] could not be started", when I try to start it manually
>> and in /var/log/tomcat8/localhost.2018-10-23.log I get the following
>> error message:
>>
>> 23-Oct-2018 14:57:48.013 SEVERE [http-nio-8080-exec-7]
>> org.apache.catalina.core.StandardContext.listenerStart Exception sending
>> context initialized event to
>> listener instance of class [org.dspace.app.util.DSpaceWebappListener]
>> org.dspace.core.exception.DatabaseSchemaValidationException: The schema
>> validator returned: Error activating Bean Validation integration
>>at org.dspace.core.Context.init(Context.java:170)
>>at org.dspace.core.Context.(Context.java:126)
>>at
>> org.dspace.app.util.AbstractDSpaceWebapp.register(AbstractDSpaceWebapp.java:74)
&g
[dspace-tech] DSpace 6.3 REST-API stopped working in Ubuntu 18.04 and 18.10
Hello DSpace Community, I cannot get the DSpace 6.3 REST-API working in Ubuntu 18.04 and 18.10. The REST-API worked in Ubuntu 17.10, but after upgrading or installing a later version, it stopped working. The Tomcat Web Application Manager gives me "FAIL - Application at context path [/rest] could not be started", when I try to start it manually and in /var/log/tomcat8/localhost.2018-10-23.log I get the following error message: 23-Oct-2018 14:57:48.013 SEVERE [http-nio-8080-exec-7] org.apache.catalina.core.StandardContext.listenerStart Exception sending context initialized event to listener instance of class [org.dspace.app.util.DSpaceWebappListener] org.dspace.core.exception.DatabaseSchemaValidationException: The schema validator returned: Error activating Bean Validation integration at org.dspace.core.Context.init(Context.java:170) at org.dspace.core.Context.(Context.java:126) at org.dspace.app.util.AbstractDSpaceWebapp.register(AbstractDSpaceWebapp.java:74) at org.dspace.app.util.DSpaceWebappListener.contextInitialized(DSpaceWebappListener.java:31) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4776) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5240) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.manager.ManagerServlet.start(ManagerServlet.java:1349) at org.apache.catalina.manager.HTMLManagerServlet.start(HTMLManagerServlet.java:679) at org.apache.catalina.manager.HTMLManagerServlet.doPost(HTMLManagerServlet.java:217) at javax.servlet.http.HttpServlet.service(HttpServlet.java:661) at javax.servlet.http.HttpServlet.service(HttpServlet.java:742) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.filters.CsrfPreventionFilter.doFilter(CsrfPreventionFilter.java:136) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:613) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:803) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:800) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1463) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.base/java.lang.Thread.run(Thread.java:844) Any ideas on how to get the REST-API running again? Best regards, Christoph -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to
[dspace-tech] How to organize customizations in dspace?
Hello, I'm currently setting up our dspace instance and doing a few changes to customize it. Till. ex. some changes in [dspace-source]/config/input-forms.xml and [dspace-source]/config/registries/dublin-core-types.xml to support DOI. Now I wonder what the best way is to preserve this changes after an update of dspace in the future. Its not something specific to a theme as far as I know, where I simply can put my customizations in [dspace-source]/themes/... as an overlay and use them again in the future. I want to keep my dspace repository as standard as possible to avoid any hassles on the next update. So what is the best way to do that without needing do merge all my changes manually to the new source code? Best regards, Christoph -- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To post to this group, send email to dspace-tech@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
