[
https://issues.jboss.org/browse/JBWEB-232?page=com.atlassian.jira.plugin....
]
Kyle Lape updated JBWEB-232:
----------------------------
Attachment: dummyContextListener.war.zip
I'm attaching a simple project that shows this problem. If you deploy this, no
application error will be displayed in the server.log, but if you add
{{-Dorg.jboss.as.logging.per-deployment=false}} it will show the desired exception
Allow StandardContext to expose start problems to callers instead of
logging them
---------------------------------------------------------------------------------
Key: JBWEB-232
URL:
https://issues.jboss.org/browse/JBWEB-232
Project: JBoss Web
Issue Type: Enhancement
Security Level: Public(Everyone can see)
Affects Versions: JBossWeb-7.0.10.GA
Reporter: Brian Stansberry
Assignee: Remy Maucherat
Attachments: dummyContextListener.war.zip
See discussion of the log.txt attached to AS7-2322. That JIRA is about how AS7 handles
exceptions, but in the case of the example the user attached, there is not much the AS can
do. StandardContext is catching any exceptions that occur, logging at error, and then
discarding the exception.
I can see how this behavior might be appropriate for some usages, e.g. standalone Tomcat.
And the logic after an exception is caught is complex, so I can see why just throwing a
LifecycleException is not an option. But is it possible to have a configuration property
on StandardContext such that instead of logging and discarding exceptions, it would *not*
log them and retain the exception so the caller to start() could access it? Or perhaps
throw it on in a LifecycleException at the end? Basically some mechanism such that the
AS' WebDeploymentService could take responsibility for reporting the exception.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira