axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <dava...@gmail.com>
Subject Re: [Axis2] My experience creating a WSDL2Java generated ADB service
Date Fri, 12 May 2006 03:50:00 GMT
Wow!!! Excellent feedback. Please give us a chance to digest it and
get back 2 u.

thanks again,
dims

On 5/11/06, Mike_McAngus@wendys.com <Mike_McAngus@wendys.com> wrote:
>
> I am trying to create a Proof of Concept (POC) for Enterprise and B2B
> Services at Wendy's Int'l, Inc.
>
> As part of this POC, I created a WSDL for an in-house service and then used
> the WSDL2Java tool to translate this WSDL to Java Classes for use with ADB
> binding.
>
> In this document, I describe the issues I encountered setting up what I
> consider to be a simple POC.
> Some, if not most, of these issues should be opened as JIRA Bugs and
> Enhancement Requests, but I didn't want to open a bunch of little requests
> that may seem disconnected, nor did I want to create one huge request with
> all this stuff in it.
>
> I encountered most of these issues in Axis2 0.95 and all of them in 1.0.
>
> I'm attaching my WSDL file so that you may generate the files and follow
> along.  In the WSDL I documented choices that I was forced to make (like not
> including our Global Schema in the WSDL).  These choices were forced by the
> limitations of the ADB binding.
>
> I'm also including my build.xml so you too can build the aar.  However,
> without the business logic and our legacy code and tables the resulting
> application will not do anything.   Finally, I'm including my
> AppReleases.css so you can compare how the returned WSDL appears in the
> Browser and to the way I want it to appear (assuming JIRA issue Axis2-618 is
> resolved).
>
> I should say here that I chose ADB because the application framework created
> under ADB is more intuitive and lighter weight than the framework created
> under XMLBeans.
>
> Some preliminary information about my environment and what was created by
> WSDL2Java.
>
> Environment:
>         Windows XP Pro SP2
>         Tomcat 5.0.28
>         Java 1.4.2_10
>         Axis2 1.0 (and Axis2 0.95 except where noted)
>
> Service Name:
>         AppRelease
>
> Messages In:
>         getAppReleasesRequest
>         getAppReleasesSortedRequest
>
> Message Out:
>         getAppReleasesResponse
>
> WSDL2Java command:
>         wsdl2java -o ..\ -s -p com.wendys.ws -t -ss -sd -d adb -g -ssi -pn
> AppReleasePort -sn AppRelease -uri .\AppRelease.wsdl
>
> Files created by WSDL2Java (I've identified one new file that was created
> because of the new -ssi runtime directive):
>         <mypackagepath>/
>                 AppReleaseMessageReceiverInOut.java
>                 AppReleaseSkeleton.java
>                 AppReleaseSkeletonInterface.java  (new)
>                 AppReleaseStub.java
>         <mypackagepath>/apprelease
>                 AppRelease.java
>                 GetAppReleasesRequest.java
>                 GetAppReleasesResponse.java
>                 GetAppReleasesSortedRequest.java
>                 GetAppReleasesType.java
>
>
> The reason that the following issues are important is because if I modify my
> application to fix them, and if I subsequently have to modify my WSDL
> (perhaps to add a new Operation or to change the definition of an element)
> and run WSDL2Java again, the following files will be overwritten (thus
> necessitating some reapplying my changes):
>         <mypackagepath>/apprelease/AppRelease.java
>
> <mypackagepath>/apprelease/GetAppReleasesRequest.java
>
> <mypackagepath>/apprelease/GetAppReleasesResponse.java
>
> <mypackagepath>/apprelease/GetAppReleasesSortedRequest.java
>         <mypackagepath>/apprelease/GetAppReleasesType.java
>
>
> Now, for the issues.
>
> 1.   Annoyance:  WSDL2Java.bat issues a warning because Log4J cannot be
> properly configured.
> When running WSDL2Java.bat, the following warning is displayed:
>         log4j:WARN No appenders could be found for logger
> (org.apache.axis2.i18n.ProjectResourceBundle).
>         log4j:WARN Please initialize the log4j system properly.
>
> To fix this, add the following line:
>         set
> AXIS2_CLASS_PATH=%AXIS2_CLASS_PATH%;%AXIS2_HOME%\modules\core\conf
>
> into the WSDL2Java.bat file, after these lines:
>         rem loop through the libs and add them to the class path
>         set AXIS2_CLASS_PATH=%AXIS2_HOME%
>         FOR %%c in ("%AXIS2_HOME%\lib\*.jar") DO set
> AXIS2_CLASS_PATH=!AXIS2_CLASS_PATH!;%%c
>
> %AXIS2_HOME%\modules\core\conf is the location of the Axis2-distributed
> log4j.properties file.
>
> Once I made this change I learned that the Sourceforge Jalopy jar is not
> available, and so the output of my Source files is not is not tidied up.  I
> don't know if the tidying up of files was available in Axis2 0.95, so I've
> continued to work with untidy java files.
>
>
> 2.   Bug:  Jalopy jar is not available in the Axis2 binary distribution.
>
>
> 3.  Annoyance:  WSDL2Java has the capability to tidy up Java source using
> Jalopy, but no similar functionality has been provide for the XML files nor
> the generated WSDL using xmlTidy.
>
>
> 4.   Bug:  GetAppReleasesType.java does not compile.
> In the GetAppReleasesType#Factory.parse method, a reference
> is made to the nonexistent method
> "org.apache.axis2.databinding.utils.ConverterUtil.convertToNonNegativeInteger(content)".
> The correct method name is
> "org.apache.axis2.databinding.utils.ConverterUtil.convertTononNegativeInteger(content)".
>  Note:  There is a correct reference to the
> org.apache.axis2.databinding.utils.ConverterUtil.convertTononNegativeInteger
> method in the AppRelease#Factory.parse method.  This leads me to conclude
> that you are not using common methods to determine which conversions to
> perform on input vs. output content, and so bugs that are caught in one
> class may still be unidentified in another class.
>
>
> 5.   Bug:  In AppRelease.java, the values for localAvailabilityStopTracker
> and localReleaseDescTracker are not set properly.
> In the setters for the attributes that these Trackers track, the following
> code should be used to ensure that the Trackers are set properly:
> For localAvailabilityStopTracker -
>     public void setAvailabilityStop(java.util.Date param) {
>
>         // update the setting tracker
>         localAvailabilityStopTracker = (param != null);
>
>         this.localAvailabilityStop = param;
>     }
>
> For localReleaseDescTracker -
>     public void setReleaseDesc(java.lang.String param) {
>
>         // update the setting tracker
>         localReleaseDescTracker = true;
>
>         this.localReleaseDesc = param;
>     }
>
> As generated by WSDL2Java, the Tracker is set to true even if the variable
> it is tracking is unset back to null.
>
>
> 6.   Bug:  In the AppReleaseResponse.setReturn method, the value of
> local_returnTracker may be set to true, but it will never be unset.
> Similar to Bug #3, the local_returnTracker should be set using the following
> code to ensure that it is unset when the supplied parm is null:
>     public void
> set_return(com.wendys.ws.apprelease.AppRelease[] param) {
>
>         validate_return(param);
>
>         // update the setting tracker
>         local_returnTracker = (param != null);
>         local_return = param;
>     }
>
>
> 7.   Annoyance:  In the AppReleaseResponse.addReturn method,
> local_returnTracker only needs to be set to true when the local_return array
> is instantiated, not every time an AppRelease is added to the array.
>
>
> 8.   Bug:  Under Axis2 1.0, only the system generated WSDL is served up in
> response to the Service?wsdl command.  Under Axis2 0.95 if a WSDL was
> located in the META-INF directory then that WSDL would be served up instead.
>  This has already been submitted as JIRA Bug Axis2-690.
>
>
> 9.   Annoyance:  WSDLs are not served up with the Stylesheet that is
> specified in the original WSDL.  In fact, under 0.95, even if the original
> WSDL is returned that WSDL has the stylesheet element removed.  This has
> been submitted as JIRA Enhancement Request Axis2-618.
>
>
> 10.   Annoyance:  In AppReleaseStub, the default constructor is not
> necessary.
> This constructor is used only by the Test class, which can supply the
> necessary service endpoint URL when it instantiates the stub class.  This
> way, the URL of the Service is not hard-coded anywhere in the application.
>
>
> 11.   Annoyance:  WSDL2Java reverses the order of the Operations listed in
> the WSDL.
> In my WSDL the Operations are listed in this order:  getAppReleases,
> getAppReleasesSorted.  Yet, in all the artifacts created by WSDL2Java, the
> operations, their messages, their associated methods, their entries in the
> services.xml file, their order in the generated WSDL file and their order in
> the axis2-admin/listServices page is reversed from what exists in my WSDL
> file.  I prefer to have messages and operations in WSDLs and attributes and
> methods in Classes in alphabetical order.  I prefer that my tools maintain
> the order that I have established.
>
>
> 12.  Annoyance:  WSDL2Java replaces my defined namespace prefix with "ns1".
> See AppRelease, GetAppReleasesRequest, GetAppReleasesResponse,
> GetAppReleasesSortedRequest and GetAppReleasesType.
> I see no reason not to use the namespace prefix specified in the WSDL that
> WSDL2Java reads, but if you MUST change the namespace prefix couldn't you
> use the more traditional "tns"?
>
>
> 13.  Annoyance:  There are a large number of unused private methods, method
> parameters and method variables in the generated classes.
> Eclipse can tell you about unused junk in the generated classes.  Perhaps
> these artifacts are no longer needed and can be removed?
>
>
> 14.  Annoyance:  The log4j.properties file shipped with Axis2 circumvents
> the ability for the developers to change the logging level of their classes.
> I have included a modified log4j.properties file that actually allows me to
> put my classes into DEBUG level while leaving Axis2 and Tomcat logging at
> their levels.
>
>
> 15.  Annoyance:  Axis2 only allows for Log4J.properties to configure
> logging, not Log4J.xml
> Log4J can be configured using either a properties or an xml file.  There is
> a growing number of Logging capabilities that are only configurable using
> the XML file.  The code that sets up configuration of Log4J in Axis2 should
> allow for both types of configuration files.
>
>
> 16.  Annoyance:  Axis2 does not use ConfigureAndWatch capabilities of Log4J
> Log4J can be configured using a ConfigureAndWatch method that causes Log4J
> to monitor its configuration file and automatically apply changes made to
> that file to its configuration.  This means that if support personnel need
> to modify the logging configuration of a production application, only the
> log4j configuration file needs to be modified and the Application server
> does not need  to be restarted.
>
> Following is a snippet of code for a Log4jUtils class that addresses
> Annoyances 15 and 16.
> The configureAndWatch method of this utility class should be called by an
> initialization servelet or some other configuration and initialization
> class.
>
> ------
>
> import org.apache.log4j.BasicConfigurator;
> import org.apache.log4j.PropertyConfigurator;
> import org.apache.log4j.helpers.FileWatchdog;
> import org.apache.log4j.net.SyslogAppender;
> import org.apache.log4j.xml.DOMConfigurator;
>
>     .
>     .
>     .
> /**
>  * A collection of static utility methods for logging with Log4J.
>  */
> public final class Log4jUtils {
>     private static final Logger LOG = Logger.getInstance(Log4jUtils.class);
>     private static loggingConfigured = false;
>
>     private Log4jUtils() {
>         // All methods are static, this class should not be instantiated
>     }
>
>     .
>     .
>     .
>
>     /**
>      * Implements configureAndWatch for the current ClassLoader hierarchy
> using the Log4J
>      * default number of seconds.
>      */
>     public static void configureAndWatch() {
>         configureAndWatch(FileWatchdog.DEFAULT_DELAY);
>     }
>
>     /**
>      * Implements configureAndWatch for the current ClassLoader hierarchy.
>      *
>      * @param watchMillisecs The number of milliseconds to wait between
> checking to see if the
>      * log4j configuration file has changed.
>      */
>     public static void configureAndWatch(long watchMillisecs) {
>         if (loggingConfigured) return;
>
>         Class myClass = Log4jUtils.class;
>         ClassLoader classLoader = myClass.getClassLoader();
>
>         // Initialize LOG4J
>         URL resourceUrl = classLoader.getResource("log4j.xml");
>         if (resourceUrl != null) {
>             String configFile = resourceUrl.getFile();
>             DOMConfigurator.configureAndWatch(configFile,
> watchMillisecs);
>         } else {
>             resourceUrl = classLoader.getResource("log4j.properties");
>             if (resourceUrl != null) {
>                 String configFile = resourceUrl.getFile();
>
> PropertyConfigurator.configureAndWatch(configFile,
> watchMillisecs);
>             } else {
>                 // Since we aren't going to be able to pull our "real"
> settings,
>                 // let's at least make sure we get some output
>                 BasicConfigurator.configure();
>
>                 // Log an error with detail regarding the problem (and
> suspected cause)
>                 LOG.error(myClass.getName(), "Unable to find log4j.xml or
> log4j.properties. " +
>                                              "Make sure the log4j
> configuration file is in the Classpath.");
>             }
>         }
>         loggingConfigured = true;
>     }
>
>
> Hope this all helps.
>
>
>
>  Mike McAngus
>  Associate Chief Engineer, Enterprise Architecture
>  Wendy's International, Inc.
>
>
>
>
>


-- 
Davanum Srinivas : http://wso2.com/blogs/

Mime
View raw message