Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004851Openbravo ERPZ. Otherspublic2008-09-08 11:122008-09-17 13:29
Reporternetworkb 
Assigned Tocromero 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOS5OS Version
Product Version2.35MP5 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0004851: When you install WebServices the name of the parameters is not catch properly
DescriptionAfter run ant installWebService task, when you enter on
http://IP_DIRECTION:PORT/CONTEXT_NAME/services [^]
and then on ExternalSells WebServices
you can see that the name of the parameters is
in0, in1, in2, in3 instead of the name entered on the java files
at
src/org/openbravo/erpCommon/ws/ExternalSales

Steps To Reproduce
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
blocks defect 0004840 closed cromero When you install WebServices the name of the parameters is not catch properly 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2008-09-08 11:12cromeroNew Issue
2008-09-08 11:12cromeroAssigned To => iperdomo
2008-09-08 11:12cromeroStatusnew => scheduled
2008-09-17 13:15cromeroAssigned Toiperdomo => cromero
2008-09-17 13:29cromeroRegression testing => No
2008-09-17 13:29cromeroStatusscheduled => closed
2008-09-17 13:29cromeroNote Added: 0009048
2008-09-17 13:29cromeroResolutionopen => no change required

Notes
(0009048)
cromero   
2008-09-17 13:29   
I have reviewed the Openbravo webservices and I have not been able to reproduce your problem.

It is true that when you install the webservices the name of method's parameters gets to in0, in1, in2, etc., but this should not affect their functionality. Indeed I have tested it and even with these parameter's names the webservices are answering to my requests (basically, when I attack a webservice, I am invoking a function with some values, so it doesn't matter the name that the function uses internally for them, just only the position and correct type).

In any case, it exists a workaround in order to see the params with the proper name: setting the debug.level property in the build.xml file to true and recompile the application.
  <property name="debug.level" value="true"/>

This workaround makes the java compiler to generate additional info for debugging, so it is not indicated for production environments.