Of course yes, but nothing prevent you for deletion this standard listener at startup.

Right, but when you restart Jira I think the DefaultMailListener is recreated if it is not present?

Sure, https://docs.atlassian.com/software/jira/docs/api/7.2.2/com/atlassian/jira/event/ListenerManager.html#deleteListener-java.lang.Class-

And in your listener:
@Override
public void init(Map params)

But can you delete the DefaultMailListener?

Maybe it is time to close this issue as there is now com.atlassian.jira.event.ListenerManager#deleteListener

Um, for what its worth, I approached this by (a) getting the project to remove its reference to the notification scheme, (b) using my own issue listener, hooked up to the users re-selection of said notification scheme through my plugin. As JIRA is not aware, the result is the same.

I don't think this is going to happen. It might one day if JIRA PMs revisited the whole mail infrastructure in JIRA - some projects need best-effort, immediate notification (think IM, SMS). Others need reliable email. Both need ways to reduce the number of notifications people get. I see a lot of filtering of JIRA messages out there.

Hmm, 4.4 EAP? seeing as not in 4.4, maybe 4.5? fingers crossed, again.

I'm upgrading a customer and one of their custom plugins needs this. I'm providing a patched system class to avoid it, which isn't very good practice.

Just making ConsistencyCheckImpl not check isn't the only thing that needs doing. Some part of the install process would need to do the initial setup of listener. Subsequent deletion (and somehow notifying the admin of this) could be handled a bunch of ways. Fingers crossed for 4.2.1

Technically, this issue's summary should read "Unable to stop JIRA recreating the default/internal Mail Listener", since it can be deleted via a URL. It would be worth checking whether that last assumption is still true in 4.2.

So, not in 4.2, bah. 4.2.1? please?

It's a right pain to do custom mail listeners with this problem in existence.

Fix for 4.1.x still? Jira 4.2 imminent, any comment on when this may be done?

Darn. Unassigned... that'll be /dev/null

Yea +1 to this, In order to install JIRA Notification Digester I have to give people pre-modified classes, all because users might delete one listener? Surely it would be fine if it was a 'built-in' listener that could be re-added if they deleted it in a fit of pique!? how many other features are hard wired in case of 'senior moments'? Given plugins etc, I can't see the case for not enabling this listener to be removed by system admins if they so require.

Sigh, back to the auto-patching SED script :[

I want to have a custom class for the Mail Listener to handle conditional notifications. I can prevent duplicate emails after adding my custom listener by deleting the system Mail listener with a URL such as: http://jira/secure/admin/jira/ViewListeners.jspa?delete=10001
I find the id for the system Mail Listener in an XML backup file or in the database listenersconfig table. That all works fine but then the ConsistencyCheckImpl class goes and readds the Mail Listener the next time JIRA restarts. Sigh. I guess the quickest change to allow this behaviour to be disabled would probably be to add a property to jira-application.properties or -Djira.option.recreatemaillistener and change ConsistencyCheckImpl thus:

    private void checkMailListenerAndService() throws Exception
    {
        if ("true".equals((ManagerFactory.getApplicationProperties()).getString(APKeys.JIRA_OPTION_RECREATEMAILLISTENER)))
        {
            ensureSingleListener("com.atlassian.jira.event.listeners.mail.MailListener", "Mail Listener");
        }
        ensureSingleService("com.atlassian.jira.service.services.mail.MailQueueService", "Mail Queue Service");
    }

I can't see any other way to stop this happening other than recompiling MailListener.java which is a bigger pain to maintain over upgrades.

I cloned this issue rom JRA-8743 since it's the same idea.

~Matt