-
Type:
Suggestion
-
Resolution: Fixed
-
Component/s: Infrastructure & Services - Application Lifecycle
-
None
We had a problem on WAS 5.1 where a transitive dependency on internal com.sun SSL provider classes prevented JIRA from initialising.
WAS made it worse because it "lost" the root cause exception and failed to log anything, and neither did JIRA.
All our context listeners should use a catch / log/ rethrow pattern so at least we know in the jira-atlassian.log when really bad stuff has happened.
They are as follows:
<listener>
<listener-class>com.atlassian.jira.appconsistency.db.DatabaseCompatibilityEnforcer</listener-class>
</listener>
<!-- Check consistency of database etc -->
<listener>
<listener-class>com.atlassian.jira.upgrade.ConsistencyLauncher</listener-class>
</listener>
<!-- Check for upgrades, and automatically perform them if neccessary. -->
<listener>
<listener-class>com.atlassian.jira.upgrade.UpgradeLauncher</listener-class>
</listener>
<!-- Launch the scheduler, which loads all the jobs from scheduler-config.xml -->
<listener>
<listener-class>com.atlassian.jira.scheduler.JiraSchedulerLauncher</listener-class>
</listener>
<!-- XML-RPC / SOAP Listener -->
<listener>
<listener-class>com.atlassian.jira.soap.axis.JiraAxisHttpListener</listener-class>
</listener>