OSGI JNDI는 비 OSGI 코드의 JNDI 호출과 공존 할 수 있습니까? <a href="http://www.osgi.org/Download/Release5" rel="noreferrer">OSGI Enterprise Release 5 specification</a>의

Question

장 126 호환성 언급 ". 자바 SE와 Java EE 클라이언트에서 사용하는 전통적인 JNDI 프로그래밍 모델을 지원"

및 OSGI-인식 코드를 사용 :

는 "은 OSGi 모르고 클라이언트와 JNDI 컨텍스트 공급자가 JRE JNDI 구현에 연결하는 정적 메소드를 사용하는의 InitialContext 클래스는에 대한 액세스를 제공합니다. 제공자의 컨텍스트와 제공자는 정적 NamingManager 메소드를 사용하여 객체 변환을 수행하고 URL 컨텍스트를 찾습니다. 이 전통적인 모델은 OSGi를 인식하지 못하므로이 OSGi 인식 부족의 결과가 관리되는 경우에만 안정적으로 사용할 수 있습니다. "

하지만,이 텍스트는 "기존의"코드 OSGi 번들 내에서 실행하거나, 또한 OSGi 컨테이너 외부의 코드에 적용되는 경우 그것은 나에게 명확하지 않다,은 OSGi 컨테이너에 포함되는 시나리오에서 F 전 지원서.

임베딩 시나리오에서 JNDI 호출을 수행하는 OSGI 컨테이너 외부와 내부 모두에 응용 프로그램 코드가있을 수 있으며 동일한 JVM에서 실행될 때 JNDI 구현을 공유합니다.

질문 :가 포함 된 OSGI 용기에 OSGI의 JNDI 구현 실행은 JNDI 평소처럼 호출, 또는 "OSGI 인식은"필요한 몇 가지 이식은 그 수행하기 위해 용기 외부에 OSGI-인식 코드를 허용해야?

Apache Karries 2.3.0 (Apache Aries JNDI 1.0.0 사용)에서이 작업을 시도하는 것은 Apache Aries가 JNDI 클라이언트 호출을 OSGI 번들에서 시작해야하므로 작동하지 않습니다.
부분 스택 트레이스 :

javax.naming.NoInitialContextException: The calling code's BundleContext could not be determined. 
    at org.apache.aries.jndi.OSGiInitialContextFactoryBuilder.getInitialContext(OSGiInitialContextFactoryBuilder.java:46) 
    at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) 
    at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) 
    at javax.naming.InitialContext.init(InitialContext.java:242) 
    at javax.naming.InitialContext.<init>(InitialContext.java:192) 

질문 :이 올바른 행동인가, 또는 거기에 이러한 제한으로 위반 내가 그 참조 할 수 있습니다 사양의 섹션입니까?

Answer 1

JNDI는 서비스 공급자 인터페이스이며 실행에 필요한 기본 구현이 필요합니다. OSGI 컨테이너를 프로비저닝하기 만하면됩니다.

JNDI에서 필요로하는 모든 jar로 단일 묶음을 만들고 모든 패키지를 내보내는 것이 좋습니다. 그런 다음 Dynamic-Import : *를 사용하여 사용하십시오. 우리의 경우 (EJB 호출에 사용되는 JBoss 5 JNDI가있는 Eclipse RCP 응용 프로그램)에서 작동했습니다. 나는 응용 프로그램 클래스 경로에 모든 항아리를 추가하는 것이 좋습니다 것,

그러나 당신은 용기의 내부 JNDI와 외부를 필요로하는 경우 당신은 클래스 로딩과 투쟁하고 싶지 않아요. 이렇게하면 응용 프로그램 전체에서 액세스 할 수 있어야합니다.

Answer 2

Weblogic에서 Apache Karaf를 배포 할 때 동일한 문제가 발생했습니다. 서블릿 브리지를 통해 karaf를 사용합니다. karaf에 대한 모든 http 요청을 연결하는 웹 로그에 전쟁이 배포됩니다.내가 웹 로직에서 다음과 같은 응용 프로그램으로 실행하고

:

1. APP1은 즉시
2. APP2
3. karaf 브리지 (Karaf에 다리 요청)

(JNDI 사용) karaf가 Aries를 시작함에 따라 Karaf 내부에서 실행되는 JNDI 구현은 javax.naming.NamingManager 내의 InitialContextFactoryBuilder를 자체 구현으로 설정합니다. NamingManager는 초기 컨텍스트 팩토리 빌더에 대한 정적 참조를 보유하므로 OSGI 환경에서 실행 중인지 여부와 관계없이이 구현이 JNDI 공급자가되도록 설정합니다.

필자의 경우, app1 (OSGI가 아닌)이 새로운 InitialContext를 시도하면 Aries JNDI는 BundleContext를 사용하여 해결하려고 시도하고 실패합니다.

jre에서 javax.naming 패키지를 추출하고이를 karaf에 번들로 설치하는 것을 포함하여 매우 못생긴 해킹을 사용하여 이것을 수정했습니다.

귀하의 질문에 대한 답변 : 나는이 문제가 실제로 JNDI 조회가 관리되는 방식에 대한 OSGI가 아니라 jre에 있다고 생각합니다.

Answer 3

아파치 양자리 이것에 대해 생각하고 작동하는 것 같다 JRE 초기 문맥 팩토리 빌더 (org.apache.aries.jndi.JREInitialContextFactoryBuilder)의 구현을 제공 한 것으로 보인다. 그러나 이것이 작동하려면 JVM 와이드 초기 컨텍스트 공장 빌더를 등록하는 Aries 코드를 변경해야했습니다. 이를 달성하는 또 다른 방법이있을 수 있습니다. 그러나 이것은 작동하는 것처럼 보였다.

또한 NamingManager에 설정된 InitialContextFactoryBuilder에서 문제가 중지되지 않습니다. 동일한 문제가 ObjectFactoryBuilder (NamingManager에서 다시 JVM wide로 설정 됨)에서 발생합니다. 연결하려는 JNDI 공급자에 따라 Aries JNDI 코드의 해당 부분도 변경해야 할 수 있습니다. 예 : Tibco EMS JNDI 연결에서 Tibco 특정 ObjectFactory를 반환하도록 Aries에서 OSGiObjectFactoryBuilder 코드를 조정해야했습니다. 이것은, Context.OBJECT_FACTORIES 환경 치를 사용해 간단하게 일반화 할 수 있습니다.

동일한 JIRA를 생성했습니다 - https://issues.apache.org/jira/browse/ARIES-1127