glassfish
  1. glassfish
  2. GLASSFISH-19441

ConnectionFactory created using @JMSConnectionFactoryDefinition does not use default credentials

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0_b67_ms7
    • Fix Version/s: 4.0_b71
    • Component/s: jms
    • Labels:
      None

      Description

      I have a simple application which defines a JMS connection factory using the following annotation:

      @JMSConnectionFactoryDefinition(
          name="java:global/jms/demoConnectionFactory",
          className= "javax.jms.ConnectionFactory",
          description="ConnectionFactory to use in demonstration",
          resourceAdapterName="jmsra"
      )  
      

      It then uses the following annotation to inject a connection factory:

          @Resource(lookup = "java:global/jms/demoConnectionFactory")
          ConnectionFactory connectionFactory;
      

      and uses it to create a connection:

      Connection connection = connectionFactory.createConnection();
      

      This fails with

      SEVERE: com.sun.messaging.jmq.auth.api.FailedLoginException: [B4051]: Forbidden guest

      See attached server log for the full exception.

      To reproduce the problem, unzip the attached Netbeans project and deploy in GlassFish (I used build 67). The navigate directly to http://localhost:8080/JMS20Demo/Servlet1?option=JavaEESenderOld and look in the server log.

      The code itself is in the session bean JavaEESenderOld. Note that the same business method also creates a connection using a connection factory defined in glassfish-resources.xml. That works fine using the default credentials.

      A quick analysis of the exception in the debugger suggests that if the connection factory is created using glassfish-resources.xml then the password used us "guest", but if the connection factory is created using @JMSConnectionFactoryDefinition then the password used is "", which is invalid.

      If you explicitly set user and password in @JMSConnectionFactoryDefinition then it works fine. The problem is if user/password is not set. A quick analysis in the debugger suggests that JMSRA is passing a correct user/password to the connection pool (using a javax.resource.spi.ConnectionRequestInfo). However the password is getting overridden somewhere.

      This example was demonstrated at JavaOne in October 2012, and so is a regression since then.

      1. server.log
        70 kB
        Nigel Deakin

        Activity

        Hide
        Nigel Deakin added a comment - - edited

        Confirmed that this is still an issue with glassfish-4.0-b70-12_31_2012.

        This is a regression since glassfish-4.0-b56-09_24_2012.

        Show
        Nigel Deakin added a comment - - edited Confirmed that this is still an issue with glassfish-4.0-b70-12_31_2012. This is a regression since glassfish-4.0-b56-09_24_2012.
        Hide
        Simon Meng added a comment -

        @JMSConnectionFactoryDefinition(
        name="java:global/jms/demoConnectionFactory",
        className= "javax.jms.ConnectionFactory",
        description="ConnectionFactory to use in demonstration",
        properties=

        {"UserName=myuser", "Password=mypassword"}

        ,
        resourceAdapterName="jmsra",
        user="guest",
        password="guest"
        )

        If user and password are defined in both annotation attribute and property list, which one takes effect?

        Show
        Simon Meng added a comment - @JMSConnectionFactoryDefinition( name="java:global/jms/demoConnectionFactory", className= "javax.jms.ConnectionFactory", description="ConnectionFactory to use in demonstration", properties= {"UserName=myuser", "Password=mypassword"} , resourceAdapterName="jmsra", user="guest", password="guest" ) If user and password are defined in both annotation attribute and property list, which one takes effect?
        Hide
        Simon Meng added a comment -

        Fixed at revision 57972.

        Show
        Simon Meng added a comment - Fixed at revision 57972.

          People

          • Assignee:
            Simon Meng
            Reporter:
            Nigel Deakin
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: