Extending OCD in AEM Services

[ayush81092]

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

[ankurk67503819]

As per documentation osgi config cant be extended

[arunpatidar · Accepted solution]

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

[Jörg_Hoh]

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