Extending OCD in AEM Services

Avatar

Avatar
Validate 1
Level 1
ayush81092
Level 1

Likes

0 likes

Total Posts

2 posts

Correct reply

0 solutions
Top badges earned
Validate 1
View profile

Avatar
Validate 1
Level 1
ayush81092
Level 1

Likes

0 likes

Total Posts

2 posts

Correct reply

0 solutions
Top badges earned
Validate 1
View profile
ayush81092
Level 1

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
Coach
MVP
Arun_Patidar
MVP

Likes

1,442 likes

Total Posts

3,318 posts

Correct reply

941 solutions
Top badges earned
Coach
Contributor 2
Ignite 10
Give Back 700
Boost 1000
View profile

Avatar
Coach
MVP
Arun_Patidar
MVP

Likes

1,442 likes

Total Posts

3,318 posts

Correct reply

941 solutions
Top badges earned
Coach
Contributor 2
Ignite 10
Give Back 700
Boost 1000
View profile
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
Validate 10
Level 3
ankurk67503819
Level 3

Likes

15 likes

Total Posts

89 posts

Correct reply

1 solution
Top badges earned
Validate 10
Validate 1
Boost 10
Boost 5
Boost 3
View profile

Avatar
Validate 10
Level 3
ankurk67503819
Level 3

Likes

15 likes

Total Posts

89 posts

Correct reply

1 solution
Top badges earned
Validate 10
Validate 1
Boost 10
Boost 5
Boost 3
View profile
ankurk67503819
Level 3

14-05-2019

As per documentation osgi config cant be extended

Avatar

Avatar
Coach
Employee
Jörg_Hoh
Employee

Likes

1,134 likes

Total Posts

3,161 posts

Correct reply

1,079 solutions
Top badges earned
Coach
Give back 600
Ignite 5
Ignite 3
Ignite 1
View profile

Avatar
Coach
Employee
Jörg_Hoh
Employee

Likes

1,134 likes

Total Posts

3,161 posts

Correct reply

1,079 solutions
Top badges earned
Coach
Give back 600
Ignite 5
Ignite 3
Ignite 1
View profile
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