Uploaded image for project: 'PUBLIC - Liferay Documentation'
  1. PUBLIC - Liferay Documentation
  2. LRDOCS-6935

LPS: Converting a Service Builder module from Spring DI to OSGi DS


    • Type of Documentation:
      Developer: Development Frameworks


      Add ServiceBuilder property to generate service modules without using spring.

      Adds a new service-builder attribute "dependency-injector" which specifies which dependency injector to use. Valid values are "spring" and "ds". For new OSGi modules, the default value is "ds", for existing modules or WARs, the default value is "spring".

      The main reason for doing this is to reduce the amount of knowledge required for new developers to understand how to use Liferay and the service builder. By making everything DS instead of partially DS and partially Spring new developers don't need to ever think or learn about how spring works or how to use it within a service builder bundle.

      Using "ds" will regenerate the module using DS Component annotations and wire everything together using DS. Doing so is incompatible with using any spring.xml files in the module but allows developers to choose how they want to build their services.

      Upgrading a service module to use DS requires manual changes to the non-generated classes that are spring bean before regenerating the service. Any service modules using setting dependency-injector="ds" will need to enable the DS annotation option for inherited dependencies, this can be done by adding the following to the bnd file:

      -dsannotations-options: inherit

      Additionally this creates a compile dependency on AOP api module:


      Service modules with high coupling between services may be difficult to migrate to using DS. This is because Spring allows circular dependencies between beans, while DS does not. However, migrating can improve code quality by forcing a module to have lower coupling and remove confusion over startup lifecycle differences between DS and Spring.

      Here are the steps to manually modify a service module to use dependency-injector="ds"

      1. Add the DS annotation option for inherited dependencies
      2. Update build to include com.liferay.portal.aop.api
      3. For each non-generated spring bean do the following:
        1. Set the Component annotation on the *Impl class
          1. If the Impl class is a finder, then use the Finder's interface as the service Component(service = MyFinder.class)
          2. If the Impl class is a remote or local service, then use the AopService interface Component(service = AopService.class)
          3. Set the the Component property attribute on remote and local services
            1. For remote services set the "json.web.service.context.name" and "json.web.service.context.path" properties to enable json web services the values can be found in OSGiBeanProperties in the remote service interface before regenerating
            2. For local services set the "model.class.name" property to enable PersistedModelLocalService service tracking, the value is the full class name of the service entity
        2. Replace all service ServiceReference and BeanReference annotations on fields with DS Reference annotations
      4. Regenerate the service after setting dependency-injector="ds" in the service.xml
      5. Replace all manual afterPropertiesSet() and destory() methods with activate() and deactivate() methods and annotate them with Activate and Deactivate DS annotations
      6. Some references will no longer be generated to avoid causing circular dependencies withing a service module, these can be easily added back by adding the necessary fields to the ServiceImpl with DS Reference annotations to resolve compile failures
      7. Deploy the service module and start the portal
      8. Run system:check in the gogo shell to confirm there are no circular service dependencies
      9. If there are components that are not resolving the most likely issue is circular dependencies between local services using scr:info <component.name> in the gogo shell can help in understanding where the easiest place is to break the dependency circle


          Issue Links



              james.hinkey James Hinkey
              richard.sezov Rich Sezov
              Participants of an Issue:
              0 Vote for this issue
              0 Start watching this issue



                  Zendesk Support


                    Version Package