tjwatson commented on pull request #21: URL: https://github.com/apache/felix-dev/pull/21#issuecomment-631627618
For your scenario is R6 or R7 log specification being used? or maybe both at the same time? My opinion is if SCR itself is wired to the R7 log package then it must always use the new Logger interface to log all messages. If SCR is logging messages related to a specific component then SCR must call the LoggerFactory.getLogger(Bundle bundle, String name, Class loggerType) method passing the bundle declaring the component to obtain the Logger. This is described at https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#d0e41804 In that case I believe SCR must use its own BundleContext to get the LoggerFactory service NOT the context of the extendee bundle. I think it would be unfortunate to resort to reflection to call the Logger because SCR is very noisy with its debug logging. That is optimized out by the log service implementation if debug is not enabled with LoggerAdmin, but now we may put a reflective call before that optimization can be used. Unfortunately Felix SCR also tries to support the R6 LogService (perhaps we should rip that out?). For R6 LogService SCR must use the BundleContext of the extendee. The R6 Declarative Service spec states: > When SCR must log an error message to the Log Service, it must use a Log Service obtained using the component's Bundle Context so that the resulting Log Entry is associated with the component's bundle. So in that case I see the need to fall back to reflection. But first I think we should decide if we want to support R6 LogService at all in SCR. My vote is to rip that out and only support R7 which allows us to only use the context of SCR itself to obtain the LoggerFactory therefore avoiding any possible cast exceptions. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
