Extending OCD in AEM Services

Avatar

Avatar

ayush81092

Avatar

ayush81092

ayush81092

14-05-2019

Hi All,

We have a scenario in our project where we want to create one common OCD to define all common attributes accorss the services and re-use / extend it within in the specific service OCD configuration to avoid the code duplications. The idea is to keep the OCD attributes at one place and populate values from the individual services.

Psuedo Code:

@ObjectClassDefinition(name = "Customer Experience Portal Process Service Configuration", description = "Customer Experience Portal Process Service Configuration")

public @interface ParentConfig {

          @AttributeDefinition(name = "Service Name", description = "Suffix of browser request")

          String serviceName();

}

In the individual service we are trying to provide the values by calling this parent ServiceConfig, like this

@ParentConfig (serviceName="Dummy Value")

public @interface ChildConfig{

          // Other Attributes

}

But we are not able to provide the configuration when the service containing the ChildConfig is executed. We need your help here.

Thanks,

Ayush

Accepted Solutions (1)

Accepted Solutions (1)

Avatar

Avatar

Arun_Patidar

MVP

Total Posts

2.9K

Likes

1.0K

Correct Answer

831

Avatar

Arun_Patidar

MVP

Total Posts

2.9K

Likes

1.0K

Correct Answer

831
Arun_Patidar
MVP

14-05-2019

you can create a common service with common attribute and use in other services using @Reference annotation

Answers (2)

Answers (2)

Avatar

Avatar

ankurk67503819

Avatar

ankurk67503819

ankurk67503819

14-05-2019

As per documentation osgi config cant be extended

Avatar

Avatar

Jörg_Hoh

Employee

Total Posts

3.0K

Likes

910

Correct Answer

1.0K

Avatar

Jörg_Hoh

Employee

Total Posts

3.0K

Likes

910

Correct Answer

1.0K
Jörg_Hoh
Employee

14-05-2019

I know that this is a total unpopular opinion, but is DRY (a.k.a do not repeat yourself) always a good choice? From my point of view it's not an issue to have a OCD per service, even if these services share some (and not all) parameters. And if they share the same parameters, very likely the design can be improved. The same with with the case, if they share most of the parameters.

Because in many cases these common parameters MUST have the same value to make the overall system work properly. in that case it might be much better to move the common configuration into some kind of configuration service, and centralize all common functionality there (do not just build an empty service with just getters for configuration values!).

Jörg