Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
Customizing JournalArticleLocalServiceWrapper class not working
Our custom service wrapper overrides the fetchLatestArticle(long groupId, String articleId, int status) method of JournalArticleLocalServiceWrapper
to return the latest journal article if it meets a condition. The code is attached below.
problem: After testing in two system s, one with FP 32 and other with FP 53; the overriden method works fine and prints the messges in Line #13 & Line #24 but in FP 53 it is not displaying the web content resturned from the custom service wrapper and FP 32 works fine.
Expected Result: In JournalContentPortlet class, when it calls the fetchLatestArticle method of journalArticleLocalService
the custom method in the service wrapper should work and it should return the latest content instead of latest approved content if an expando attribute in the user model is set.
code:
to return the latest journal article if it meets a condition. The code is attached below.
problem: After testing in two system s, one with FP 32 and other with FP 53; the overriden method works fine and prints the messges in Line #13 & Line #24 but in FP 53 it is not displaying the web content resturned from the custom service wrapper and FP 32 works fine.
Expected Result: In JournalContentPortlet class, when it calls the fetchLatestArticle method of journalArticleLocalService
the custom method in the service wrapper should work and it should return the latest content instead of latest approved content if an expando attribute in the user model is set.
code:
@Component(immediate = true, service = ServiceWrapper.class)
public class CustomJournalServiceWrapper extends JournalArticleLocalServiceWrapper {
public CustomJournalServiceWrapper(JournalArticleLocalService journalArticleLocalService) {
super(journalArticleLocalService);
} public CustomJournalServiceWrapper() {
super(null);
}
@Override
public JournalArticle fetchLatestArticle(long groupId, String articleId, int status) {
try {
System.out.println("TEST !");
if (PrincipalThreadLocal.getName() != null) {
long userId = GetterUtil.getLong(PrincipalThreadLocal.getName());
User user = null;
try {
user = UserLocalServiceUtil.getUser(userId);
if (user.getExpandoBridge().hasAttribute("th-view-latestcontent-mode")) {
flag = user.getExpandoBridge().getAttribute("th-view-latestcontent-mode");
if (flag.toString().contains("true")){
JournalArticle article = JournalArticleLocalServiceUtil.getLatestArticle(groupId, articleId);
System.out.println("flag 1");
return article;
}
}
} catch (PortalException e) {
e.printStackTrace();
}
}
} catch (Exception e) {
}
return super.fetchLatestArticle(groupId, articleId, status);
}
@Reference(unbind = "-")
private void serviceSetter(JournalArticleLocalService articleLocalService) {
setWrappedService(articleLocalService);
}
}
You shouldn't have the constructor defined as public CustomJournalServiceWrapper(JournalArticleLocalService journalArticleLocalService), this is not a constructor that OSGi can invoke.
Instead, your constructor should be public CustomJournalServiceWrapper() and, inside the constructor, call super(null);
OSGi will later inject the reference for the JournalArticleLocalService using the "serviceSetter" (which, by Liferay standards, you should make as a real setter, i.e. naming it setJournalArticleLocalService()).
Instead, your constructor should be public CustomJournalServiceWrapper() and, inside the constructor, call super(null);
OSGi will later inject the reference for the JournalArticleLocalService using the "serviceSetter" (which, by Liferay standards, you should make as a real setter, i.e. naming it setJournalArticleLocalService()).
Thanks David, for your time.
The confusing part is, it works in one machine but not in any other machines. Also it's worth mentioning that, when journalContentPortlet class of web content portlet calls fetchLatestArticle, the code reaches here in the overriden method and returns the article we want, but the web content portlet still displays the different one.
You shouldn't have the constructor defined as public CustomJournalServiceWrapper(JournalArticleLocalService journalArticleLocalService), this is not a constructor that OSGi can invoke.I have both constructors like this in the above code. I removed the other one and tried again but didn't work.
Instead, your constructor should be public CustomJournalServiceWrapper() and, inside the constructor, call super(null);
public CustomJournalServiceWrapper(JournalArticleLocalService journalArticleLocalService) {
super(journalArticleLocalService);
}
public CustomJournalServiceWrapper() {
super(null); }
The confusing part is, it works in one machine but not in any other machines. Also it's worth mentioning that, when journalContentPortlet class of web content portlet calls fetchLatestArticle, the code reaches here in the overriden method and returns the article we want, but the web content portlet still displays the different one.
More info: Like I said it was working on one machine which was running on Liferay DXP patch 32. It stopped working after it's upgraded to patch 79.
Vishnu S Kumar:
Have you contacted support on that? (e.g. opened a ticket?)
More info: Like I said it was working on one machine which was running on Liferay DXP patch 32. It stopped working after it's upgraded to patch 79.
They might recognize the problem, in case you're not the first one to observe it.
Alternatively: Have you checked if your dependencies on Liferay-packages wasn't overly specific? You might need to bump your dependencies to a newer version, in case the updates required some updates that your old declared dependencies don't cover.
Thanks Olaf. We are opening a support ticket. But we might have to step back from this approach if it is vulnerable to patch updates as it may causes inconveniences in the future updates.
I checked the dependencies and updates , but it looks fine. The code snippet is done using the reference from this liferay documentation.
Alternatively: Have you checked if your dependencies on Liferay-packages wasn't overly specific? You might need to bump your dependencies to a newer version, in case the updates required some updates that your old declared dependencies don't cover.
I checked the dependencies and updates , but it looks fine. The code snippet is done using the reference from this liferay documentation.
There were changes in what was included in fixpacks starting around FP40, less chance of introducing breaking changes.
It wasn't clear in your post, but it sounds like both systems print out the first message, but only the older fixpack prints out the second message?
It wasn't clear in your post, but it sounds like both systems print out the first message, but only the older fixpack prints out the second message?
In both system (FP 32 & FP 53), it prints out both the messages (Line: #24 & #14). But only the system one shows the expected content( latest web content) at the web content portlet while the second one still shows the default content.(latest published web content). The method in the custom service wrapper works in both machines, but system two (newer FP) is not displaying the web content returned from the custom method in service wrapper (Line #25).
In FP 79, AfterI upgraded my working system (FP 32), none of the messages are printed and it's not taking my custom service wrapper.
In FP 79, AfterI upgraded my working system (FP 32), none of the messages are printed and it's not taking my custom service wrapper.
I'll update my question detail to make it clearer
It wasn't clear in your post, but it sounds like both systems print out the first message, but only the older fixpack prints out the second message?
Okay, so here's some suggestions...
1. You have journal local service injected into your instance, so why use JournalArticleLocalServiceUtil on line #23?
2. You shouldn't use UserLocalServiceUtil on line #19, instead you should @Reference inject it into a member variable.
3. You're swallowing the exception on line #32; you should probably be dumping that too.
4. It's really bad practice to use System.out.println(); you're building a java servlet app, just use a logger like you know you should.
5. I would say if FP32 is getting latest (unpublished) web content in line #23, then this was a bug that was fixed. The general get methods should always return the published content, if you need a non-published content there are different methods that accept the workflow status that you want to include.
6. For FP79, this points to either the bundle or component issues. You'll need to use the gogo shell to diagnose if your bundle is started and if the component in the bundle is also started.
1. You have journal local service injected into your instance, so why use JournalArticleLocalServiceUtil on line #23?
2. You shouldn't use UserLocalServiceUtil on line #19, instead you should @Reference inject it into a member variable.
3. You're swallowing the exception on line #32; you should probably be dumping that too.
4. It's really bad practice to use System.out.println(); you're building a java servlet app, just use a logger like you know you should.
5. I would say if FP32 is getting latest (unpublished) web content in line #23, then this was a bug that was fixed. The general get methods should always return the published content, if you need a non-published content there are different methods that accept the workflow status that you want to include.
6. For FP79, this points to either the bundle or component issues. You'll need to use the gogo shell to diagnose if your bundle is started and if the component in the bundle is also started.
Thanks for the suggestions:
- I tried using super.fetchLatestArticle(...) and the injected journal local service at line #23 but none of them worked.So I was experimenting with the JournalArticleLocalServiceUtil.
- Sure, I'll update that way.
- & 4 . This code was meant to show a sample, in actual scenario I am using the proper logs
- ----
- In FP 32 and FP 53, it returns the unpublished latest content at line #23 , but in FP 53 it displays the published content in the web content portlet even if line #23 returns the unpublished content.
- In FP 79, I verified that both the bundle and all its components are started.
Copyright © 2025 Liferay, Inc
• Privacy Policy
Powered by Liferay™