Summery of Important annotations in Liferay DXP

 

@Component

We will need this annotation to define a component and publish into the Liferay OSGI container

  • immediate - ensure the component is started right away and not wait for a reference
  • properties - Used to pass in a set of OSGi properties to bind to the component. 
  • service - Defines the service that the component implements.
  •  
  • EXAMPLE

/**

 * @author manish

 */

@Component(

immediate = true,

property = {

"com.liferay.portlet.display-category=category.sample",

"com.liferay.portlet.header-portlet-css=/css/main.css",

"com.liferay.portlet.instanceable=true",

"javax.portlet.display-name=VINTracker",

"javax.portlet.init-param.template-path=/",

"javax.portlet.init-param.view-template=/view.jsp",

"javax.portlet.name=" + VINTrackerPortletKeys.VINTRACKER,

"javax.portlet.resource-bundle=content.Language",

"javax.portlet.security-role-ref=power-user,user"

},

service = Portlet.class

)

public class VINTrackerPortlet extends MVCPortlet {

}



@Reference  (All blue are @Reference attribute)

complementary to the @Component annotation.  @Reference is used to allow OSGi to inject another component reference into your component. This need to be understood here, since OSGi is doing the injection, it is only going to work on an OSGi @Component class.(will be ignored in non OSGI and even in subclasses)

Common attribute are
unbind attribute -- @Reference(unbind = "-") ---- the unbind attribute indicates that there is no method to call when the component is unbinding

 target attribute -- you indicate which instance of a component that you'd like to bind here.  Here's one example:

@Reference(

target = "(component.name=override.my.service.reference.service.impl.SomeServiceImpl )",

unbind = "-"

)

private SomeService _defaultService;


i.e. it will need _defaultService instance tied with component indicated i.e. SomeServiceImpl

Important attribute are

Cardinality 

  • MANDITORY (Default) - The reference must be available and injected before this component will start.
  • OPTIONAL - The reference is not required for the component to start and will function w/o a component assignment.
  • MULTIPLE - Multiple resources may satisfy the reference and the component will take all of them, but like OPTIONAL the reference is not needed for the component to start.
  • AT_LEAST_ONE - Multiple resources may satisfy the reference and the component will take all of them, but at least one is manditory for the component to start.
Optional (scenario where you have a circular reference issue: as none will start because the references cannot be satisfied (only started components can be assigned as a reference) , this breaks the circle)

MULTIPLE ( were adding to a list or array.  Alternatives to this kind of thing would be to use a ServiceTracker so you wouldn't have to manage the list yourself.)

@Reference(

cardinality = ReferenceCardinality.MULTIPLE,

policy = ReferencePolicy.DYNAMIC,

target = "(com.liferay.fragment.entry.processor.portlet.alias=*)"

)

protected void setPortlet(Portlet portlet, Map<String, Object> properties) {

String aliass = MapUtil.getString(

properties, "com.liferay.fragment.entry.processor.portlet.alias");

String portletName = MapUtil.getString(

properties, "javax.portlet.name");


_portletNames.put(aliass, portletName);

}


Policy 



  • STATIC (Default) - The component will only be started when there is an assigned reference, and will not be notified of alternative services as they become available.
  • DYNAMIC - The component will start when there is reference(s) or not, and the component will accept new references as they become available.
The reference policy controls what happens after your component starts when new reference options become available.  For STATIC, new reference options are ignored and DYNAMIC your component is willing to change.

@Reference(

policy = ReferencePolicy.STATIC,

policyOption = ReferencePolicyOption.GREEDY, 

cardinality = ReferenceCardinality.MANDATORY)

protected void setModbus(BridgeModbus modbus) {

super.setModbus(modbus);

}


policyOption

  • RELUCTANT (Default) - For single reference cardinality, new reference potentials that become available will be ignored.  For multiple reference cardinality, new reference potentials will be bound.
  • GREEDY - As new reference potentials become available, the component will bind to them.
Two Scenerios

First is the default, ReferenceCardinality.MANDITORY, ReferencePolicy.STATIC and ReferencePolicyOption.RELUCTANT.  This summarizes down to your component must have only one reference service to start and regardless of new services that are started, your component is going to ignore them.  These are really good and normal defaults and promote stability for your component.

Another common grouping you'll find in the Liferay source is ReferenceCardinality.OPTIONAL or MULTIPLE, ReferencePolicy.DYNAMIC and ReferencePolicyOption.GREEDY.  In this configuration, the component will function with or without reference service(s), but the component allows for changing/adding references on the fly and wants to bind to new references when they are available.


@BeanReference

This is a Liferay annotation used to inject a reference to a Spring bean from the Liferay core.

@ServiceReference

This is a Liferay annotation used to inject a reference from a Spring Extender module bean.

*** If your @Reference isn't getting injected or is null, that will be sign that you should use one of the other reference annotations.  Here your choice is easy: if the bean is from the Liferay core, use @BeanReference, but if it is from a Spring Extender module, use the @ServiceReference annotation instead.  

@Activate

The @Activate annotation is OSGi's equivalent to Spring's InitializingBean interface.  It declares a method that will be invoked after the component has started.

@Deactivate

The @Deactivate annotation is the inverse of the @Activate annotation, it identifies a method that will be invoked when the component is being deactivated.



Reference > https://liferay.dev/blogs/-/blogs/liferay-osgi-annotations-what-they-are-and-when-to-use-them

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