Topic
  • 6 replies
  • Latest Post - ‏2010-05-17T21:00:46Z by Rohit_R
Rohit_R
Rohit_R
24 Posts

Pinned topic Open SCA feature pack and JNDI lookup?

‏2010-05-06T19:18:34Z |
We are using spring for wiring our application classes and are specifically interested in spring SCA support (implementation.spring). While going through this article (http://www.ibm.com/developerworks/websphere/library/techarticles/1001_beck6/1001_beck6.html) we are not sure whether spring framework can access the JNDI resources defined using websphere admin console. For example when can we define a spring bean which uses a websphere datasource in the following way and use this as a part of bean as part of Spring context initialized by SCA?

<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
  • <property name="jndiName"><value>jdbc/auditds</value></property>*
  • <property name="lookupOnStartup" value="true"/>*
  • <property name="cache" value="true"/>*
</bean>

If not what are the alternative methods for using JMS and datasource resources defined in websphere when using Spring with SCA?

thanks
Rohit
Updated on 2010-05-17T21:00:46Z at 2010-05-17T21:00:46Z by Rohit_R
  • JenniferThompson
    JenniferThompson
    5 Posts

    Re: Open SCA feature pack and JNDI lookup?

    ‏2010-05-10T21:09:57Z  
    Rohit,

    Globally defined JNDI names are available in the Open SCA Domain and therefore available in implementation.spring applications. Resources defined via the Admin Console use global JNDI names.

    However, local namespace JNDI names are not available in the Open SCA Domain. For example the following are not supported: local resource ref JNDI lookups (i.e. resources defined in an application), resources defined in the J2EE container, resources with JNDI names beginning with "java:comp".

    So your example will work, provided the JNDI name does not begin with "java:comp".
    When using JNDI lookups in Spring with Open SCA, the user should be aware the Spring container may automatically pre-pend "java:comp/env" to the JNDI name specified in the application context. Again referring to the example in your question, if the following property is set in the dataSource bean:
    
    <property name=
    "resourceRef" value=
    "true"/>
    
    the Spring container will automatically add "java:comp/env" to the JNDI name, resulting in a JDNI lookup failure in the Open SCA environment.

    If you have any other questions or need any clarifications please post a response.

    Regards,

    Jennifer
  • Rohit_R
    Rohit_R
    24 Posts

    Re: Open SCA feature pack and JNDI lookup?

    ‏2010-05-11T13:53:33Z  
    Rohit,

    Globally defined JNDI names are available in the Open SCA Domain and therefore available in implementation.spring applications. Resources defined via the Admin Console use global JNDI names.

    However, local namespace JNDI names are not available in the Open SCA Domain. For example the following are not supported: local resource ref JNDI lookups (i.e. resources defined in an application), resources defined in the J2EE container, resources with JNDI names beginning with "java:comp".

    So your example will work, provided the JNDI name does not begin with "java:comp".
    When using JNDI lookups in Spring with Open SCA, the user should be aware the Spring container may automatically pre-pend "java:comp/env" to the JNDI name specified in the application context. Again referring to the example in your question, if the following property is set in the dataSource bean: <pre class="jive-pre"> <property name= "resourceRef" value= "true"/> </pre> the Spring container will automatically add "java:comp/env" to the JNDI name, resulting in a JDNI lookup failure in the Open SCA environment.

    If you have any other questions or need any clarifications please post a response.

    Regards,

    Jennifer
    Jennifer,
    thanks for the reply. We writing some sample programs we found that the above spring datasource
    <bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
    + <property name="jndiName"><value>jdbc/auditds</value></property>+
    + <property name="lookupOnStartup" value="true"/>+
    + <property name="cache" value="true"/>+
    </bean>
    works fine in a regular enterprise application.

    But when used within an SCA application we were able to get it working only by explicitly specifying the "java.naming.factory.initial" for the data source as shown below.

    <bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName"><value>jdbc/auditds</value></property>
    <property name="lookupOnStartup" value="true"/>
    <property name="cache" value="true"/>
    <property name="jndiTemplate" ref="jndiTemplate"/>
    </bean>
    <bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
    <property name="environment">
    <props>
    <prop key="java.naming.factory.initial">com.ibm.websphere.naming.WsnInitialContextFactory</prop>
    </props>
    </property>
    </bean>

    If we do not specify the context factory we get the following error

    org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'dataSource': Invocation of init method failed; nested exception is javax.naming.NoInitialContextException: Failed to create InitialContext using factory specified in hashtable {java.naming.provider.url=corbaloc:rir:/NameServiceServerRoot, java.naming.factory.url.pkgs=com.ibm.ws.naming:com.ibm.ws.runtime:com.ibm.iscportal.jndi} http://Root exception is java.lang.NullPointerException
    at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:243)
  • SteveKinder
    SteveKinder
    14 Posts

    Re: Open SCA feature pack and JNDI lookup?

    ‏2010-05-12T12:54:03Z  
    • Rohit_R
    • ‏2010-05-11T13:53:33Z
    Jennifer,
    thanks for the reply. We writing some sample programs we found that the above spring datasource
    <bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
    + <property name="jndiName"><value>jdbc/auditds</value></property>+
    + <property name="lookupOnStartup" value="true"/>+
    + <property name="cache" value="true"/>+
    </bean>
    works fine in a regular enterprise application.

    But when used within an SCA application we were able to get it working only by explicitly specifying the "java.naming.factory.initial" for the data source as shown below.

    <bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName"><value>jdbc/auditds</value></property>
    <property name="lookupOnStartup" value="true"/>
    <property name="cache" value="true"/>
    <property name="jndiTemplate" ref="jndiTemplate"/>
    </bean>
    <bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
    <property name="environment">
    <props>
    <prop key="java.naming.factory.initial">com.ibm.websphere.naming.WsnInitialContextFactory</prop>
    </props>
    </property>
    </bean>

    If we do not specify the context factory we get the following error

    org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'dataSource': Invocation of init method failed; nested exception is javax.naming.NoInitialContextException: Failed to create InitialContext using factory specified in hashtable {java.naming.provider.url=corbaloc:rir:/NameServiceServerRoot, java.naming.factory.url.pkgs=com.ibm.ws.naming:com.ibm.ws.runtime:com.ibm.iscportal.jndi} http://Root exception is java.lang.NullPointerException
    at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:243)
    Rohit,

    JEE resources within a Spring bean is quite interesting from an architectural perspective. When Spring is used in a JEE application environment, it actually relies on the fact that a JEE container is providing: local JNDI namespaces, transaction coordinators, and connection management. As such, the Spring container in this environment is really a hybrid container, both a JEE and a Spring container.

    That said, when you ask SCA to expose your Spring service endpoints, SCA opens those ports and invokes the Spring beans directly, without establishing a JEE context. This means, there is no local JNDI namespace for datasource lookups; although you can use explicit JNDI namespaces. SCA also provides an implementation.JEE which can be used as an implementation style, which would allow you to have access to the JEE business logic; but we don't have a hybrid implementation style that allows you to establish the JEE context, and then dispatch the Spring bean from inside the JEE and Spring Containers.

    You might want to take a look at the OSGi/JPA Feature Pack for WebSphere Application Server V7; it provides an Open alternative to Spring applications.

    Steve Kinder
    SOA Architect for WebSphere
  • Rohit_R
    Rohit_R
    24 Posts

    Re: Open SCA feature pack and JNDI lookup?

    ‏2010-05-13T21:22:22Z  
    Rohit,

    JEE resources within a Spring bean is quite interesting from an architectural perspective. When Spring is used in a JEE application environment, it actually relies on the fact that a JEE container is providing: local JNDI namespaces, transaction coordinators, and connection management. As such, the Spring container in this environment is really a hybrid container, both a JEE and a Spring container.

    That said, when you ask SCA to expose your Spring service endpoints, SCA opens those ports and invokes the Spring beans directly, without establishing a JEE context. This means, there is no local JNDI namespace for datasource lookups; although you can use explicit JNDI namespaces. SCA also provides an implementation.JEE which can be used as an implementation style, which would allow you to have access to the JEE business logic; but we don't have a hybrid implementation style that allows you to establish the JEE context, and then dispatch the Spring bean from inside the JEE and Spring Containers.

    You might want to take a look at the OSGi/JPA Feature Pack for WebSphere Application Server V7; it provides an Open alternative to Spring applications.

    Steve Kinder
    SOA Architect for WebSphere
    Steve, Thanks for the reply!
  • JenniferThompson
    JenniferThompson
    5 Posts

    Re: Open SCA feature pack and JNDI lookup?

    ‏2010-05-14T17:39:03Z  
    Rohit,

    JEE resources within a Spring bean is quite interesting from an architectural perspective. When Spring is used in a JEE application environment, it actually relies on the fact that a JEE container is providing: local JNDI namespaces, transaction coordinators, and connection management. As such, the Spring container in this environment is really a hybrid container, both a JEE and a Spring container.

    That said, when you ask SCA to expose your Spring service endpoints, SCA opens those ports and invokes the Spring beans directly, without establishing a JEE context. This means, there is no local JNDI namespace for datasource lookups; although you can use explicit JNDI namespaces. SCA also provides an implementation.JEE which can be used as an implementation style, which would allow you to have access to the JEE business logic; but we don't have a hybrid implementation style that allows you to establish the JEE context, and then dispatch the Spring bean from inside the JEE and Spring Containers.

    You might want to take a look at the OSGi/JPA Feature Pack for WebSphere Application Server V7; it provides an Open alternative to Spring applications.

    Steve Kinder
    SOA Architect for WebSphere
    Rohit,

    I was able to perform a successful JNDI (global) lookup without having to explicitly specify the InitialContext when I used a profile augmented with both SCA and OSGi feature packs. However, I saw the same issue you reported when I used a profile only augmented with SCA feature pack. If you’d like to open a PMR, we can investigate this further.

    Regards,

    Jennifer Thompson
  • Rohit_R
    Rohit_R
    24 Posts

    Re: Open SCA feature pack and JNDI lookup?

    ‏2010-05-17T21:00:46Z  
    Rohit,

    I was able to perform a successful JNDI (global) lookup without having to explicitly specify the InitialContext when I used a profile augmented with both SCA and OSGi feature packs. However, I saw the same issue you reported when I used a profile only augmented with SCA feature pack. If you’d like to open a PMR, we can investigate this further.

    Regards,

    Jennifer Thompson
    Jennifer,
    its good to know that when using both SCA and OSGi feature packs the explicit specification of InitialContext is not required as we intend to use the OSGi feature pack as well for our development. Also since the only information required is a static factory name and not server deployment specific information like JNDI provider url or authentication information at this time we don't see the need to open a PMR

    Thanks and Regards
    Rohit R