내 응용 프로그램은 속성 파일에서 클래스 이름을 가져옵니다. 이러한 클래스 이름이 나타내는 클래스는 미리 알려지지 않은 특정 OSGI 번들에있을 수 있으므로 인스턴스화하려면 먼저이 클래스가 속한 번들을 찾아야합니다. BundleContext # getBundles에서 모든 설치된 번들을 가져 오는 것에 대해 생각하고 있습니다. 즉, AbstractUIPlugin # start에서 BundleContext에 대한 참조를 얻어야합니다. BundleContext에 대한 참조를 보유하는 것이 start 메소드에서만 사용되어야하기 때문에 올바른 일이 아닌지 확실하지 않습니다. 번들 목록을 얻으려면 OSGI 전문가에게 조언을 구하십시오.런타임에 설치된 OSGI 번들 목록 얻기
도움을 주시면 감사하겠습니다.
감사합니다,
Setya
이은 OSGi 의도가 정말 방법이 아니다. 번들에 '전역'컨텍스트에 추가 할 내용이 있으면 서비스를 등록해야합니다. 따라서 공유 할 항목이있는 각 번들은 자체 시작 메소드에서이를 수행 할 수 있습니다.
일부 다른 구성 요소 (DS, ServiceTracker, Blueprint 등)는 이러한 이벤트를 수신하여 그에 따라 작동 할 수 있습니다.
모든 번들을 수동으로 검색하기 시작하면 OSGi의 장점을 완전히 잃게됩니다.
여러분이 원하는 것을 얻기 위해 서비스를 사용하기 전에 작성해야하는 것과 비슷합니다. 나는 당신이 런타임에 설치해야 하나 이상의 구현과 인터페이스를 가지고 같아요. 따라서 인터페이스를 구현하는 번들을 제어하는 경우 Activator 또는 청사진 컨텍스트를 사용하여 해당 구현을 서비스로 설치할 수 있습니다. 서비스 속성을 사용하여 구현을 설명 할 수 있습니다.
구현이 필요한 번들은 청사진의 서비스 추적기 또는 서비스 참조를 사용하여 서비스를 조회 할 수 있습니다.
그럴 수 없다면 번들 컨텍스트를 사용하여 실행중인 번들을 얻고 클래스를 인스턴스화 할 수 있지만 이것이 OSGi의 작동 방식이 아닙니다. 클래스를 인스턴스화하려고하는 번들에 직접 액세스 할 수 없으므로 클래스로드 문제가 발생합니다.
번들은 DS를 통해 번들 활성기 이상으로 시작될 때 제어됩니다. 이 때 서비스 레지스트리에 서비스를 등록하여 다른 사람들이 찾을 수 있도록 할 수 있습니다.
의심 할 여지없이 클래스로드 지옥에서 실행되기 때문에 계획하고있는 경로 (이름 클래스)는 잘못되었습니다. 모듈화는 구현 세부 사항을 숨기는 것에 관한 것이고 구현 클래스의 이름은 그러한 세부 사항입니다.
속성 파일에 구현 클래스를 표시하는 것은 실제로 바람직하지 않으며 모듈성의 이점을 잃어 버립니다. 다른 클래스가 구현 클래스 나 속성 파일을 참조하는지는 중요하지 않습니다. 문제는 impl입니다. 클래스가 공개됩니다.
불행하게도이 모델은 많은 개발자들이 그것은 OSGi는 당신은 단지 내부에 알려지게 구현 클래스를 허용하는 방식으로 인터페이스가 입력 한 인스턴스를 공유 할 수 있습니다 정상 :-(생각하는 것이 우리 업계에서 아주 유행이되었다 모듈
OSGi에서 클래스를 인스턴스화하는 이유는 무엇입니까? 서비스로 선언하고 Equinox에서 라이프 사이클을 처리해야합니다. 그렇게 할 구체적인 이유가 있습니까? – maasg