glassfish
  1. glassfish
  2. GLASSFISH-19252

Add proper support for the platform default connection factory with admin tools

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0
    • Fix Version/s: 4.0_b72_EE7MS4
    • Component/s: admin_gui
    • Labels:
      None

      Description

      Java EE 7 spec section EE 5.21 defines a "platform default JMS connection factory". This was implemented in GLASSFISH-18899. This means that a connection factory is now always created by default.

      Here is the automatically-created entry that is now created in domaim.xml:

      <connector-connection-pool max-pool-size="64" name="__DefaultJMSConnectionFactory-Connection-Pool" 
          resource-adapter-name="jmsra" connection-definition-name="javax.jms.ConnectionFactory">
      </connector-connection-pool>
          
      <connector-resource pool-name="__DefaultJMSConnectionFactory-Connection-Pool"
          jndi-name="jms/__defaultConnectionFactory" object-type="system-all">
      </connector-resource>
      

      Currently the user will see this in the admin console. The application can look up the default connection factory by using the JNDI name jms/_defaultConnectionFactory (with _ prefix) or using the JNDI name java:comp/DefaultJMSConnectionFactory. However a portable application must use the JNDI name java:comp/DefaultJMSConnectionFactory since that is the name defined in the Java EE 7 specification.

      To avoid confusion, it is desirable if the user didn't actually see jms/__defaultConnectionFactory in the admin console, but saw a special entry which showed the true JNDI name that they need to use.

      Also, the user shouldn't be allowed to delete this connection factory, though they should be allowed to modify it.

      The exact functionality should be decided in conjunction with other interested parties such as the Java EE 7 spec leads and the implementer of GLASSFISH-18899.

        Activity

        Hide
        Tom Mueller added a comment -

        From Ed:

        My opinion: there ought to, at least be a button in the Admin GUI that can re-create this resource, if it's been removed or absent from domain.xml. If it's decided that this cannot be removed, then there will need to be code somewhere, which restores it, if it is, somehow absent from domain.xml.

        From Tom:
        Maybe using config modularity, we can cause this to always be available in the configuration.

        Show
        Tom Mueller added a comment - From Ed: My opinion: there ought to, at least be a button in the Admin GUI that can re-create this resource, if it's been removed or absent from domain.xml. If it's decided that this cannot be removed, then there will need to be code somewhere, which restores it, if it is, somehow absent from domain.xml. From Tom: Maybe using config modularity, we can cause this to always be available in the configuration.
        Hide
        Tom Mueller added a comment - - edited

        Regarding the requirement to prevent deleting this resource, here is a proposal:

        1. Add a new resource object type: system-all-req which would be used for this resource.
        The delete-connector-resource command would not allow deleting these type of resource and therefore the console would also not allow deleting it.

        2. If the system admin deletes it via editing the domain.xml, it will not be recreated. Editing the domain.xml manually is akin to deleting an IPS package or deleting a JAR file, i.e., the system admin should know that they are screwing up their system by doing this. In this case, a reboot of the system will not automatically recreate the resource.

        One draw-back of this approach is that in the admin console, the user would still be able to check the checkbox next to this resource and click the delete button. Only then would the user receive an error message saying that the delete failed because it is a system resource which cannot be deleted. A better user interface would be to never allow the user to even try to delete the resource. However, that is not feasible with the current UI design since the same checkbox is used to perform other operations on the resource (enable/disable).

        Show
        Tom Mueller added a comment - - edited Regarding the requirement to prevent deleting this resource, here is a proposal: 1. Add a new resource object type: system-all-req which would be used for this resource. The delete-connector-resource command would not allow deleting these type of resource and therefore the console would also not allow deleting it. 2. If the system admin deletes it via editing the domain.xml, it will not be recreated. Editing the domain.xml manually is akin to deleting an IPS package or deleting a JAR file, i.e., the system admin should know that they are screwing up their system by doing this. In this case, a reboot of the system will not automatically recreate the resource. One draw-back of this approach is that in the admin console, the user would still be able to check the checkbox next to this resource and click the delete button. Only then would the user receive an error message saying that the delete failed because it is a system resource which cannot be deleted. A better user interface would be to never allow the user to even try to delete the resource. However, that is not feasible with the current UI design since the same checkbox is used to perform other operations on the resource (enable/disable).
        Hide
        marina vatkina added a comment -

        should it behave the same as jdbc/__default (and the corresponding default jdbc resource)?

        Show
        marina vatkina added a comment - should it behave the same as jdbc/__default (and the corresponding default jdbc resource)?
        Hide
        Tom Mueller added a comment -

        Yes, I was wondering about that too.

        Since writing that comment, I had a chat with Tim, and it might be possible to implement the "can't delete" behavior using the new security authorization framework. We are evaluating that as a possibility.

        Show
        Tom Mueller added a comment - Yes, I was wondering about that too. Since writing that comment, I had a chat with Tim, and it might be possible to implement the "can't delete" behavior using the new security authorization framework. We are evaluating that as a possibility.
        Hide
        Tom Mueller added a comment -

        The originally proposed behavior (the "system-all-req" object type) has been implemented for preventing deletion of this resource.

        The list-jms-resources command has been modified to provide the logical-jndi-name to the console in revision 58220.
        To support this, a new interface, DefaultResourceProxy, was added which is implemented by the classes that implement these default resources. So the logical name is available for the JDBC default resource as well (however, it is not yet made available via the list-jdbc-resources command).

        The remaining work is to make the console actually display this JNDI name. Handing off to Anissa.

        Show
        Tom Mueller added a comment - The originally proposed behavior (the "system-all-req" object type) has been implemented for preventing deletion of this resource. The list-jms-resources command has been modified to provide the logical-jndi-name to the console in revision 58220. To support this, a new interface, DefaultResourceProxy, was added which is implemented by the classes that implement these default resources. So the logical name is available for the JDBC default resource as well (however, it is not yet made available via the list-jdbc-resources command). The remaining work is to make the console actually display this JNDI name. Handing off to Anissa.
        Hide
        Tom Mueller added a comment -

        Assigning to Anissa to use the logical-jndi-name value from the list-jms-resources command in the console. The extraProperties from list-jms-resources is now a list of maps where each map has the property "name" and optionally "logical-jndi-name" if there is one.

        Show
        Tom Mueller added a comment - Assigning to Anissa to use the logical-jndi-name value from the list-jms-resources command in the console. The extraProperties from list-jms-resources is now a list of maps where each map has the property "name" and optionally "logical-jndi-name" if there is one.
        Hide
        Anissa Lam added a comment -

        change to admin_gui component and the targeted milestone for this.

        Show
        Anissa Lam added a comment - change to admin_gui component and the targeted milestone for this.
        Hide
        Anissa Lam added a comment -

        Changes checked in.

        Project: glassfish
        Repository: svn
        Revision: 58289
        Author: anilam
        Date: 2013-01-11 14:19:18 UTC
        Link:

        Log Message:
        ------------

        Changes in JMS resources including:

        • fixing treeNode to use list-jms-resources
        • table listing for connection Factories include display of logical-jndi-name
        • cleaning up listing connection factories and destination listing page.
        • report correct error msg if try to delete the default out-of-box connection factories
        • creating and editing connection factories now shows proper jndi names.

        =======
        svn commit common jms-plugin
        Sending common
        Adding common/src/main/java/org/glassfish/admingui/common/handlers/JmsResourceHandler.java
        Sending common/src/main/resources/resourceNode/resourceHandlers.inc
        Sending jms-plugin/src/main/resources/jmsConnectionButtons.inc
        Sending jms-plugin/src/main/resources/jmsConnectionEdit.jsf
        Sending jms-plugin/src/main/resources/jmsConnectionNew.jsf
        Sending jms-plugin/src/main/resources/jmsConnections.jsf
        Sending jms-plugin/src/main/resources/jmsDestinations.jsf
        Sending jms-plugin/src/main/resources/org/glassfish/jms/admingui/Strings.properties
        Sending jms-plugin/src/main/resources/poolProperties.inc
        Sending jms-plugin/src/main/resources/resourcesNodes.jsf
        Sending jms-plugin/src/main/resources/shared/resourcesTable.inc
        Sending jms-plugin/src/main/resources/shared/tableButtons.inc
        Transmitting file data ............
        Committed revision 58289.

        Show
        Anissa Lam added a comment - Changes checked in. Project: glassfish Repository: svn Revision: 58289 Author: anilam Date: 2013-01-11 14:19:18 UTC Link: Log Message: ------------ Changes in JMS resources including: fixing treeNode to use list-jms-resources table listing for connection Factories include display of logical-jndi-name cleaning up listing connection factories and destination listing page. report correct error msg if try to delete the default out-of-box connection factories creating and editing connection factories now shows proper jndi names. ======= svn commit common jms-plugin Sending common Adding common/src/main/java/org/glassfish/admingui/common/handlers/JmsResourceHandler.java Sending common/src/main/resources/resourceNode/resourceHandlers.inc Sending jms-plugin/src/main/resources/jmsConnectionButtons.inc Sending jms-plugin/src/main/resources/jmsConnectionEdit.jsf Sending jms-plugin/src/main/resources/jmsConnectionNew.jsf Sending jms-plugin/src/main/resources/jmsConnections.jsf Sending jms-plugin/src/main/resources/jmsDestinations.jsf Sending jms-plugin/src/main/resources/org/glassfish/jms/admingui/Strings.properties Sending jms-plugin/src/main/resources/poolProperties.inc Sending jms-plugin/src/main/resources/resourcesNodes.jsf Sending jms-plugin/src/main/resources/shared/resourcesTable.inc Sending jms-plugin/src/main/resources/shared/tableButtons.inc Transmitting file data ............ Committed revision 58289.

          People

          • Assignee:
            Anissa Lam
            Reporter:
            Nigel Deakin
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: