axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Derek Foster (JIRA)" <>
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
             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, 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:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message