Refactor JpaGroupRoleProvider into "production code" (aka. getService resulted in a cycle)

Description

This ticket addresses top class level comment in JpaGroupRoleProvider regarding refactoring out the REST endpoint from the core JpaGroupRoleProvider service to clean the code and attempt to avoid a race-condition load collision.

"Since this is not intended to be production code, the REST concerns have not be factored into a separate class. Feel free to refactor." [1]

And the module load race condition SCR-vs-JAXRS tug of war exception [2].

[1] https://github.com/opencast/opencast/blob/r/5.x/modules/userdirectory/src/main/java/org/opencastproject/userdirectory/JpaGroupRoleProvider.java#L99-L111

[2] Load race condition with dependencies triggered by JaxRsServiceTracker.addingService regarding opencast-userdirectory. Consistently about the time the "/groups" endpoint is being registered.

Activity

Show:
Karen Dolan
October 24, 2018, 2:06 PM
Edited

Related to MH-11973, which throws the cycle on "matterhorn-textanalyzer-impl". The textanalyzer impl has a separate Endpoint class. However, the endpoint relies on DI of textanalyzer impl, the impl has a static dependency on userdirectory. Unbinding JpaGroupRoleProvider service from JAX-RS endpoint registration processing might help there, too.

Karen Dolan
October 24, 2018, 4:43 PM
Edited

Possibly related: https://issues.apache.org/jira/browse/FELIX-5887 "Cycles in DS depending on bundle order"

... Looks like the connection between all three problems I discovered, is a call to #getService(XY) while in Activation of XY. Iam not sure if the situation did not occur in 2.0.10 and earlier or if it didnt lead to an error back then.

Assignee

Karen Dolan

Reporter

Karen Dolan

Tags (folksonomy)

None

Affects versions

Priority

Major
Configure