[Dspace-tech] ClassNotFoundException for org.dspace.app.util.DailyFileAppender under 1.7.1

57 views
Skip to first unread message

John Preston

unread,
Aug 25, 2015, 4:49:07 PM8/25/15
to dspac...@lists.sourceforge.net
I'm getting the following in my tomcat logs for dspace 1.7.1 under
tomcat 6.0.26.

INFO: Loading provided config file: /dspace/config/dspace.cfg
INFO: Using dspace provided log configuration (log.init.config)
INFO: Loading: /dspace/config/log4j.properties
log4j:ERROR Could not instantiate class [org.dspace.app.util.DailyFileAppender].
java.lang.ClassNotFoundException: org.dspace.app.util.DailyFileAppender
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1387)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1233)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at org.apache.log4j.helpers.Loader.loadClass(Loader.java:178)
at org.apache.log4j.helpers.OptionConverter.instantiateByClassName(OptionConverter.java:319)
at org.apache.log4j.helpers.OptionConverter.instantiateByKey(OptionConverter.java:120)
at org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:629)
at org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:612)
at org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:509)
at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:415)
at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:441)
at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:470)
at org.dspace.core.ConfigurationManager.loadConfig(ConfigurationManager.java:719)
at org.naa.server.UFOServiceImpl.init(UFOServiceImpl.java:74)
at javax.servlet.GenericServlet.init(GenericServlet.java:212)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1172)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:992)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4058)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4371)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:627)
at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:516)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:177)
log4j:ERROR Could not instantiate appender named "A1".
log4j:ERROR Could not instantiate class [org.dspace.app.util.DailyFileAppender].
java.lang.ClassNotFoundException: org.dspace.app.util.DailyFileAppender
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1387)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1233)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at java.lang.Class.forName0(Native Method)
.......

It is repeated for all the appenders in the log4j.properties file. I
have another dspace 1.7.0 instance and its fine. Also this instance
seems to work and I get dspace.log files with dates
(dspace.log.2011-05-19). Has something changed.

John

Thornton, Susan M. (LARC-B702)[LITES]

unread,
Aug 25, 2015, 4:49:11 PM8/25/15
to byhis...@gmail.com, dspac...@lists.sourceforge.net
I was getting a similar error upon first bringing up my DSpace 1.7.1 site (upgrading from 1.5.1). I just solved this problem by renaming my log4j.properties file under /dspace/config to log4j.properties.save and then renaming log4j.properties.new to log4j.properties. Seems like log4j.properties.new contained the "translated" file location names. Example:

In log4j.properties: log4j.appender.A1.File=${log.dir}/dspace.log
In log4j.properties.new: log4j.appender.A1.File=/home/dspace/log/dspace.log

I believe the log4j.properties.new file is created when you execute "ant -Dconfig=/{dspace.dir}/config/dspace.cfg update"

The documentation does talk in detail about logging, etc, but I didn't see where it said specifically you need to use the log4j.properties.new file.

Hope this helps.
Sue



Sue Walker-Thornton
Software Developer/Database Administrator
NASA Langley Research Center|LITES Contract
(757) 224-4074
------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
DSpace-tech mailing list
DSpac...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

John Preston

unread,
Aug 25, 2015, 4:49:12 PM8/25/15
to Thornton, Susan M. (LARC-B702)[LITES], dspac...@lists.sourceforge.net
I'm using the log4j.properties file which has the explicit path to the
/dspace/log/dspace.log file. Also the files seem to be created at some
point and the system seems to run. Thus I'm wondering what is causing
the org.dspace.app.util.DailyFileAppender to not be created at startup
but later on.

John

Thornton, Susan M. (LARC-B702)[LITES]

unread,
Aug 25, 2015, 4:49:34 PM8/25/15
to bfr...@unm.edu, dspac...@lists.sourceforge.net
Hi Brian,
That's interesting. Now that you mention that, I just noticed there are a bunch of other .new files under /dspace/config and I'm wondering if I need to rename them all as I had to do with the log4j.properties (using the -overwrite=true parameter you mentioned)...?
Thanks,
Sue


Sue Walker-Thornton
Software Developer/Database Administrator
NASA Langley Research Center|LITES Contract
(757) 224-4074



-----Original Message-----
From: Brian Freels-Stendel [mailto:bfr...@unm.edu]
Sent: Tuesday, May 24, 2011 1:32 PM
To: Thornton, Susan M. (LARC-B702)[LITES]
Subject: Re: [Dspace-tech] ClassNotFoundException for org.dspace.app.util.DailyFileAppender under 1.7.1

Good morning,

If it's a problem with the updated config files having the '.new' extension, you can run the ant command with '-Doverwrite=true' to force updated config files in the source directory to overwrite the current files in the deploy directory. (Actually, it renames the current files to have a '.old' extension and then puts the new ones in place. Apparently, there has to be trash created or the program isn't happy. ;) )

I'm thinking this doesn't really apply for John's situation, so I don't want to muddy the newsgroup waters, but it's a useful trick.

B--

>>> On 5/24/2011 at 10:33 AM, in message
<03DE6124B1F32240B3692...@NDMSSCC07.ndc.nasa.gov>, "Thornton,
Susan M. (LARC-B702)[LITES]" <susan.m....@nasa.gov> wrote:

Thornton, Susan M. (LARC-B702)[LITES]

unread,
Aug 25, 2015, 4:49:35 PM8/25/15
to bfr...@unm.edu, dspac...@lists.sourceforge.net
Here are the files in our /dspace/config directory that have new appended to the end. Oh and btw, I haven't modified any of them.

dc2mods.cfg.new
default.context.xml.new
default.license.new
input-forms.xml.new
item-submission.xml.new
launcher.xml.new
log4j-handle-plugin.properties.new
news-side.html.new
news-top.html.new
news-xmlui.xml.new
oaicat.properties.new
xmlui.xconf.new
log4j.properties (I renamed the .new already to the current one)

It looks like maybe what's happening is that, since we're upgrading, these modules already existed in our /dspace/config folder and it's comparing the ones in /dspace-source/dspace/config with these, determining they're different, and creating the .new versions.

Sue




Sue Walker-Thornton
Software Developer/Database Administrator
NASA Langley Research Center|LITES Contract
(757) 224-4074



-----Original Message-----
From: Brian Freels-Stendel [mailto:bfr...@unm.edu]
Sent: Wednesday, May 25, 2011 1:01 PM
To: Thornton, Susan M. (LARC-B702)[LITES]
Subject: Re: [Dspace-tech] ClassNotFoundException for org.dspace.app.util.DailyFileAppender under 1.7.1

Hi there,

Now that, I can't remember. I know that it writes the .new or .old files when the particular file in question has been updated...but I don't know if it does the same thing if the file has _not_ been changed. Ideally, it shouldn't, but. I try to always use the overwrite parameter, because I don't have write privs in the deploy directory (yeah, I'm in one of those shops), so I don't have the experience, and the docs are less than fully informative.

B--

>>> On 5/25/2011 at 10:43 AM, in message
Reply all
Reply to author
Forward
0 new messages