Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.2.1, 3.3
    • Fix Version/s: 3.4.0
    • Component/s: None
    • Labels:
      None

      Description

      ClientFactory tries to bind to java:comp/env/jbi/ClientFactory by default and this only appears to work when run as a standalone server. The java:comp/env naming context is read only according to the JEE spec so the ClientFactory can never bind to JNDI when deployed with JBoss deployer, WAR file, etc.

        Issue Links

          Activity

          Hide
          steve_almeida_1978 steve almeida added a comment -

          i had faced the same issue in jboss as a work around . the following steps were followed

          1) create a jndi propertries and add this to the conatiner

          example : <sm:container id="jbi" embedded="true" useMBeanServer="false"
          createMBeanServer="false" autoEnlistInTransaction="true"
          monitorDeploymentDirectory="true" monitorInstallationDirectory="true"
          monitorInterval="5" persistent="false" createJmxConnector="false" namingContext="#namingContext" >
          </sm:container>
          <util:map id="envproperties" map-class="java.util.Properties">
          <entry key="java.naming.factory.initial" value="$

          {INITIAL_CONTEXT_FACTORY}

          " />
          <entry key="java.naming.provider.url" value="$

          {PROVIDER_URL}

          " />
          <entry key="java.naming.factory.url.pkgs" value="$

          {URL_PKG_PREFIXES}

          " />
          <entry key="java.naming.security.credentials" value="$

          {SECURITY_CREDENTIALS}

          " />
          <entry key="java.naming.security.principal" value="$

          {SECURITY_PRINCIPAL}

          " />
          </util:map>

          <bean id="namingContext" class="javax.naming.InitialContext">
          <constructor-arg index="0" type="" ref="envproperties" />
          </bean>

          2) create a duplicate ClientFactory.java with the same package and edit the private String jndiName = "java:JbiClientFactory"; or write some logic to retrive from file or system.properties

          3) in the jndiview
          the following will be displayed under Global JNDI Namespace

          +- JbiClientFactory (class: org.apache.servicemix.jbi.framework.ClientFactory)

          Show
          steve_almeida_1978 steve almeida added a comment - i had faced the same issue in jboss as a work around . the following steps were followed 1) create a jndi propertries and add this to the conatiner example : <sm:container id="jbi" embedded="true" useMBeanServer="false" createMBeanServer="false" autoEnlistInTransaction="true" monitorDeploymentDirectory="true" monitorInstallationDirectory="true" monitorInterval="5" persistent="false" createJmxConnector="false" namingContext="#namingContext" > </sm:container> <util:map id="envproperties" map-class="java.util.Properties"> <entry key="java.naming.factory.initial" value="$ {INITIAL_CONTEXT_FACTORY} " /> <entry key="java.naming.provider.url" value="$ {PROVIDER_URL} " /> <entry key="java.naming.factory.url.pkgs" value="$ {URL_PKG_PREFIXES} " /> <entry key="java.naming.security.credentials" value="$ {SECURITY_CREDENTIALS} " /> <entry key="java.naming.security.principal" value="$ {SECURITY_PRINCIPAL} " /> </util:map> <bean id="namingContext" class="javax.naming.InitialContext"> <constructor-arg index="0" type="" ref="envproperties" /> </bean> 2) create a duplicate ClientFactory.java with the same package and edit the private String jndiName = "java:JbiClientFactory"; or write some logic to retrive from file or system.properties 3) in the jndiview the following will be displayed under Global JNDI Namespace +- JbiClientFactory (class: org.apache.servicemix.jbi.framework.ClientFactory)
          Hide
          tmielke Torsten Mielke added a comment -

          I have seen pretty much the same error when deploying that war into WebSphere 6.1.
          Trying to add any SMX shared libraries afterwards (via JMX) results in

          Caused by: javax.naming.NameNotFoundException: Name comp/env/jms not found in context "java:".
          

          In addition Websphere spits out the following explanation:

          A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to 
          associate the operation's thread with any J2EE application component. This condition can occur 
          when the JNDI client using the "java:" name is not executed on the thread of a server application 
          request. Make sure that a J2EE application does not execute JNDI operations on "java:" names within 
          static code blocks or in threads created by that J2EE application. Such code does not necessarily run 
          on the thread of a server application request and therefore is not supported by JNDI operations on 
          "java:" names"
          

          Also, there is some discussion of this error in http://jlorenzen.blogspot.com/2010/04/possible-solution-for-websphere-issue.html.
          From what I understand the local JNDI namespace java:comp/env is not available to any J2EE non-container managed threads.

          Show
          tmielke Torsten Mielke added a comment - I have seen pretty much the same error when deploying that war into WebSphere 6.1. Trying to add any SMX shared libraries afterwards (via JMX) results in Caused by: javax.naming.NameNotFoundException: Name comp/env/jms not found in context "java:" . In addition Websphere spits out the following explanation: A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation's thread with any J2EE application component. This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request. Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application. Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names" Also, there is some discussion of this error in http://jlorenzen.blogspot.com/2010/04/possible-solution-for-websphere-issue.html . From what I understand the local JNDI namespace java:comp/env is not available to any J2EE non-container managed threads.
          Hide
          lhein Lars Heinemann added a comment -

          fixed

          Show
          lhein Lars Heinemann added a comment - fixed

            People

            • Assignee:
              lhein Lars Heinemann
              Reporter:
              ccustine Chris Custine
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development