-
Bug
-
Resolution: Fixed
-
Medium
-
9.2.0, 9.3.0, 9.4.0, 9.5.0, 9.4.1, 9.4.2
-
9.02
-
7
-
Severity 3 - Minor
-
48
-
Issue Summary
It is not possible to save an Outgoing Mail configuration in Jira using the JNDI Location setting. When clicking on the Save button after testing the connection, the user is redirected to the Oops error page, with the error Sorry, we had some technical problems during your last operation:
Environment
This bug impacts any Jira Server/Data Center version from 9.2.0.
Steps to Reproduce
I was able to replicate the same issue on my side, by configuring an Outgoing Mail server from a JDNI location, on Jira 9.4.1.
- Install Jira 9.4.1
- Edit the server.xml file by adding the <Resource> section within the <Context> section, including the SMTP mail server parameters:
<Resource name="mail/Office365SmtpServer" auth="Container" type="javax.mail.Session" mail.smtp.host="smtp" mail.smtp.port="1025" mail.transport.protocol="smtp" mail.smtp.auth="false" />
- Restart Jira
- Go ⚙ > System > Outgoing Mail, to configure the SMTP Mail Server
- Tick the Enabled option under JNDI Location, and add the following to the JNDI field
java:comp/env/mail/Office365SmtpServer
- Test the connection and verify that it is successful
- Try to save the configuration
Expected results
The saving of the configuration should be successful, and the mail server should be showing in the Outgoing Mail Server page:
Actual results
The saving fails, and the user is redirected to a 500 error page, showing the following error:
java.lang.NullPointerException at com.atlassian.jira.plugins.mail.webwork.AddMailServer.doExecute(AddMailServer.java:84) [?:?] at webwork.action.ActionSupport.execute(ActionSupport.java:165) [webwork-1.4-atlassian-30.jar:?] at com.atlassian.jira.web.action.JiraWebActionSupport.execute(JiraWebActionSupport.java:1364) [jira-api-9.4.1.jar:?] at webwork.interceptor.DefaultInterceptorChain.proceed(DefaultInterceptorChain.java:39) [webwork-1.4-atlassian-30.jar:?] at webwork.interceptor.NestedInterceptorChain.proceed(NestedInterceptorChain.java:31) [webwork-1.4-atlassian-30.jar:?] at webwork.interceptor.ChainedInterceptor.intercept(ChainedInterceptor.java:16) [webwork-1.4-atlassian-30.jar:?] at webwork.interceptor.DefaultInterceptorChain.proceed(DefaultInterceptorChain.java:35) [webwork-1.4-atlassian-30.jar:?] at webwork.dispatcher.GenericDispatcher.executeAction(GenericDispatcher.java:225) [webwork-1.4-atlassian-30.jar:?] at webwork.dispatcher.GenericDispatcher.executeAction(GenericDispatcher.java:154) [webwork-1.4-atlassian-30.jar:?] at com.atlassian.jira.web.dispatcher.JiraWebworkActionDispatcher.service(JiraWebworkActionDispatcher.java:141) [classes/:?] at javax.servlet.http.HttpServlet.service(HttpServlet.java:779) [servlet-api.jar:4.0.FR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227) [catalina.jar:9.0.68] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) [catalina.jar:9.0.68] at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) [tomcat-websocket.jar:9.0.68] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189) [catalina.jar:9.0.68] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) [catalina.jar:9.0.68] at com.atlassian.jira.web.filters.JiraLastFilter.lambda$doFilter$0(JiraLastFilter.java:39) [classes/:?] at com.atlassian.jira.web.filters.steps.ChainedFilterStepRunner.doFilter(ChainedFilterStepRunner.java:74) [classes/:?] at com.atlassian.jira.web.filters.JiraLastFilter.doFilter(JiraLastFilter.java:36) [classes/:?] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189) [catalina.jar:9.0.68] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) [catalina.jar:9.0.68] at com.atlassian.core.filters.HeaderSanitisingFilter.doFilter(HeaderSanitisingFilter.java:37) [atlassian-core-8.0.0.jar:?] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189) [catalina.jar:9.0.68] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) [catalina.jar:9.0.68] at com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:39) [atlassian-plugins-servlet-7.1.2.jar:?] at com.atlassian.plugin.servlet.filter.DelegatingPluginFilter.lambda$doFilter$0(DelegatingPluginFilter.java:57) [atlassian-plugins-servlet-7.1.2.jar:?] at com.atlassian.jira.onboarding.postsetup.ui.PostSetupAnnouncementsFilter.doFilter(PostSetupAnnouncementsFilter.java:53) [?:?] at com.atlassian.plugin.servlet.filter.DelegatingPluginFilter.doFilter(DelegatingPluginFilter.java:62) [atlassian-plugins-servlet-7.1.2.jar:?]
The same error can be found in the Jira application logs:
2023-01-19 09:26:27,335+0000 http-nio-8080-exec-7 ERROR [o.a.c.c.C.[.[localhost].[/jira].[action]] Servlet.service() for servlet [action] in context with path [/jira] threw exception [java.lang.NullPointerException] with root cause java.lang.NullPointerException at com.atlassian.jira.plugins.mail.webwork.AddMailServer.doExecute(AddMailServer.java:84) at webwork.action.ActionSupport.execute(ActionSupport.java:165) at com.atlassian.jira.web.action.JiraWebActionSupport.execute(JiraWebActionSupport.java:1364) at webwork.interceptor.DefaultInterceptorChain.proceed(DefaultInterceptorChain.java:39) at webwork.interceptor.NestedInterceptorChain.proceed(NestedInterceptorChain.java:31) ... 5 filtered at javax.servlet.http.HttpServlet.service(HttpServlet.java:779) ... 48 filtered at com.atlassian.greenhopper.jira.filters.ClassicBoardRouter.doFilter(ClassicBoardRouter.java:56) ... 7 filtered at com.atlassian.jira.plugin.mobile.web.filter.MobileAppRequestFilter.doFilter(MobileAppRequestFilter.java:59) ... 4 filtered at com.atlassian.jira.plugin.mobile.login.MobileLoginSuccessFilter.doFilter(MobileLoginSuccessFilter.java:54) ... 3 filtered at com.atlassian.diagnostics.internal.platform.monitor.http.HttpRequestMonitoringFilter.doFilter(HttpRequestMonitoringFilter.java:54) ... 8 filtered at com.atlassian.web.servlet.plugin.request.RedirectInterceptingFilter.doFilter(RedirectInterceptingFilter.java:21) ... 48 filtered at com.atlassian.oauth2.scopes.web.ReadWriteScopeFilter.doFilter(ReadWriteScopeFilter.java:46) ... 3 filtered at com.atlassian.troubleshooting.thready.filter.AbstractThreadNamingFilter.doFilter(AbstractThreadNamingFilter.java:46) ... 21 filtered at com.atlassian.jira.security.JiraSecurityFilter.lambda$doFilter$0(JiraSecurityFilter.java:66) ... 1 filtered at com.atlassian.jira.security.JiraSecurityFilter.doFilter(JiraSecurityFilter.java:64) ... 16 filtered at com.atlassian.pats.web.filter.TokenBasedAuthenticationFilter.doFilter(TokenBasedAuthenticationFilter.java:82) ... 3 filtered at com.atlassian.oauth2.provider.core.web.AccessTokenFilter.doFilter(AccessTokenFilter.java:81) ... 26 filtered at com.atlassian.jira.servermetrics.CorrelationIdPopulatorFilter.doFilter(CorrelationIdPopulatorFilter.java:30) ... 5 filtered at com.atlassian.plugins.authentication.impl.basicauth.filter.DisableBasicAuthFilter.doFilter(DisableBasicAuthFilter.java:70) ... 8 filtered at com.atlassian.web.servlet.plugin.request.RedirectInterceptingFilter.doFilter(RedirectInterceptingFilter.java:21) ... 4 filtered at com.atlassian.troubleshooting.thready.filter.AbstractThreadNamingFilter.doFilter(AbstractThreadNamingFilter.java:46) ... 3 filtered at com.atlassian.web.servlet.plugin.LocationCleanerFilter.doFilter(LocationCleanerFilter.java:36) ... 29 filtered at com.atlassian.jira.servermetrics.MetricsCollectorFilter.doFilter(MetricsCollectorFilter.java:25) ... 25 filtered at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191) at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.base/java.lang.Thread.run(Thread.java:829)
Note
This bug was actually created by the introduction of the Oauth 2.0 authentication method for the Outgoing Mail Configuration, in Jira 9.2.0 as per this feature request.
Workaround
- Create a new outgoing mail server via the page ⚙ > System > Outgoing Mail
- In the mail server form:
- fill in the fields Name, From Address, Email Prefix
- select Basic Authentication as the Authentication Method (keep the username and password fields empty)
- tick the Enabled option under JNDI Location
- fill in the field JNDI Location
- Click on the Test Connection button, and verify that the test is successful
- If the test connection is successful
- Open the Browser Dev Tool
- Click on the tab on the far left (the one with the square and arrow icons)
- Click on "SMTP" next to the Protocol field
- Clear the word disabled next to protocol_select and press enter:
- Repeat the same steps with the Authentication Method field (remove the disabled word and press enter)
- Click on Save and authorize and verify that the configuration was successfully saved
- is caused by
-
JRASERVER-72166 As a Jira Administrator I want to configure OAuth 2.0 for Outgoing mail (SMTP)
- Closed
- is related to
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
JSEV-3214 Loading...
-
- was cloned as
-
(4 mentioned in, 1 was cloned as)