Uploaded image for project: 'Karaf'
  1. Karaf
  2. KARAF-2095

Camel Route (JMS Polling) not working when installing feature "jndi"

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.9
    • Fix Version/s: 2.4.0, 3.0.2, 2.3.6, 4.0.0.M3
    • Component/s: karaf-core
    • Labels:
      None
    • Environment:

      Windows/Linux

      Description

      We have a route which polls on a weblogic jms queue.If we do not have "feature jndi" installed, the route work fine.On installing jndi feature,it work fine if we do not restart the container. On restarting the container it throws following exception.
      ---------------------------------------------------------------------------
      013-01-02 16:06:22,723 | WARN | JmsConsumer[IN] | faultJmsMessageListenerContainer | 101 - org.springframework.jms - 3.0.7.RELEASE | Could not refresh JMS Connection for destination 'IN' - retrying in 5000 ms. Cause: JndiObjectTargetSource failed to obtain new target object; nested exception is javax.naming.ConfigurationException: rmiURLContextFactory.getObjectInstance: argument must be an RMI URL String or an array of them
      org.springframework.jndi.JndiLookupFailureException: JndiObjectTargetSource failed to obtain new target object; nested exception is javax.naming.ConfigurationException: rmiURLContextFactory.getObjectInstance: argument must be an RMI URL String or an array of them
      ----------------------------------------------------------------------------
      I enclosed the following files:
      1)log file for my test(karaf.log)
      2)Test project as attachment(wls_jmspolling.zip)

      1. jndibugtest.zip
        19 kB
        Antoni Mylka
      2. karaf.log
        1.00 MB
        Shrish Srivastava
      3. wls_jmspolling.zip
        2.64 MB
        Shrish Srivastava

        Activity

        Hide
        antoni.mylka Antoni Mylka added a comment -

        I've been able to reproduce the same error with a much smaller example (attached).

        As far as I understand it's a bug in the standard "jndi" feature of Karaf. When it's installed - the OSGI environment contains a Service with the javax.naming.spi.ObjectFactory interface and the com.sun.jndi.url.rmi.rmiURLContextFactory implementation class.

        When I want to lookup an RMI object via JNDI, the control gets through a number of methods into the Aries' ObjectFactoryHelper.getObjectInstanceUsingObjectFactories. The ObjectFactoryHelper gets a list of javax.naming.spi.ObjectFactory services from the OSGI environment and tries to pass the object to all of them. The problem is that by the time the control gets to that method, the object is not a string, but a RMIServerImpl_Stub. When it's passed to the rmiURLContextFactory - the error occurs, because the rmiURLContextFactory expects a String or an array of strings.

        Karaf 2.3 (and 3.0) contain a solution for ARIES-823 - about coping with ObjectFactories that expect only a Reference. This particular object factory expects a String, so it seems to be an even worse case of a "badly written ObjectFactory".

        I don't know much about Karaf or JNDI but AFAICS either the rmiURLContextFactory should NOT be registered as an OSGI service or some specific hack, similar to ARIES-823 should be applied in Aries.

        The attachment contains a simple maven module with two pax exam tests. Both contain a JNDI lookup. One is successfull, one fails. The only difference between them is that one installs the "jndi" feature, one doesn't.

        Show
        antoni.mylka Antoni Mylka added a comment - I've been able to reproduce the same error with a much smaller example (attached). As far as I understand it's a bug in the standard "jndi" feature of Karaf. When it's installed - the OSGI environment contains a Service with the javax.naming.spi.ObjectFactory interface and the com.sun.jndi.url.rmi.rmiURLContextFactory implementation class. When I want to lookup an RMI object via JNDI, the control gets through a number of methods into the Aries' ObjectFactoryHelper.getObjectInstanceUsingObjectFactories. The ObjectFactoryHelper gets a list of javax.naming.spi.ObjectFactory services from the OSGI environment and tries to pass the object to all of them. The problem is that by the time the control gets to that method, the object is not a string, but a RMIServerImpl_Stub. When it's passed to the rmiURLContextFactory - the error occurs, because the rmiURLContextFactory expects a String or an array of strings. Karaf 2.3 (and 3.0) contain a solution for ARIES-823 - about coping with ObjectFactories that expect only a Reference. This particular object factory expects a String, so it seems to be an even worse case of a "badly written ObjectFactory". I don't know much about Karaf or JNDI but AFAICS either the rmiURLContextFactory should NOT be registered as an OSGI service or some specific hack, similar to ARIES-823 should be applied in Aries. The attachment contains a simple maven module with two pax exam tests. Both contain a JNDI lookup. One is successfull, one fails. The only difference between them is that one installs the "jndi" feature, one doesn't.
        Hide
        jbonofre Jean-Baptiste Onofré added a comment -

        I think this issue is now fixed. To give me some time to test it, I leave this Jira opened and postpone to next Karaf release.

        Show
        jbonofre Jean-Baptiste Onofré added a comment - I think this issue is now fixed. To give me some time to test it, I leave this Jira opened and postpone to next Karaf release.

          People

          • Assignee:
            jbonofre Jean-Baptiste Onofré
            Reporter:
            shrishs Shrish Srivastava
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development