how to use "liferay portal workflow kaleo api" in jsf portlet (gradle build project) ? Liferay 7.0

Question

i have use this gradal property "compile group: 'com.liferay', name: 'com.liferay.portal.workflow.kaleo.api', version: '1.0.0'"
on MVC potlate and i have got all data

@Component
public class KaleoTaskInstanceTokenPortlet extends MVCPortlet {
    @Reference
    KaleoTaskInstanceTokenLocalService kaleoTaskInstanceTokenLocalService;

    @Override
    public void render(RenderRequest renderRequest, RenderResponse renderResponse)
        throws IOException, PortletException {
        List<KaleoTaskInstanceToken> instanceToken = kaleoTaskInstanceTokenLocalService
            .getKaleoTaskInstanceTokens(QueryUtil.ALL_POS, QueryUtil.ALL_POS);
        for (KaleoTaskInstanceToken kaleoTaskInstanceToken : instanceToken) {
            System.out.println("=-=-=-=-" + kaleoTaskInstanceToken.getKaleoInstanceId());
        }

    }

}   

but My problem on JSF portlet And I have the same code use in JSF portlet. is not working i have got "kaleoTaskInstanceTokenLocalService" value null..

Answer 1

According to Liferays docs about JSF, you cannot use OSGi-based Declarative Services using @Reference annotations; instead, you'll have to query the Service Tracker yourself:

To call OSGi-based Service Builder services from your JSF portlet, you need a mechanism that gives you access to the OSGi service registry, because you can’t look up services published to the OSGi runtime using Declarative Services. Instead, you should open a ServiceTracker when you want to call a service that’s in the OSGi service registry.

[..]

In a managed bean, whenever you need to call a service, open the service tracker. For example, this is done in the same demo JSF portlet to open the service tracker, using the @PostContruct annotation:

@PostConstruct
public void postConstruct() {
   Bundle bundle = FrameworkUtil.getBundle(this.getClass());
   BundleContext bundleContext = bundle.getBundleContext();
   userLocalServiceTracker = new UserLocalServiceTracker(bundleContext);
   userLocalServiceTracker.open();
}

Then the service can be called:

UserLocalService userLocalService = userLocalServiceTracker.getService();
...

userLocalService.updateUser(user);

When it’s time for the managed bean to go out of scope, you must close the service tracker using the @PreDestroy annotation:

@PreDestroy
public void preDestroy() {
    userLocalServiceTracker.close();
}

There's another piece of information about Service Trackers here, which ends with

There’s a little boilerplate code you need to produce, but now you can look up services in the service registry, even if your plugins can’t take advantage of the Declarative Services component model.

... and JSF portlets do belong in exactly that category, because they're "WAR-style plugins" (as opposed to OSGi bundles, a.k.a. "JAR-style plugins").

In the end, whenever you see any dependency injection that is using an @Reference annotation in any example on the web, you'll need to adapt the aforementioned boilerplate code in your "WAR-style plugins".

If this isn't enough, maybe you've got a wrong module version in your dependencies. I don't have a Liferay 7.0 instance running, but even in the oldest zip file I found, Kaleo API was in version 2.0.0; you, on the other hand, explicitely depend on version 1.0.0, which might be your problem.

You'll need to find out the exact Kaleo API bundle version that is used on the Liferay server you're writing modules for. Open the Gogo shell (Control Panel -> System -> Gogo Shell), which allows you to inspect the running OSGi bundles. Use this command ("list bundles, display their symbolic name, show only lines that contain 'kaleo.api'"):

lb -s | grep kaleo.api

On my Liferay 7.3 that's sitting around here, the output would be:

 5320|Active     |   10|com.liferay.portal.workflow.kaleo.api (6.4.0)|6.4.0

Find out the version your Liferay instance is using, and use that in your build.gradle. For some modules, you need to hit the exact version; for others, you could get away with matching at least the major version.

Note: for newer versions of Liferay (from 7.3.2 onwards, I think), you could configure the target Liferay platform version centrally (which presets all module versions to the versions used in that specific platform version) and escape this dependency hell; see this answer here.