glassfish
  1. glassfish
  2. GLASSFISH-20898

Injecting @Resource(name = "jdbc/MyDB") fails with GF4 but works in GF3

    Details

    • Type: Bug Bug
    • Status: In Progress
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 4.0
    • Fix Version/s: 4.0_b90
    • Component/s: naming
    • Labels:
      None
    • Environment:

      ALL

      Description

      @Resource(name = "jdbc/MyDB") loads Default DataSource erroneously.
      @Resource(lookup = "jdbc/MyDB") works correctly, but this is not per the spec.
      name = "jdbc name" should work correctly or if data source not found, it should print an error
      instead of silently default to default data source

        Activity

        Hide
        tweier added a comment - - edited

        With the glassfish-sources from 4.0-b91 we have traced the bug into the
        artifact org.glassfish.main.deployment:dol

        In com.sun.enterprise.deployment.util.ComponentValidator there is a method computeRuntimeDefault() with setting the hardcoded DefaultDataSource:

        com.sun.enterprise.deployment.util.ComponentValidator
        964: private void computeRuntimeDefault(ResourceReferenceDescriptor resRef) {
        965:  if (resRef.getType() != null && resRef.getType().equals("org.omg.CORBA.ORB")){
        966:   resRef.setJndiName("java:comp/ORB");
        967:  }
        968:
        969:  else if (resRef.getJndiName() == null ||
        970:    resRef.getJndiName().length() == 0) {
        971:   if (resRef.getType() != null) {
        972:    if (resRef.getType().equals("javax.sql.DataSource"))
        973:     resRef.setLookupName("java:comp/DefaultDataSource");
        974:    else if (resRef.getType().equals("javax.jms.ConnectionFactory"))
        975:     resRef.setLookupName("java:comp/DefaultJMSConnectionFactory");
        976:    else
        977:     resRef.setJndiName(getDefaultResourceJndiName(resRef.getName()));
        978:   } else {
        979:    resRef.setJndiName(getDefaultResourceJndiName(resRef.getName()));
        980:   }
        981:  }
        982: }
        

        From our point of view, the problem seems to be in the special handling for injected DataSources (and also for ConnectionFactories).
        After commenting the lines 972 til 976 (disable the special handling), everything seems to work. We don't know, for what reason this special handling exists.

        We are strongly use @Resource injection for datasources (our product has hundreds of such injections) - so this bug is a showstopper for us.

        Show
        tweier added a comment - - edited With the glassfish-sources from 4.0-b91 we have traced the bug into the artifact org.glassfish.main.deployment:dol In com.sun.enterprise.deployment.util.ComponentValidator there is a method computeRuntimeDefault() with setting the hardcoded DefaultDataSource: com.sun.enterprise.deployment.util.ComponentValidator 964: private void computeRuntimeDefault(ResourceReferenceDescriptor resRef) { 965: if (resRef.getType() != null && resRef.getType().equals( "org.omg.CORBA.ORB" )){ 966: resRef.setJndiName( "java:comp/ORB" ); 967: } 968: 969: else if (resRef.getJndiName() == null || 970: resRef.getJndiName().length() == 0) { 971: if (resRef.getType() != null ) { 972: if (resRef.getType().equals( "javax.sql.DataSource" )) 973: resRef.setLookupName( "java:comp/DefaultDataSource" ); 974: else if (resRef.getType().equals( "javax.jms.ConnectionFactory" )) 975: resRef.setLookupName( "java:comp/DefaultJMSConnectionFactory" ); 976: else 977: resRef.setJndiName(getDefaultResourceJndiName(resRef.getName())); 978: } else { 979: resRef.setJndiName(getDefaultResourceJndiName(resRef.getName())); 980: } 981: } 982: } From our point of view, the problem seems to be in the special handling for injected DataSources (and also for ConnectionFactories). After commenting the lines 972 til 976 (disable the special handling), everything seems to work. We don't know, for what reason this special handling exists. We are strongly use @Resource injection for datasources (our product has hundreds of such injections) - so this bug is a showstopper for us.
        Hide
        lemon_zhang added a comment -

        This change was introduced in another task : GLASSFISH-19187
        And From the spec here : EE 5.18 https://java.net/downloads/javaee-spec/JavaEE_Platform_Spec_EDR.pdf
        It seems to work as expected.
        For more detail you can refer to the https://java.net/jira/browse/GLASSFISH-19187 and above pdf.

        Show
        lemon_zhang added a comment - This change was introduced in another task : GLASSFISH-19187 And From the spec here : EE 5.18 https://java.net/downloads/javaee-spec/JavaEE_Platform_Spec_EDR.pdf It seems to work as expected. For more detail you can refer to the https://java.net/jira/browse/GLASSFISH-19187 and above pdf.
        Hide
        lprimak added a comment -

        This looks like either oversight in the spec or there is something I don't understand…
        There should at least be a warning in big letters that the datasource was not found,
        instead of just silently defaulting.
        Perhaps you should take this up with the spec guys for clarification.

        My particular case is that with GF4, I am now forced to create glassfish-web.xml or glassfish-ejb.xml
        to map the resources. If I don't, there is no way to configure the mapping using @Resource(name="xxx")

        I thought Sun/Oracle wanted to be more standardized and eliminate glassfish-xxx files wherever possible?

        With this change, there is no way to configure a resource without glassfish-xxx files.

        Thank you

        Show
        lprimak added a comment - This looks like either oversight in the spec or there is something I don't understand… There should at least be a warning in big letters that the datasource was not found, instead of just silently defaulting. Perhaps you should take this up with the spec guys for clarification. My particular case is that with GF4, I am now forced to create glassfish-web.xml or glassfish-ejb.xml to map the resources. If I don't, there is no way to configure the mapping using @Resource(name="xxx") I thought Sun/Oracle wanted to be more standardized and eliminate glassfish-xxx files wherever possible? With this change, there is no way to configure a resource without glassfish-xxx files. Thank you

          People

          • Assignee:
            lemon_zhang
            Reporter:
            lprimak
          • Votes:
            5 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: