I think I just meant that in order for a server-side (>=logical)
interceptor to make use of any information on the Message or
Exchange, then the representation of that data -- the data structures
used, that is -- has to be the same on the client side as it is on
the server side. I'm pretty sure I wasn't referring to JAXB, but now
I'm worried if there is a case in which different data bindings were
relevant. For example, could the CXF AuthorizationPolicy XML type
end up bound different Java type? It's a degenerate case, for sure,
and one not likely to be seen for a long while, so I'm less concerned
about that.
I think my only point was that not all information in a request
context (Message/Exchange) is symmetric on the client and server
side, and post-logical interceptors may require information in the
context that's not on the client context. So I'm just noodling about
how such an interceptor would make sense out of the limited
information it has.
One other concrete issue has occurred to me, in thinking about this
CXF AuthorizationPolicy. If you look at the documentation
annotations for the AuthorizationPolicy XML type, there is an /
implication/ that the structure is intended for use with HTTP
(witness the term "BASIC"). Perhaps the founding fathers had loftier
intentions for this type, such that it could be used for any type of
username/password authentication (JMS? CSIv2?), but let's assume the
narrow case of HTTP/BasicAuth.
Now imagine a co-located case, in which a client populates a request
context with one of these AuthorizationPolicy instances.
On Apr 12, 2007, at 3:51 PM, Glynn, Eoghan wrote:
Also, one other difference between the 2 approaches is that
the coloc case seems to require that any information
represented on a message on the outbound side has to be
represented in exactly the same way on the inbound side.
Do you mean that the data binding is the same on both sides (e.g. JAXB
with identical customizations)?
