Summary: 1.) most of openbravo internals (java code) which were public but shouldn't be public in our opinion will be changed to private (pi now, shipped in MP2) 2.) If a module is using a now private part it will fail to compile and needs to be changed. Several solutions for this are possible: 2.a) Don't use the now private part 2.b) Make a copy of the now private part and use the copy. The copy is then in the maintenance ownership of the module 2.c) Raise the issue to us, if you think a specific part should be public and usable by a module. After a review we might open up this part and include in the public API. 3.) Ideally you should test your module which this changes api before the MP2 release.
Hi, this mail describes part two of the public/private definition for this we are auditing the visibility of all java code in openbravo right now to define which parts can be publicly used (i.e. by a module) and which cannot. We will commit the needed changes for this into the pi repository today and plan to ship the changes with the MP2 maintenance pack. The related feature request is 9317 [1] and the commit will be related to that issue. Lots of classes/methods which we think should not be accessible or reused by a module are then non-public. Examples: - individual report/manual form/java-process implementations - internals of many classes This can affect a number of modules if they use a part which is now no longer publicly available. As described in the summary it should be checked if the use of the private part is really needed. If yes, then either a copy of the private part needs to be made inside the module or the issue should be raised to us so we can discuss if the part should be included into the public API. Note: If a module author decides to copy a private part into his module he is responsible of maintaining the copy. For a small number of changes which could be needed in a module the needed change and the reasoning for it is outlined below. First example: Class: org.openbravo.base.HttpBaseServlet No longer accessible methods: - arrayDobleEntrada - arrayEntradaSimple Can now be found in the class: org.openbravo.utility.Utility Why the change? These methods have been only used in a very small number of servlets (about 10) but because of their placement they have been inherited into all servlets. In addition they did not access any of the servlet state but are really static utility methods. Change needed for a user: instead of just calling the method directly in the servlet now the call needs to be Utility.arrayDobleEntrada . Second example: Class: org.openbravo.base.secureapp.HttpSecureAppServlet No longer accessible methods: - advise (one of the overloaded methods only) - advisePopUpRefresh (some of the overloaded methods only) - bdError (one of the overloaded methods only) - bdErrorGeneralPopUp (one of the overloaded methods only) - bdErrorGeneral (some of the overloaded methods only) - printPageClosePopUpWindow (one of the overloaded methods only) - printPageClosePoUpAndRefresh (one of the overloaded methods only) Why the change? All of these methods exist in several overloaded version with the same method name but different signature. The removed version of these utility methods had no user inside the openbravo codebase. Change needed for a user: Use one of the other overloaded method versions still available. The developer guide contains a reference to the generated javadoc [2] corresponding to the java code. We will update the online copy of the javadoc after doing this visibility change. This javadoc then shows the publicly usable part of the api. Hint: An servlet should normally not be called directly but invoked by referring to a url mapping they have. If the call is done it that way the mapping will be stable even if some implementation detail of the classes (manually written or generated does change). Regards, Stefan Huehner [1] https://issues.openbravo.com/view.php?id=9317 [2] http://wiki.openbravo.com/wiki/ERP/2.50/Developers_Guide/Reference/JavaAPI ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Openbravo-development mailing list Openbravo-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbravo-development