> -----Original Message----- > From: Fred Dushin [mailto:[EMAIL PROTECTED] > Sent: 13 April 2007 14:43 > To: [EMAIL PROTECTED] > Subject: Re: [PROPOSAL] Unification of coloc and object bindings > > > 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.
Yep, that's exactly what I was talking about re. the data binding being identical on both sides. The data binding determines the types of the raw Java objects representing the parameters of the invocation. JAXB is just one example of a data binding supported by CXF. So it would be possible for say the client logic to be using JAXB and the server logic to be using Aegis, or maybe both side using JAXB but with different customizations. But I think in practice, this won't be common. > 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. Yep, agreed this case is unusual, and the coloc binding will transparently revert to a full dispatch (mediated via the real binding) when the data bindings don't match. > 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. I guess that logic would be engaged in a coloc dispatch if the AuthorizationPolicy was fully populated in the logical phase on the client-side, and the server-side interceptor that checks the username/pass also operates in the logical phase by checking the (same) AuthorizationPolicy instance. Though obviously since the forthcoming HttpBasicAuthUserPassSupplier is only triggered from the HTTPConduit, and I guess the 401-sending on the server-side is also done in a "close-to-the-wire" interceptor, then we obviously wouldn't have full basic auth going on. Which is fine I think, where we implicitly trust collocated code. For users who don't, then the solution is clear, just fall back to a full dispatch over HTTPS. /Eoghan > 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)? > >
