Hi Michael, > I would like to suggest the > processor generate a warning in case there are any annotations such as > @WebMethod in the implementation bean and the bean refers to an endpoint > interface.
It doesn't take that much time so let me implement this later. > If there is an endpoint interface, the > implementation bean is *not* required to have @WebMethod annotations. > [The methods in the endpoint interface isn't required to have @WebMethod > annotations either.] So there shouldn't be an exception in this case. I've implemented the way you said. ( I attached a patch and test cases for this. plz throw away the last files I sent you, Michael) The original WebServiceTYPEMetadata had only <Collection>WebServiceMETHODMetadata collection variable (named methods) which are always published by Web Service. In case the object model is for the service implementation bean, it contains only methods annotated with @WebMethod. In case the object model is for the service endpoint interface, it contains all methods no matter they are annotated with @WebMethod or not. So when comparing the methods' signature of the service implementation bean and one of the endpoint interface , the processor has to have the service implementation bean's methods which are not annotated with @WebMethod also. Otherwise, the processor is required to scan the service implementation bean class to retrieve methods with reflection again. It costs much. Thus, I refactored WebServiceTYPEMetadata for the service implementation bean to hold non-annotated methods as well in a new added Collection variable named nonAnnotatedMethods. ( The variable name, nonAnnotatedMethods, is not right, though. It should be hiddenMethods or something like that. Anyways, I go with nonAnnotatedMethods for now. ) Unfortunately, one problem raised by APT. Although I implemented WsmAnnotationProcessor to throw an exception when the inconsistency is found while constructing an object model of the endpoint interface, APT ( com.sun.tools.apt.Main().compile(...) ) never throws the exception up to the caller and even the return-value of the compile method is always zero (which means the compiling succeeded). What APT does is just catch the exception and print the error message to System.err and always return zero. So the caller of APT cannot tell the annotation processing succeeded or not programmatically. There're two ways to avoid this problem. The first one is intercepting the System.err to figure out whether an exception had been thrown. ( this is obviously silly though ) The second one is ,for example, adding a new static variable which holds the result status of the processing in WsmAnnotationProcessor and the caller retrieves the variable to check whether the processing succeeded or not. What do you guys think ?? Wolfgang. ps) The drt/tests/org/apache/beehive/wsm/jsr181/processor/apt/WsmAnnotationProcessorEndpointInterface2Test.java test case in new_files.tar.gz always fails. This relates to what I said above.
