[MAGNOLIA-2711] Failure to resolve class when finishing installation leads to 404 page being displayed after installation Created: 04/May/09  Updated: 03/Dec/13  Resolved: 03/Dec/13

Status: Closed
Project: Magnolia
Component/s: updatemechanism
Affects Version/s: 4.0.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jan Haderka Assignee: Magnolia International
Resolution: Outdated Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File stacktrace.txt    
Issue Links:
dependency
depends upon MAGNOLIA-1670 Updatemech : review exception handlin... Closed
relation
is related to MAGNOLIA-2552 FactoryUtil: newInstance() method sho... Closed
is related to MAGNOLIA-2743 startup: don't fail to start the syst... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

Stacktrace attached. Hitting the back button and clicking on "Start Magnolia" button again leads to admin interface being displayed (on author) as expected. The exception in UI appears most likely because initialization is not finished yet. We should either postpone those or make sure some better page is displayed then default tomcat's 404.



 Comments   
Comment by Magnolia International [ 05/May/09 ]

Is this what you had ?

2009-05-05 15:41:22,223 ERROR .[localhost].[/magnolia-empty-webapp-4.1-SNAPSHOT]: Exception sending context initialized
___ event to listener instance of class info.magnolia.cms.servlets.MgnlServletContextListener
java.lang.IllegalStateException: Can't instantiate an implementation of this class 
___ [info.magnolia.imaging.filters.text.TextOverlayImageFilter]: InstantiationException: 
	at info.magnolia.cms.util.FactoryUtil.newInstance(FactoryUtil.java:124)
	at info.magnolia.content2bean.impl.Content2BeanTransformerImpl.newBeanInstance(Content2BeanTransformerImpl.java:325)
	at info.magnolia.content2bean.impl.Content2BeanProcessorImpl.toBean(Content2BeanProcessorImpl.java:103)
	at info.magnolia.content2bean.impl.Content2BeanProcessorImpl.toMap(Content2BeanProcessorImpl.java:173)
	at info.magnolia.content2bean.impl.Content2BeanProcessorImpl.toBean(Content2BeanProcessorImpl.java:101)
	at info.magnolia.content2bean.impl.Content2BeanProcessorImpl.toMap(Content2BeanProcessorImpl.java:173)
	at info.magnolia.content2bean.impl.Content2BeanProcessorImpl.setProperties(Content2BeanProcessorImpl.java:140)
	at info.magnolia.content2bean.Content2BeanUtil.setProperties(Content2BeanUtil.java:204)
	at info.magnolia.content2bean.Content2BeanUtil.setProperties(Content2BeanUtil.java:194)
	at info.magnolia.module.ModuleManagerImpl.populateModuleInstance(ModuleManagerImpl.java:387)
	at info.magnolia.module.ModuleManagerImpl.startModules(ModuleManagerImpl.java:312)
	at info.magnolia.module.ui.ModuleManagerWebUI.onStartup(ModuleManagerWebUI.java:80)
	at info.magnolia.cms.beans.config.ConfigLoader.load(ConfigLoader.java:108)
	at info.magnolia.cms.servlets.MgnlServletContextListener$2.exec(MgnlServletContextListener.java:177)
	at info.magnolia.context.MgnlContext.doInSystemContext(MgnlContext.java:377)
	at info.magnolia.cms.servlets.MgnlServletContextListener.startServer(MgnlServletContextListener.java:175)
	at info.magnolia.cms.servlets.MgnlServletContextListener.contextInitialized(MgnlServletContextListener.java:171)

This just happened to me while restarting an instance that add a module's configuration referring to a class i renamed (and/or made abstract) while developing.

The 404 is "only" a side effect of the whole app not being started at all.
With MAGNOLIA-1670, we could maybe introduce a way to "disable" modules when their loading fails.ยจ

This one is probably happening since we fixed MAGNOLIA-2552; which is fine, but really calls for MAGNOLIA-1670 to be taken care of too.

Comment by Jan Haderka [ 05/May/09 ]

Nope, that's not it. What happened for me is that registration of paragraph failed with exception and that triggered another exception (actually NPE) from log4j (the log file it was trying to write into was null) since it was not initialized yet and as a result I got 404 on the page. But after reloading the page normal login window popped up. The instance was running, it didn't shut down. I thought I can reproduce it always, but unfortunately that is not the case, even with that broken paragraph in place i was not able to get the exception any more so I assume it is some weird race condition during initialization.

Comment by Jan Haderka [ 12/May/09 ]

Finally got the stacktrace again. And as a matter of fact I don't think it is related to error in installation (tho i had one as well this time), but I rather think it is a race condition on initialization.

Comment by Jan Haderka [ 12/May/09 ]

Actually it is a race condition when an error occurs on startup. The issue occurs when there is an exception thrown during module initialization before log4j is initialized.

Comment by Magnolia International [ 13/May/09 ]

Hmm, that's interesting, I think I've had that one too. Is (part of) log4j's initialization happening asynchronously ?

Comment by Jan Haderka [ 13/May/09 ]

Can't think of any other explanation. Probably related to the AsyncAppender we use. See WEB-INF/config/default/log4j.xml

  <appender name="log-debug" class="org.apache.log4j.AsyncAppender">

There is also similar issue with log4j 1.1 (closed as won't fix, because of being outdated)
https://issues.apache.org/bugzilla/show_bug.cgi?id=14926

Comment by Magnolia International [ 13/May/09 ]

Makes sense.
Can we reproduce this? (outside Magnolia, just by directly poking at log4j) If so, I'd suggest we reopen this log4j bug !

Comment by Magnolia International [ 25/May/09 ]

This issue needs to be split in 2. The issue I had is related to MAGNOLIA-2552 and MAGNOLIA-2743.
The log4j issue is likely very different - would need a way to reproduce.

Comment by Magnolia International [ 25/May/09 ]

The attach stacktrace emanates from WriterAppender - which indicates this could be thrown before our actual "custom" log4j configuration - we first let log4j be configured from core:/log4j.xml, which uses ConsoleAppender (which is a WriterAppender subclass, unlike AsyncAppender)

Furthermore, line 140 of java.io.Writer my jdk6 source would indicate the NPE would be caused when attempting to write a null String; this would surprising, I'd assume log4j takes care of that. My jdk5 copy doesn't have any relevant source for NPEs at java.io.Writer:140.

Comment by Jan Haderka [ 03/Dec/13 ]

Closing as it doesn't seem to be reproducible in recent versions of Magnolia. If you happen to run across this issue again, pls reopen with description on how to reproduce and exact version numbers.

Generated at Mon Feb 12 03:39:21 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.