--- Cut ---
Hi Gang,
In general new features are added to 2.x, and 1.x gets bug fixes that are
considered important from a user perspective. The issues that you have
been raising seem to be a mixture of the above, so I am not quite sure
what is the best approach, especially as more issues are continuing to
come to light as your work proceeds.
Whatever is done for 1.x should be consistent with the longer term
direction for 2.x, though it wouldn't be unreasonable for the 1.x solution
to be a pragmatic "meets minimum" approach.
If these fixes/features are essential for what you need to do, and you're
unable to move to 2.x, then I think it makes sense to do a "meets minimum"
update to 1.x that would bridge the gap until you are able to move to 2.x.
Would it be possible for you to move to 2.x? If not, what are the issues
that prevent you from doing this?
Simon
Hi, Simon N.,
Thanks for the reply. I understand that 2.x is the future and I agree with
your longer term consideration. However, the application side of our
projects has been using 1.6.x for some time and from my limited experience
with 2.0, it's not backword compatible with 1.6.x due to the namespace and
API changes. From the WS-security consideration, even though I did have a
2.0 prototype, which got stuck at the policy extension using interceptor,
our effort has mainly been focussed on 1.6.x and got pretty good progress.
Adding all these plus an end-of-March delivery, it's impractical for us to
move to 2.0 in the immediate future.
So far, I have raised four issues with 1.6.x (may also apply to 2.0 with the
interceptor approach):
1. PolicyHandler.afterInvoke() needs to be called with the outbound
MessageContext instead of the inbound MC. This is critical for WS-security.
I have provided my fixes in the JIRA. With some generalization we discussed,
I think this should be fixable in 1.6.x.
2. SOAP message encryption is not supported because the
PolicyHandler.beforeInvoke() is called after Axis2 dispatching phase, which
needs to analize SOAP body in order to determine the endpoint method. This
can be worked around by defining SOAPaction in WSDL or Java interface using
@WebMethod. However, a future fix is still nice to have.
3. A state-sharing mechanism is needed to allow sharing states among service
side interceptors/handlers, component and reference side
interceptors/handlers. I'm currently using the ThreadLocal as a workaround,
which I wish to have your blessing - for now, it's only used from the
service handler to component and then to reference handler and I hope you
can confirm that the same thread is used for processing. However, we all
agreed that this is not desirable to use ThreadLocal in the service
framework and a state-sharing mechanism is needed.
4. PolicyHandler.afterInvoke is not called when Fault is generated. So far,
I have no workaround on this and would like a fix. If I remember the code
correctly, a quick fix is possible if
Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic() can catch the
exception, create the Fault body and call PolicyHandler.afterInvoke() on the
service side. I'm not sure how the client (requester) side works, but the
PolicyHandler.afterInvoke() is also skipped on the return with the Fault.
Thanks,
Gang
