You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Version used: 3.2.1-build 14.01.2021 including activeMQ bugfix #4029
I see the following stack trace in kitodo.log - Hint: activeMQ is NOT configured
#activeMQ.hostURL=failover:(tcp://localhost:61616?closeAsync=false)
It looks like, that this does not have a very negative effect, besides getting error messages in kitodo.log.
But maybe an improvement could be made, to identify the "non-configuration" of activemq in advance, instead of "just" catching an exception.
==> Main concern from my side is, that there might be something wrong - so, please check.
[TRACE] 2021-03-24 08:22:16.960 [localhost-startStop-1] KitodoConfig - Catching
java.util.NoSuchElementException: 'activeMQ.finalizeStep.queue' doesn't map to an existing object
at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1028) ~[commons-configuration-1.10.jar:1.10]
at org.kitodo.config.KitodoConfig.getOptionalString(KitodoConfig.java:233) [kitodo-api-3.2.1-SNAPSHOT.jar:?]
at org.kitodo.production.interfaces.activemq.FinalizeStepProcessor.(FinalizeStepProcessor.java:43) [classes/:3.2.1-SNAPSHOT]
at org.kitodo.production.interfaces.activemq.ActiveMQDirector.(ActiveMQDirector.java:59) [classes/:3.2.1-SNAPSHOT]
at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [?:?]
at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [?:?]
at java.lang.reflect.Constructor.newInstance(Constructor.java:490) [?:?]
at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:151) [tomcat8-catalina-8.5.39.jar:8.5.39]
at org.jboss.weld.environment.tomcat.ForwardingInstanceManager.newInstance(ForwardingInstanceManager.java:26) [weld-servlet-2.4.8.Final.jar:2.4.8.Final]
at org.jboss.weld.environment.tomcat.WeldForwardingInstanceManager.newInstance(WeldForwardingInstanceManager.java:71) [weld-servlet-2.4.8.Final.jar:2.4.8.Final]
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4692) [tomcat8-catalina-8.5.39.jar:8.5.39]
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5236) [tomcat8-catalina-8.5.39.jar:8.5.39]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) [tomcat8-catalina-8.5.39.jar:8.5.39]
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754) [tomcat8-catalina-8.5.39.jar:8.5.39]
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730) [tomcat8-catalina-8.5.39.jar:8.5.39]
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734) [tomcat8-catalina-8.5.39.jar:8.5.39]
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:980) [tomcat8-catalina-8.5.39.jar:8.5.39]
at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1852) [tomcat8-catalina-8.5.39.jar:8.5.39]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
The text was updated successfully, but these errors were encountered:
This informs you that the application has caught an exception because it can deal with it. Note that this is logged on the lowest "TRACE" log level. Such exceptions are meaningless to you unless maybe you are debugging something, when it may be a hint that the application deals with a situation that it can deal with, but this is causing a behaviour which is maybe not what you want.
Ok, understood - this is expected behavor. @Kathrin-Huber : From technical point of view, I could close this ticket. Do you want to keept this open, because of "documentation" tag?
@solth : This is just for document "somewhere", that the kitodo.log on "TRACE"-level might have entries with "Catching".
And these entries are ok.
I would not even know, where to document this. Therefore IMO we can close this issue.
What is you opinion?
Version used: 3.2.1-build 14.01.2021 including activeMQ bugfix #4029
I see the following stack trace in kitodo.log - Hint: activeMQ is NOT configured
#activeMQ.hostURL=failover:(tcp://localhost:61616?closeAsync=false)
It looks like, that this does not have a very negative effect, besides getting error messages in kitodo.log.
But maybe an improvement could be made, to identify the "non-configuration" of activemq in advance, instead of "just" catching an exception.
==> Main concern from my side is, that there might be something wrong - so, please check.
[TRACE] 2021-03-24 08:22:16.960 [localhost-startStop-1] KitodoConfig - Catching
java.util.NoSuchElementException: 'activeMQ.finalizeStep.queue' doesn't map to an existing object
at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1028) ~[commons-configuration-1.10.jar:1.10]
at org.kitodo.config.KitodoConfig.getOptionalString(KitodoConfig.java:233) [kitodo-api-3.2.1-SNAPSHOT.jar:?]
at org.kitodo.production.interfaces.activemq.FinalizeStepProcessor.(FinalizeStepProcessor.java:43) [classes/:3.2.1-SNAPSHOT]
at org.kitodo.production.interfaces.activemq.ActiveMQDirector.(ActiveMQDirector.java:59) [classes/:3.2.1-SNAPSHOT]
at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [?:?]
at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [?:?]
at java.lang.reflect.Constructor.newInstance(Constructor.java:490) [?:?]
at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:151) [tomcat8-catalina-8.5.39.jar:8.5.39]
at org.jboss.weld.environment.tomcat.ForwardingInstanceManager.newInstance(ForwardingInstanceManager.java:26) [weld-servlet-2.4.8.Final.jar:2.4.8.Final]
at org.jboss.weld.environment.tomcat.WeldForwardingInstanceManager.newInstance(WeldForwardingInstanceManager.java:71) [weld-servlet-2.4.8.Final.jar:2.4.8.Final]
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4692) [tomcat8-catalina-8.5.39.jar:8.5.39]
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5236) [tomcat8-catalina-8.5.39.jar:8.5.39]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) [tomcat8-catalina-8.5.39.jar:8.5.39]
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754) [tomcat8-catalina-8.5.39.jar:8.5.39]
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730) [tomcat8-catalina-8.5.39.jar:8.5.39]
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734) [tomcat8-catalina-8.5.39.jar:8.5.39]
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:980) [tomcat8-catalina-8.5.39.jar:8.5.39]
at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1852) [tomcat8-catalina-8.5.39.jar:8.5.39]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
The text was updated successfully, but these errors were encountered: