Best Practice Recommendation For Overriding Default Liferay Mail Engine

Message Boards

Christopher Dawson, modified 2 Years ago.

Best Practice Recommendation For Overriding Default Liferay Mail Engine

New Member Posts: 11 Join Date: 2/27/12 Recent Posts

Hello Liferay Dev Community:

Migration question with regards to Liferay's mail engine.

In 6.2.x I was able to override the mail system to leverage an third party API (not SMTP) based system - Postmark.
This required an ext plugin that contained overrides for mail-spring.xml, MailEngine, MailServiceImpl, MailMessageListener & MailMesssage

I am attempting to provide the same functionality in our 7.3.x deployment. However I am uncertain of the best approach here given that I am running into road blocks no matter which solution I attempt. So far I have tried:

EXT Plugin - created via the war-core-ext blade template in Liferay Workspace.
1. Main issue here is that the newly created plugin project gets an immediate build error which prevents me from even compiling code.
2. I also cannot find a way to introduce libraries into this project. In 6.2.x I was able to use the liferay-plugin-package.properties file to incorporate dependencies from the server's libraries. This no longer appears to be functioning.
EXT Module - created via the Module Ext Project blade template in Liferay Workspace
1. While I'm able to specify apps.petra.petra-mail as the original module to override - I am unable to get my module project to compile and deploy to my local development server
Service Wrapper - also created via Liferay Workspace blade template
1. portal-impl/src/com/liferay/mail/messaging/MailMessageListener.java is not defined as an OSGI component (since it is instantiated via Spring in the mail-spring.xml file). I cannot retrieve anything related to it via the GoGo shell. So this prevents me from overriding it via the recommended OSGI Service ranking approach

Bottom line: the Liferay mail engine is stil being instantiated by Spring and not (as far as I can tell) being exposed as an OSGI service.

Should I be continuing to look at either options 1 or 2 above (since option 3 seems like a dead end)? Or is there some other option out there?

Thanks in advance for any help/suggestions!!

Note: I am aware that Postmark offers an SMTP approach - however some of the advanced functionality that we wish to utilize is only exposed via their API - not over SMTP.

Olaf Kock, modified 2 Years ago.

RE: Best Practice Recommendation For Overriding Default Liferay Mail Engine

Liferay Legend Posts: 6403 Join Date: 9/23/08 Recent Posts

I haven't tried overriding the mail engine, but the first place I'd look at is the Message Queue: AFAIK mails are sent/handled through the queue, and if you manage to get a queue-listener that is triggered before/instead of Liferay's default implementation, you'd have what you need. That should be possible through OSGi - but again: I have no experience doing so, just a vague expectation about this direction being workable

Dominik Marks, modified 2 Years ago.

RE: Best Practice Recommendation For Overriding Default Liferay Mail Engine

Regular Member Posts: 149 Join Date: 8/29/12 Recent Posts

As far as I know Liferay uses the MessageBus to send mails. The destination is called "liferay/mail". If you create your own listener for that destination and replace the existing one you should be able to handle all mail sending.

Pseudo-Code (derived from a real project):

@Component(
    immediate = true,
    service = CustomMailMessageListener.class
)
public class CustomMailMessageListener extends MailMessageListener {

    @Reference(target = "(destination.name=liferay/mail)")
    private Destination destination;

    private List<MessageListener> messageListeners;


    @Activate
    @Modified
    protected void activate(Map<String, Object> properties) {
        this.messageListeners = new ArrayList<>(this.destination.getMessageListeners());

        this.destination.unregisterMessageListeners();

        this.destination.register(this);
    }

    @Deactivate
    protected void deactivate(Map<String, Object> proprties) {
        this.destination.unregisterMessageListeners();

        for (MessageListener messageListener : messageListeners) {
            this.destination.register(messageListener);
        }
    }

    @Override
    protected void doMailMessage(MailMessage mailMessage) throws Exception {
		...

		CustomMailEngine.send(mailMessage);
    }
}

Christopher Dawson, modified 2 Years ago.

RE: Best Practice Recommendation For Overriding Default Liferay Mail Engine

New Member Posts: 11 Join Date: 2/27/12 Recent Posts

Thank you both for your comments/suggestions. I will give the MessageBus destination override a try.

I think I got hung up on the idea that since the mail framework was still initialized by Spring - I was out of options for cleanly leveraging OSGI to do the override.

Thanks again!