Geronimo
  1. Geronimo
  2. GERONIMO-3806

CLONE -Extraneous WARN messages during deployment of resource-env-refs in EJB jar

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0.2, 2.1, 2.1.1, 2.2
    • Fix Version/s: 2.0.3, 2.1.1, 2.2
    • Component/s: deployment
    • Security Level: public (Regular issues)
    • Labels:
      None
    • Environment:

      Windows XP SP2

    • Patch Info:
      Patch Available
    • Regression:
      Regression

      Description

      During deployment of one of my EJB jar files in my EAR, I get the following WARN messages:

      14:29:37,425 WARN  [AdminObjectRefBuilder] Failed to build reference to Admin object reference [jms/UnsequencedDestination, jms/MailQueue, jms/InboundEventQueue, jms/OutboundQueue, jms/SystemQueue, jms/ActionQueue, jms/SequencedDestination, jms/InboundIntegrationQueue, jms/OutboundEventQueue] defined in plan file, reason - corresponding entry in deployment descriptor missing.
      14:29:37,440 WARN  [ResourceRefBuilder] Failed to build reference to resource reference [jms/ConnectionFactory, jms/QueueConnectionFactory, mail/MailSession, jms/TopicConnectionFactory] defined in plan file, reason - corresponding entry in deployment descriptor missing.
      

      This occurs at the point in the following point in the stack:

      AdminObjectRefBuilder.buildNaming(XmlObject, XmlObject, Module, Map) line: 160
      

      The "specDD" that is passed in is a XML fragment for a specific session bean. However, the "plan" that is passed in contains all the resource-ref and resource-env-ref elements in the openejb-jar.xml plan. Therefore, the "refMap" variable does not get completely emptied out, since the specific session bean will only contain a subset of the resource-env-refs that are defined in the plan.

      1. GERONIMO-3806-r639837.patch
        4 kB
        Manu T George
      2. GERONIMO-3806-2.0.2.patch
        3 kB
        toby cabot

        Issue Links

          Activity

          Hide
          toby cabot added a comment -

          The fix for GERONIMO-3248 causes two warnings in the log when a webapp has a resource-ref in web.xml to a resource adapter in the same .ear:

          16:24:19,032 WARN [ResourceRefBuilder] Failed to build reference to resource reference [] defined in plan file, reason - corresponding entry in deployment descriptor missing.
          16:24:19,311 WARN [ResourceRefBuilder] Failed to build reference to resource reference [] defined in plan file, reason - corresponding entry in deployment descriptor missing.

          This worked OK prior to r572902.

          Show
          toby cabot added a comment - The fix for GERONIMO-3248 causes two warnings in the log when a webapp has a resource-ref in web.xml to a resource adapter in the same .ear: 16:24:19,032 WARN [ResourceRefBuilder] Failed to build reference to resource reference [] defined in plan file, reason - corresponding entry in deployment descriptor missing. 16:24:19,311 WARN [ResourceRefBuilder] Failed to build reference to resource reference [] defined in plan file, reason - corresponding entry in deployment descriptor missing. This worked OK prior to r572902.
          Hide
          toby cabot added a comment -

          Here's a patch that quiets the messages in my case (and adds a couple of debug messages that I found helpful). With this patch applied and log4j screwed down to DEBUG I get:

          16:36:46,764 DEBUG [ResourceRefBuilder] trying to resolve JobCF, type reva.job.ra.ConnectionFactory, resourceRef null
          16:36:46,766 DEBUG [ResourceRefBuilder] initial 0 unresolved 0 refmap 0
          16:36:47,004 DEBUG [ResourceRefBuilder] trying to resolve JobCF, type reva.job.ra.ConnectionFactory, resourceRef null
          16:36:47,005 DEBUG [ResourceRefBuilder] initial 0 unresolved 0 refmap 0

          ... and no warnings.

          Someone who understands the operation of the buildNaming() method better than I do should inspect the code but I believe (from inspection) that it shouldn't break the case that GERONIMO-3248 solved.

          Show
          toby cabot added a comment - Here's a patch that quiets the messages in my case (and adds a couple of debug messages that I found helpful). With this patch applied and log4j screwed down to DEBUG I get: 16:36:46,764 DEBUG [ResourceRefBuilder] trying to resolve JobCF, type reva.job.ra.ConnectionFactory, resourceRef null 16:36:46,766 DEBUG [ResourceRefBuilder] initial 0 unresolved 0 refmap 0 16:36:47,004 DEBUG [ResourceRefBuilder] trying to resolve JobCF, type reva.job.ra.ConnectionFactory, resourceRef null 16:36:47,005 DEBUG [ResourceRefBuilder] initial 0 unresolved 0 refmap 0 ... and no warnings. Someone who understands the operation of the buildNaming() method better than I do should inspect the code but I believe (from inspection) that it shouldn't break the case that GERONIMO-3248 solved.
          Hide
          Manu T George added a comment -

          I am attaching a patch which I feel solves the problem better. Tested it out with an application. Toby If you can test it with yours and verify that it doesn't break your app it will be good.

          Show
          Manu T George added a comment - I am attaching a patch which I feel solves the problem better. Tested it out with an application. Toby If you can test it with yours and verify that it doesn't break your app it will be good.
          Hide
          Manu T George added a comment -

          Toby can you check if my fix works for you

          Show
          Manu T George added a comment - Toby can you check if my fix works for you
          Hide
          toby cabot added a comment -

          Hi Manu, thanks for giving this your attention.

          I tried your patch and it had the same problem as the old code, i.e. it displayed the spurious warnings. The problem appears to be that a resource ref might be resolved after you've added its name to unresolvedRefs.

          I modified your patch so it applies to 2.0.2 (which is what I'm using) and added a line to take the name out of unresolvedRefs if we find it later. That works for my application. I also added back the debug line that I found useful in looking for the problem.

          Thanks!
          Toby

          Show
          toby cabot added a comment - Hi Manu, thanks for giving this your attention. I tried your patch and it had the same problem as the old code, i.e. it displayed the spurious warnings. The problem appears to be that a resource ref might be resolved after you've added its name to unresolvedRefs. I modified your patch so it applies to 2.0.2 (which is what I'm using) and added a line to take the name out of unresolvedRefs if we find it later. That works for my application. I also added back the debug line that I found useful in looking for the problem. Thanks! Toby
          Hide
          Manu T George added a comment -

          Thanks Toby. I missed that. So it follows that we need to remove from the unresolved refs ,the ORB and URL references that are resolved afterwords as well.

          Show
          Manu T George added a comment - Thanks Toby. I missed that. So it follows that we need to remove from the unresolved refs ,the ORB and URL references that are resolved afterwords as well.
          Hide
          Manu T George added a comment -

          Toby has attached a patch for 2.0.2. Just added another patch with tobys changes for trunk as I currently don't have 2.1.1 checked out on my m/c. This file should be very similar in 2.1.1.

          Show
          Manu T George added a comment - Toby has attached a patch for 2.0.2. Just added another patch with tobys changes for trunk as I currently don't have 2.1.1 checked out on my m/c. This file should be very similar in 2.1.1.
          Hide
          Vamsavardhana Reddy added a comment -

          Applied patches submitted by Manu and Toby.

          Completed: At revision: 639953 in trunk
          Completed: At revision: 639955 in branches\2.1
          Completed: At revision: 639957 in branches\2.0

          Please verify and close the JIRA.

          Show
          Vamsavardhana Reddy added a comment - Applied patches submitted by Manu and Toby. Completed: At revision: 639953 in trunk Completed: At revision: 639955 in branches\2.1 Completed: At revision: 639957 in branches\2.0 Please verify and close the JIRA.
          Hide
          Manu T George added a comment -

          closing after testing the scenario i have

          Show
          Manu T George added a comment - closing after testing the scenario i have

            People

            • Assignee:
              Manu T George
              Reporter:
              toby cabot
            • Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development