[ http://issues.apache.org/jira/browse/AXIS2-918?page=all ]
Ajith Harshana Ranabahu resolved AXIS2-918.
-------------------------------------------
Resolution: Fixed
Fixed in the latest SVN. Thanks for pointing out the problem
> 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: wsdl, databinding
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
