Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0004840Openbravo ERPZ. Otherspublic2008-09-08 08:592008-09-17 13:29
networkb 
cromero 
highmajoralways
closedno change required 
5
2.35MP5 
 
Core
No
0004840: When you install WebServices the name of the parameters is not catch properly
After 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

No tags attached.
depends on backport 0004850 closed cromero When you install WebServices the name of the parameters is not catch properly 
depends on backport 0004851 closed cromero When you install WebServices the name of the parameters is not catch properly 
Issue History
2008-09-08 08:59networkbNew Issue
2008-09-08 08:59networkbAssigned To => cromero
2008-09-08 08:59networkbsf_bug_id0 => 2099694
2008-09-08 08:59networkbRegression testing => No
2008-09-08 11:12cromeroStatusnew => scheduled
2008-09-08 11:12cromeroAssigned Tocromero => iperdomo
2008-09-08 11:12cromerofix_in_branch => trunk
2008-09-17 13:15cromeroAssigned Toiperdomo => cromero
2008-09-17 13:29cromeroStatusscheduled => closed
2008-09-17 13:29cromeroNote Added: 0009046
2008-09-17 13:29cromeroResolutionopen => no change required

Notes
(0009046)
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.