Liferay DXP ServiceBuilder Tips

  1. Use for creating DAO / POJOs / SQL scripts  based on  service.xml.
  2. Internally uses spring and hibernate .
  3. Manages Database connection pool internally.
  4. The basic operations of create, read, update, delete (CRUD) operations


  • Service Builder Generate 

-api 

IT MAINLY CONSISTS OF INTERFACES


-service

IT MAINLY CONSISTS OF implementations




Note: *Util classes are generated for backwards compatibility purposes only. Your module applications should avoid calling the util classes. Use the non-util classes instead–you can reference them using the @Reference annotation.


You can modify any *Impl class Service Builder generates. The most common are *LocalServiceImpl, *ServiceImpl and *Impl. If you modify the other classes, Service Builder overwrites the changes the next time you run it. Whenever you add methods to, remove methods from, or change a method signature of a *LocalServiceImpl class, *ServiceImpl class, or *Impl class, you should run Service Builder again to regenerate the affected interfaces and the service JAR



Remote Service (SET OF CLASSES)(generated for an entity only if an entity’s remote-service attribute is not set to false in service.xml)


  • [ENTITY_NAME]ServiceImpl (REMOTE SERVICE IMPLEMENTATION): Remote service implementation. This is the only class in the remote service that you should modify manually. Here, you can write code that adds additional security checks and invokes the local services. For any custom methods added here, Service Builder adds corresponding methods to the [ENTITY_NAME]Service interface the next time you run it.


portal-model-hints.xml

You define model hints in a file called portlet-model-hints.xml. The portlet-model-hints.xml file goes in the service module’s src/main/resources/META-INF folder.

Model hints define two things:

  1. How entities are presented to users

  2. The size of database columns

<field name="name" type="String">
            <hint name="max-length">255</hint>
        </field>


Hint :
The Build Auto Upgrade feature is now different and is set in a global property schema.module.build.auto.upgrade in the file [Liferay_Home]/portal-developer.properties.

References

https://help.liferay.com/hc/en-us/articles/360030614132-Understanding-the-Code-Generated-by-Service-Builder


Comments

Post a Comment

Popular posts from this blog

Azure App Service for Liferay DXP Installations

 Azure App Service is generally not the optimal choice for hosting Liferay DXP (Digital Experience Platform) installations. Liferay DXP is a robust, enterprise-grade platform that requires specific configurations and resources that are better suited for a more flexible and customizable infrastructure. Here are some considerations: 1. **Resource Requirements**: Liferay DXP typically requires significant memory, CPU, and storage resources. Azure App Service, being a Platform-as-a-Service (PaaS) offering, might not provide the necessary resource flexibility and control needed for optimal performance of Liferay DXP. 2. **Custom Configuration**: Liferay DXP often needs custom configurations and tuning, which are easier to manage on Infrastructure-as-a-Service (IaaS) offerings like Azure Virtual Machines or Azure Kubernetes Service (AKS). These services provide greater control over the operating system, middleware, and application layers. 3. **Database Requirements**: Liferay DXP require...
Read more

What Azure Infrastructure is better for Liferay DXP

 When choosing between Azure Container Apps (ACA) and Azure Kubernetes Service (AKS) for Liferay DXP installations, it's important to consider the specific requirements and characteristics of your deployment. Here's a comparison to help you decide: ### Azure Container Apps (ACA) **Pros:** 1. **Simplicity**: ACA provides a serverless environment for deploying containerized applications. It abstracts away much of the underlying infrastructure management. 2. **Cost-Effective**: ACA can be more cost-effective for smaller applications or less complex deployments due to its pay-per-use pricing model. 3. **Ease of Use**: ACA is designed to be easy to use, with less complexity in setup and management compared to AKS. **Cons:** 1. **Limited Control and Flexibility**: ACA abstracts much of the infrastructure, which means you have less control over the configurations and fine-tuning of the environment. 2. **Scalability**: While ACA does support scaling, it may not handle very large or com...
Read more