Thanks for your reply. I could easily extend the patch
provided by Nandana in AXIS2-4066
and it would work, but my intention was to find a better
approach for solving this and similar requirements in the
future. I will try to explain the point using the patch in AXIS2-4066
The goal of this patch was to allow for an Axis2 module (in
this case Rampart) to contribute to a WSDL extensibility
element (in this case - <wsa:EndpointReference>).
For example, if an Axis2 web service secured with Rampart
message-level security, Rampart would expose the service
certificate information using an <Identity> element in
the <wsa:EndpointReference> wsdl extensibility lement:
For that to work, Rampart would set this information in an
Axis2 service parameter, then the AxisService2WSDL11 would
check for this parameter and generate an <Identity>
element in the EPR of an <wsdl:port>.
This approach works, but it means that Axis2 wsdl
generation now contains some security-oriented code that
checks for certain parameter and acts accordingly. If any
changes are needed, for example adding support for future
releases of WS-AddressingAndIdentity specification, the
AxisService2WSDL11 needs to be patched again.
IMO this would eventually lead to polluting the wsdl
generation with code which is meant to support certain WS spec
that should otherwise be hosted in an Axis2 module.
Instead, an Axis2 description instance could keep a list of
WSDL extensibility elements attached to it (similarly to the
list of policy components), then any Axis2 module could
manipulate them the way it needs. The WSDL generation would
simply serialize those extensibility elements, without caring
for their content.
This design would encourage people to develop functionality
for handling custom WSDL extensibility elements as part of an
Axis2 module instead of having to contribute patches to Axis2
Does this make sense?