axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Derek Foster (JIRA)" <j...@apache.org>
Subject [jira] Created: (AXIS2-918) WSDL2Java/XMLBeans generated interfaces should not reference inner classes of their own subclasses
Date Fri, 21 Jul 2006 18:50:15 GMT
WSDL2Java/XMLBeans generated interfaces should not reference inner classes of their own subclasses
--------------------------------------------------------------------------------------------------

                 Key: AXIS2-918
                 URL: http://issues.apache.org/jira/browse/AXIS2-918
             Project: Apache Axis 2.0 (Axis2)
          Issue Type: Bug
          Components: databinding, wsdl
    Affects Versions: 1.0
            Reporter: Derek Foster


When I run WSDL2Java on a WSDL document using the XMLBeans data binding (and possibly others),
I get skeleton files that look something like this:

    /**
     *  FEUServiceSkeletonInterface java skeleton interface for the axisService
     */
    public interface FEUServiceSkeletonInterface {
     
		 
        /**
         * Auto generated method signature
         */
        public  crc.feuimport.xmlbeans.wsdl.ReturnDocument acceptFEURecap
        (
          crc.feuimport.xmlbeans.wsdl.RecapDocument param0     
         )
         
           throws crc.feuimport.wsdl2java.FEUServiceSkeleton.FailureException;
    }

Note that this interface (FEUServiceSkeletonInterface) contains a method (acceptFEURecap)
whose throws clause is referencing an inner class of a class which implements the interface
itself (namely, class FEUServiceSkeleton.FailureException is an inner class of FEUServiceSkeleton,
which is a subtype of FEUServiceSkeletonInterface). This is extremely poor design from an
object-oriented design perspective. Subtypes often reference their supertypes, but the reverse
should never be true, as it is in this case. Violating this rule has a variety of problematic
consequences. As the current design exists, for instance, it is impossible for someone to
create their own subtype of FEUServiceSkeletonInterface which will have equal status with
FEUServiceSkeleton, since FEUServiceSkeleton.FailureException is specifically referenced by
the interface. It is also impossible to put FEUServiceSkeletonInterface into a separately
deployable JAR file from FEUServiceSkeleton.

In this case, the specific supertype of exceptions that may be thrown from this method is
pretty clearly a detail of the INTERFACE to this method, rather than part of its IMPLEMENTATION.
Therefore, I think that the code generator should be revised so that the actual declaration
of this exception type is either in its own source file (i.e. not an inner class of FEUServiceSkeleton,
but a separate FailureException.java), or so that the declaration of the exception type is
moved to be an inner class of FEUServiceSkeletonInterface, rather than of FEUServiceSkeleton.
That way, if an implementation of FEUServiceSkeleton or any other subtype of FEUServiceSkeletonInterface
wishes to throw an instance of that specific exception type, it may do so, or it might even
declare its own subclass of that exception type (with, perhaps, added functionality) and throw
that instead.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message