OSGi 및 선언적 서비스 (DS)로 작업 중이며 현재 로깅을 올바르게 처리하는 방법을 고려 중입니다. 어쨌든 나는 DS와 함께 일하고 있기 때문에 OSGi 서비스 목록에 지정된 LogService를 필수 서비스 참조로 사용하는 것이 자연스러운 것처럼 보입니다. 나는 ekkes corner 및 nogunners's blog에서 그물에 많이 읽고,하지만 뭔가 나에게 여전히 불분명하다 : (인수 분해 구성 요소를 사용하는 경우 또는 다른 서비스 구성 요소 인스턴스)서비스 구성 요소를 분리하는 동안 OSGi의 로깅을 어떻게 적절하게 처리합니까?
가 어떻게 서로 다른 서비스 구성 요소의 적절한 구분을해야합니까?
Logback을 사용하여 LogListener를 구현 한 nogunners를 살펴보면 Bundle-Id 양식 인 bundlecontext를 사용하여이를 구별합니다. 좋아, 지금까지. 하지만 서비스 구성 요소를 어떻게 구분할 수 있습니까? LogService 객체는 자연스럽게 BundleContext에 대한 참조를 포함하지만 (LogService 인터페이스를 살펴보면) 사용자 (실제로 무언가를 기록하는 사람)가 ServiceReference를 제공해야합니다. 이것은 나에게 허약 한 것처럼 보인다. BundleContext를 전달할 때 프레임 워크가 이것을 제공 할 수없는 이유는 무엇입니까?
OSGi 사양에 준 표준 대신에 logger.log(LogService.LOG_INFO,...)을 사용하는 이유는 무엇입니까? 거기에 몇 가지 구체적인 이유가 있습니까?
빠른 답변을 주셔서 감사합니다. Pax 로깅을 자세히 살펴 보겠습니다. 그러나 메시지에 포함 된 것뿐만 아니라 정확한 구성 요소 차별화를 원하기 때문에 직접 구현할 것입니다. – benjamin
몇 가지 설명 : 로깅 서비스에 ServiceFactory를 사용하면 서로 다른 번들에 다른 서비스 인스턴스를 제공 할 수 있습니다 따라서 BundleContext를 추적 할 수 있습니다. 이는 ComponentContext에서도 가능할 것으로 예상했습니다. 나쁜 소식은 : 프레임 워크가 서비스 인스턴스를 캐시하고 동일한 번들이 서비스를 요청할 때 해당 인스턴스를 다시 사용할 수 있기 때문입니다. 따라서 하나의 번들과 다른 별개의 서비스를 제공 할 수 없습니다. 이것은 imho 나쁜 디자인입니다. http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/ServiceFactory.html – benjamin
Pax-Logging 권장 사항을 강력히지지합니다. 나는 SLF4J와 함께 사용한다. Apache-Karaf를 사용하는 경우 Pax-Logging은 사전 번들로 제공됩니다. –