axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 25626] New: - JavaServiceDesc ignores StopClasses property
Date Thu, 18 Dec 2003 14:32:28 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25626>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25626

JavaServiceDesc ignores StopClasses property 

           Summary: JavaServiceDesc ignores StopClasses property
           Product: Axis
           Version: 1.2 Alpha
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Deployment / Registries
        AssignedTo: axis-dev@ws.apache.org
        ReportedBy: micantunes@bes.pt


JavaServiceDesc is ignoring StopClasses property for overloading methods, 
during initialization by introspection.

My problem is that I do not want the overloaded methods declared in super 
classes to be found, I only want to expose the operations that correspond to 
the methods declared in the service class. I've tried defining my own 
RPCProvider extension so that I could set the StopClasses  property but that 
didn't worked. Then I looked into the JavaServiceDesc  implementation and found 
that the StopClasses  property is not checked when looking for overloaded 
methods in the super class. So I changed the createOperationsForName so that it 
checks StopClasses  when looking for overloaded methods. Here is the code after 
my modification:

    private void createOperationsForName(Class implClass, String methodName) 
    { 
        // If we're a Skeleton deployment, skip the statics. 
        if (isSkeletonClass) { 
            if (methodName.equals("getOperationDescByName") || 
                methodName.equals("getOperationDescs")) 
                return; 
        } 

        Method [] methods = implClass.getDeclaredMethods(); 

        for (int i = 0; i < methods.length; i++) { 
            Method method = methods[i]; 
            if (Modifier.isPublic(method.getModifiers()) && 
                    method.getName().equals(methodName)) { 
                createOperationForMethod(method); 
            } 
        } 

        Class superClass = implClass.getSuperclass(); 
        if (superClass != null && 
                !superClass.getName().startsWith("java.") && 
                !superClass.getName().startsWith("javax.")&& 
                (stopClasses == null || 
                !stopClasses.contains(superClass.getName())))  //<------- added 
check for stop classes

        { 
            createOperationsForName(superClass, methodName); 
        } 

    }  

I have made this change in Axis 1.1 and  now in Axis 1.2 alpha and to avoid any 
further changes in future Axis versions, I would like to know if this is the 
intended behavior, and if it is, could  Axis at least provide some kind of 
service configuration parameter to turn off overloaded methods discovery; or 
perhaps could org.apache.axis.handlers.soap.SOAPService define a factory method 
for creating ServiceDesc instances that could be overridden in subclasses to 
allow JavaServiceDesc extensions???

Mime
View raw message