DO NOT REPLY [Bug 22262] New: - block commented "this never happens" happens, a lot

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22262>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22262

block commented "this never happens" happens, a lot

           Summary: block commented "this never happens" happens, a lot
           Product: Axis
           Version: current (nightly)
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Serialization/Deserialization
        AssignedTo: axis-dev@ws.apache.org
        ReportedBy: Eric.D.Friedman@wellsfargo.com


In MethodCache, there is a try {} catch {} block that attempts to find classes
named *_Helper.  The catch side of that block is commented "should never happen
--> assert false;" but this is actually quite a common case -- WSDL2Java, to
cite one rather obvious example, doesn't generate _Helper classes.

Worse, the cache doesn't record failed searches, so those are always repeated. 
In my application, that every message results in searches for a getDeserializer
method on java.lang.String (to cite just one of several examples), followed by a
search for java.lang.String_Helper.

Clearly the cache needs to take note of the fact that a search has already been
unsuccessfully tried.  As things stand, my profiling shows that this code (and
the resulting I/O, in particular) is sucking up a lot of time.

We might want to have a new AxisProperty that would allow applications to
indicate that they do/don't use _Helper classes for binding.  I never use these
and could realize some savings by disabling the searches for them, as those
searches are always worst case.