DO NOT REPLY [Bug 12828] New: - userguide.example3.Client doesn't set a default URL

[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=12828>.
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=12828

userguide.example3.Client doesn't set a default URL

           Summary: userguide.example3.Client doesn't set a default URL
           Product: Axis
           Version: current (nightly)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Minor
          Priority: Other
         Component: Samples
        AssignedTo: axis-dev@xml.apache.org
        ReportedBy: william.pohlmann@vertexinc.com


Some samples set a default URL for the service and others do not.  

The userguide doesn't mention specifying an argument for the URL when invoking 
the client, but in not doing this, it defaults to what is set in 
org.apache.axis.utils.Options (http://localhost:8080/axis/servlet/AxisServlet)

With this default, the processing path for the request through Axis is 
different.  URLMapper relies on the HTTP request extra path information in 
looking up a target service.  With this default URL, it will be null and no map 
will occur.

So the request ends up using the "kludge" portion in 
org.apache.axis.server.AxisServer  where a last ditch parse of the message is 
done to try to determine a service before faulting.

Given that the external behavior remains the same, this may not warrant being a 
bug.  But if you use it to learn Axis processing it is a bit problematical.  
Since it is the first advanced sample, there is a chance others could end up 
looking to it the same way I did.  Seeing the execution path for the sample go 
down the kludge path isn't necessarily a comforting introduction.

I couldn't quite postulate under what other circumstances this forced parse 
would be needed, but I guess that is better served as a development question 
than part of this bug.