Customizing JournalArticleLocalServiceWrapper class not working

Vishnu S Kumar, modified 6 Years ago. Regular Member Posts: 131 Join Date: 7/28/17 Recent Posts
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:
 @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);
    }
}
 
thumbnail
David H Nebinger, modified 6 Years ago. Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts
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()).
Vishnu S Kumar, modified 6 Years ago. Regular Member Posts: 131 Join Date: 7/28/17 Recent Posts
Thanks David, for  your time.
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);
I have both constructors like this in the above code.  I removed the other one and tried again but didn't work.

    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.
Vishnu S Kumar, modified 6 Years ago. Regular Member Posts: 131 Join Date: 7/28/17 Recent Posts
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.
thumbnail
Olaf Kock, modified 6 Years ago. Liferay Legend Posts: 6441 Join Date: 9/23/08 Recent Posts
Vishnu S Kumar:

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.
Have you contacted support on that? (e.g. opened a ticket?)
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.
Vishnu S Kumar, modified 6 Years ago. Regular Member Posts: 131 Join Date: 7/28/17 Recent Posts
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.

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.
thumbnail
David H Nebinger, modified 6 Years ago. Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts
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?
Vishnu S Kumar, modified 6 Years ago. Regular Member Posts: 131 Join Date: 7/28/17 Recent Posts
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.


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?
I'll update my question detail to make it clearer
thumbnail
David H Nebinger, modified 6 Years ago. Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts
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.
Vishnu S Kumar, modified 6 Years ago. Regular Member Posts: 131 Join Date: 7/28/17 Recent Posts
Thanks for the suggestions:
  1.  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.
  2.  Sure, I'll update that way.
  3. &  4 . This code was meant to show a sample, in actual scenario I am using the proper logs
  4. ----
  5.  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.
  6. In FP 79, I verified that both the bundle and all its components are started.