Bug when specifying url-pattern in web.xml

Question

Hi
          I have been using Weblogic 6.0 Beta and managed to specify the following
          security constraint
          <security-constraint>
          <web-resource-collection>
          <web-resource-name>SecurePages</web-resource-name>
          <description>no description</description>
          <url-pattern>/control/signin</url-pattern>
          <url-pattern>/control/refreshUser</url-pattern>
          <url-pattern>/control/updateUser</url-pattern>
          <url-pattern>/control/deleteaddress</url-pattern>
          <url-pattern>/control/updateaddress</url-pattern>
          <url-pattern>/control/refreshcontacts</url-pattern>
          <url-pattern>/control/updatecard</url-pattern>
          <http-method>POST</http-method>
          <http-method>GET</http-method>
          </web-resource-collection>
          </security-constraint>
          This works fine as you would expect. I have upgraded to Weblogic 6.0 Service
          Pack 1 Rolling Patch 1 and the same web.xml file no longer works. When you
          try and start the server Weblogic hangs just after loading the Oracle driver
          that I use.
          The odd behaviour is that if I change the order of the url-pattern elements
          so that the updatecard URL is above the refreshUser URL the server starts!
          (shown below)
          <url-pattern>/control/signin</url-pattern>
          <url-pattern>/control/updatecard</url-pattern>
          <url-pattern>/control/refreshUser</url-pattern>
          <url-pattern>/control/updateUser</url-pattern>
          <url-pattern>/control/deleteaddress</url-pattern>
          <url-pattern>/control/updateaddress</url-pattern>
          <url-pattern>/control/refreshcontacts</url-pattern>
          A deadlock condition appears to occur, a section of the thread dump looks
          like:
          "Reference Handler" daemon prio=10 tid=0x8990b20 nid=0x7dc waiting on
          monitor [0
          x8c0f000..0x8c0fdc4]
          at java.lang.Object.wait(Native Method)
          at java.lang.Object.wait(Object.java:420)
          at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:110)
          "main" prio=5 tid=0x234ce0 nid=0x6cc runnable [0x6e000..0x6fc3c]
          at weblogic.servlet.utils.URLMatchMap.put(URLMatchMap.java:156)
          at
          weblogic.servlet.security.internal.WebAppSecurity.setConstraints(WebA
          ppSecurity.java:77)
          Looking at the weblogic.jar file the URLMatchMap class is a new addition
          over the original Weblogic 6.0. It seems that the put method of the
          URLMatchMap may be going into an infinite loop, dependant on the URLs that
          are being entered. The fact that changing the order of the URLs overcomes
          the bug seems to suggest there may be some coding error in this new class.
          A fix would be great if anyone has one.
          Chris Mein
          

Answer 1

          Just wondering if anyone ever came up with the solution to the bug with WL 6.0
          sp1, mentioned by Chris, below. Any information on this would be greatly appreciated.
          Tony
          "Chris Mein" <[email protected]> wrote:
          >Hi
          >
          >I have been using Weblogic 6.0 Beta and managed to specify the following
          >security constraint
          >
          ><security-constraint>
          > <web-resource-collection>
          > <web-resource-name>SecurePages</web-resource-name>
          > <description>no description</description>
          > <url-pattern>/control/signin</url-pattern>
          > <url-pattern>/control/refreshUser</url-pattern>
          > <url-pattern>/control/updateUser</url-pattern>
          > <url-pattern>/control/deleteaddress</url-pattern>
          > <url-pattern>/control/updateaddress</url-pattern>
          > <url-pattern>/control/refreshcontacts</url-pattern>
          > <url-pattern>/control/updatecard</url-pattern>
          > <http-method>POST</http-method>
          > <http-method>GET</http-method>
          > </web-resource-collection>
          > </security-constraint>
          >
          >This works fine as you would expect. I have upgraded to Weblogic 6.0
          >Service
          >Pack 1 Rolling Patch 1 and the same web.xml file no longer works. When
          >you
          >try and start the server Weblogic hangs just after loading the Oracle
          >driver
          >that I use.
          >
          >The odd behaviour is that if I change the order of the url-pattern elements
          >so that the updatecard URL is above the refreshUser URL the server starts!
          >(shown below)
          >
          ><url-pattern>/control/signin</url-pattern>
          ><url-pattern>/control/updatecard</url-pattern>
          ><url-pattern>/control/refreshUser</url-pattern>
          ><url-pattern>/control/updateUser</url-pattern>
          ><url-pattern>/control/deleteaddress</url-pattern>
          ><url-pattern>/control/updateaddress</url-pattern>
          ><url-pattern>/control/refreshcontacts</url-pattern>
          >
          >A deadlock condition appears to occur, a section of the thread dump looks
          >like:
          >
          >"Reference Handler" daemon prio=10 tid=0x8990b20 nid=0x7dc waiting on
          >monitor [0
          >x8c0f000..0x8c0fdc4]
          > at java.lang.Object.wait(Native Method)
          > at java.lang.Object.wait(Object.java:420)
          > at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:110)
          >
          >"main" prio=5 tid=0x234ce0 nid=0x6cc runnable [0x6e000..0x6fc3c]
          > at weblogic.servlet.utils.URLMatchMap.put(URLMatchMap.java:156)
          > at
          >weblogic.servlet.security.internal.WebAppSecurity.setConstraints(WebA
          >ppSecurity.java:77)
          >
          >Looking at the weblogic.jar file the URLMatchMap class is a new addition
          >over the original Weblogic 6.0. It seems that the put method of the
          >URLMatchMap may be going into an infinite loop, dependant on the URLs
          >that
          >are being entered. The fact that changing the order of the URLs overcomes
          >the bug seems to suggest there may be some coding error in this new class.
          >
          >A fix would be great if anyone has one.
          >
          >Chris Mein
          >
          >