Liferay DXP’s static utility functions (e.g., UserServiceUtil,
CompanyServiceUtil, GroupServiceUtil, etc.) are examples of non-OSGi code
that use OSGi services.
Note that it’s safer to track and use Liferay DXP’s OSGi services directly with
Liferay DXP’s Registry API than to invoke Liferay DXP’s similar static utility
functions. For example, you can’t call an OSGi service unless all its
dependencies are satisfied: the container won’t enable the service. If you
invoke Liferay DXP’s static utility functions, you might invoke them prematurely
(e.g., before OSGi bundle activation and application startup events). You could
work around this by identifying all of the implied OSGi service dependencies and
making sure they are satisfied before invocation, but then you’re not only
duplicating the container’s more robust functionality for this, you’re also
creating a bigger surface for bugs. Avoid this mess by using Liferay DXP’s
Registry API to track the services you want. This way, you let OSGi
make sure a service’s dependencies are satisfied before invoking that service.
For example, use Liferay DXP’s OSGi service UserService instead of
UserServiceUtil, which in turn uses the OSGi service UserService.
Click here
to see an example of this.
Remember that you can check the state of Liferay DXP’s services in
the Gogo shell.
If you’re running Liferay DXP locally, use the command telnet localhost 11311 to
connect to the Gogo shell. Once connected, the scr:list command shows all
Declarative Services components, including inactive ones from unsatisfied
dependencies. To find unsatisfied dependencies for Service Builder services, use
the Dependency Manager’s dependencymanager:dm wtf command. Note that these
commands only show components that haven’t been activated because of unsatisfied
dependencies–they don’t show pure service trackers that are waiting for a
service because of unsatisfied dependencies.
Related Topics
Using OSGi Services from EXT Plugins