I trying to modify JournalArticle assets (need to set categories depending of article layout parents). I managed to implement ModelListener for JournalArticle. In method onAfterUpdate() I have JournalArticleLocalServiceUtil.updateAsset().
In logs everything is fine. I have needed category id in parameters, but it doesn’t appear in categories list in article when I open article editor in the next time.
Is it possible to save changes in model from ModelListener somehow or it’s just for monitoring and I can’t modify model from this listener?
Code (reduced version):
package mypackage;
// imports
public class JournalArticleListener implements ModelListener {
private void updateCategories(JournalArticle article) {
try {
long[] categoriesArray = getCategories(article); // this works fine
String[] tagsArray = getTags(article); // this also works fine
JournalArticleLocalServiceUtil.updateAsset(article.getUserId(), article, categoriesArray, tagsArray);
} catch (PortalException ex) {
// logger
} catch (SystemException ex) {
// logger
}
}
@Override
public void onBeforeUpdate(Object model) throws ModelListenerException {
updateCategories((JournalArticle)model);
}
// other abstract method implemented without any code inside
}
in liferay-hook.xml I have
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hook PUBLIC "-//Liferay//DTD Hook 6.0.0//EN" "http://www.liferay.com/dtd/liferay-hook_6_0_0.dtd">
<hook>
<model-listener>
<model-listener-class>mypackage.JournalArticleListener</model-listener-class>
<model-name>com.liferay.portlet.journal.model.JournalArticle</model-name>
</model-listener>
</hook>
As far as I can tell, your code looks fine but I can think of a few things you could try. Please let me know if this worked for you.
First. check to see if the article is approved. If the article is in the draft state the data won’t reflected until it is approved.
Second. Instead of using a model listener try overwriting the service with the hook instead.
You’ll need to implement its service wrapper,
JournalArticleServiceWrapper.Overwrite the update methods (there could be several) and call its parent method then do your logic. Like so:
Doing it by model listeners is definitely easier. Though I’m not sure that this is the actual problem, it maybe that there is an issue using onAfterUpdate to update the model since an infinite loop could be created.