// which are defined on the SEI are not defined as operations in the WSDL.
// Although they usually specific the same OperationName as the WSDL operation,
// there may be cases where they do not.
// TODO: Is this path an error path, or can the async methods specify different operation names than the
// WSDL operation?
OperationDescription operation = new OperationDescriptionImpl(seiMethod, this);
addOperation(operation);
} else {
// Currently Axis2 does not support overloaded operations. That means that even if the WSDL
// defined overloaded operations, there would still only be a single AxisOperation, and it
// would be the last operation encounterd.
// HOWEVER the generated JAX-WS async methods (see above) may (will always?) have the same
// operation name and so will come down this path; they need to be added.
// TODO: When Axis2 starts supporting overloaded operations, then this logic will need to be changed
// TODO: Should we verify that these are the async methods before adding them, and treat it as an error otherwise?
// Loop through all the opdescs; if one doesn't currently have a java method set, set it
// If all have java methods set, then add a new one. Assume we'll need to add a new one.
boolean addOpDesc = true;
for (OperationDescription checkOpDesc : updateOpDesc) {
if (checkOpDesc.getSEIMethod() == null) {
// TODO: Should this be checking (somehow) that the signature matches? Probably not an issue until overloaded WSDL ops are supported.
//Make sure that this is not one of the 'async' methods associated with
//this operation. If it is, let it be created as its own opDesc.
if (!DescriptionUtils.isAsync(seiMethod)) {
((OperationDescriptionImpl) checkOpDesc).setSEIMethod(seiMethod);
addOpDesc = false;
break;
}
}
}
if (addOpDesc) {
OperationDescription operation =
new OperationDescriptionImpl(seiMethod, this);
addOperation(operation);
}
}
}