glassfish
  1. glassfish
  2. GLASSFISH-18807

Whitespace in web service handler chain files should be trimmed

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 3.1.2
    • Fix Version/s: 4.0_b39
    • Component/s: web_services
    • Labels:
      None
    • Environment:

      All

      Description

      When web services are deployed with handler chains, they may refer in the handler chain file to a particular class which implements the handler, as follows:

      <javaee:handler-class>myHandler</javaee:handler-class>

      Glassfish 3.1.2, 3.1.1, and 3.1 all fail to trim any white space that might be before and after that name. This results in the following...

      <javaee:handler-class>myHandler </javaee:handler-class>

      ...leading to a runtime exception:

      [#|2012-04-03T21:59:11.769-0400|SEVERE|glassfish3.1.2|javax.enterprise.webservices.org.glassfish.webservices|_ThreadID=16;_ThreadName=Thread-3;|Unable to load handler class myHandler

      java.lang.ClassNotFoundException: myHandler

      In fact, there is whitespace at the end of the name that is being printed in the logs...

      For more information, see:

      https://forums.oracle.com/forums/thread.jspa?threadID=2369079&tstart=0

      Thanks.

        Issue Links

          Activity

          Hide
          Martin Grebac added a comment - - edited

          Lukasi, am I right you already mentioned this issue some time ago?

          Show
          Martin Grebac added a comment - - edited Lukasi, am I right you already mentioned this issue some time ago?
          Hide
          Lukas Jungmann added a comment -

          content of handler-class element must be a string without leading/trailing space(s), as per javaee:string definition in http://java.sun.com/xml/ns/javaee/javaee_5.xsd, and as such it is treated and correctly reports that class "myHandler " is not found

          Show
          Lukas Jungmann added a comment - content of handler-class element must be a string without leading/trailing space(s), as per javaee:string definition in http://java.sun.com/xml/ns/javaee/javaee_5.xsd , and as such it is treated and correctly reports that class "myHandler " is not found
          Hide
          bland999 added a comment -

          The cited schema states with respect to javaee:string the following:

          "This is a special string datatype that is defined by Java EE as
          a base type for defining collapsed strings. When schemas
          require trailing/leading space elimination as well as
          collapsing the existing whitespace, this base type may be
          used."

          Those two sentences clarify what the end result should be, but I wonder if it is so clear about WHO should be responsible for that end result. I have seen multiple people independently complaining about this type of error within the Glassfish code going back 5 years. It seems to me that if the code can be enhanced to at least strip away leading and trailing whitespace, that would still be advantageous.

          If you don't agree, then AT MINIMUM, it would be greatly useful to simply add QUOTES to the error message that reports the error as follows:

          Unable to load handler class "myHandler " <<<<--- clearly show the extra spaces here.

          There are other places where Class.forName is being called where the same potentially confusing message is being printed.

          Keep in mind that most JAX-WS developers do not know when a javaee:string is being used versus an xsd:string. I thoroughly agree that at the end of the day, the developer is responsible, but with a little bit of helpful code, Glassfish could be so much more clearer in this case.

          Thanks for listening. I've been using Glassfish for more than 5 years now, and it is my application server of choice, no question about that. Great job, Glassfish team!

          Show
          bland999 added a comment - The cited schema states with respect to javaee:string the following: "This is a special string datatype that is defined by Java EE as a base type for defining collapsed strings. When schemas require trailing/leading space elimination as well as collapsing the existing whitespace, this base type may be used." Those two sentences clarify what the end result should be, but I wonder if it is so clear about WHO should be responsible for that end result. I have seen multiple people independently complaining about this type of error within the Glassfish code going back 5 years. It seems to me that if the code can be enhanced to at least strip away leading and trailing whitespace, that would still be advantageous. If you don't agree, then AT MINIMUM, it would be greatly useful to simply add QUOTES to the error message that reports the error as follows: Unable to load handler class "myHandler " <<<<--- clearly show the extra spaces here. There are other places where Class.forName is being called where the same potentially confusing message is being printed. Keep in mind that most JAX-WS developers do not know when a javaee:string is being used versus an xsd:string. I thoroughly agree that at the end of the day, the developer is responsible, but with a little bit of helpful code, Glassfish could be so much more clearer in this case. Thanks for listening. I've been using Glassfish for more than 5 years now, and it is my application server of choice, no question about that. Great job, Glassfish team!
          Hide
          bland999 added a comment -

          By the way, in a similar issue from "way back when", it was implied that this type of trimming on a "previous version of Glassfish" used to work...

          See http://java.net/jira/browse/GLASSFISH-8615

          Show
          bland999 added a comment - By the way, in a similar issue from "way back when", it was implied that this type of trimming on a "previous version of Glassfish" used to work... See http://java.net/jira/browse/GLASSFISH-8615

            People

            • Assignee:
              Lukas Jungmann
              Reporter:
              bland999
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: