100% don't initialize a resource resolver in your activate method. Keep your ResourceResolvers/JCR Sessions short-lived as you can. Also, rememeber resourceResolvers and JCR Sessions are NOT thread-safe. So if you had a servlet being hit by 2 ppl at the same time, and they both invoke the RepoUtil service using the same resourceResolver, bad things will happen (like end up w/ lost data due to unresolvable state conflicts)
Here's what you should do (in order of generic preference),
1. Pass in the slingRequest's resourceResolver to your OSGi component's methods to read/write the properties. This way you are using the actual user's security context (permissions) to write the data. This is the preferred approach.
2. If for some reason you cannot allow for the user of the sling requests's resource resolver to write the data, obtain a Service User resourceResolver with the proper permissions in your Servlet, and pass it to your methods.
3. You could alternatively obtain the Service User resource resolver in your RepoUtil, and get a new resourceResolver in each method, but obviously thats a bit wasteful (if the servlet calls 3 methods, then you'd be obtaining the same resourceResolver 3x)
Also, try to avoid using JCR APIs when you can use Sling APIs, I'm specifically saying here you should use SLing Resources and ValueMaps (and ModifiableValueMaps) over JCR Nodes and Properties. If all your RepoUtil does is a "dumb" read/write of JCR properties, it seems unnucessary. If you had a domain-specific OSGi Service, such as "ContactUsService" and you pass in a bunch of data to something like contantUsService.submit(email, name, message) .. and that service puts those 3 params in the "right place" in the JCR, that makes more sense. Just having a OSGI component that generically reads/writes properties doesn't strike me as useful and redundant of Sling's APIs.
https://experienceleague.adobe.com/docs/experience-manager-learn/foundation/development/understand-j...