Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

Extending OCD in AEM Services

ayush81092
Level 1
Level 1

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

1 Accepted Solution
Arun_Patidar
Correct answer by
Community Advisor
Community Advisor

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

View solution in original post

3 Replies
ankurk67503819
Level 4
Level 4

As per documentation osgi config cant be extended

Arun_Patidar
Correct answer by
Community Advisor
Community Advisor

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

View solution in original post

Jörg_Hoh
Employee
Employee

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