[jira] Updated: (CXF-445) Accessing Connection-based info from the transport

["Fred Dushin (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CXF-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fred Dushin updated CXF-445:
----------------------------

    Attachment: CXF-445.patch

patch file generated via svn diff from trunk of revision 514527

> Accessing Connection-based info from the transport
> --------------------------------------------------
>
>                 Key: CXF-445
>                 URL: https://issues.apache.org/jira/browse/CXF-445
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0-RC
>            Reporter: Fred Dushin
>             Fix For: 2.0-RC
>
>         Attachments: CXF-445.patch
>
>
> Original post to cxf-dev mailinglist.  Patch to follow:
> I'd like to get access to some connection-based information from the transport -- in particular, properties relating to any security context established at the transport (e.g., via an SSL handshake, or via a GSS-Accept) --
> Primarily I'm thinking about the server-side of an invocation, though I suspect there may be client-side requirements, as well, though at present they are not as pressing for me.  (They may be later).
> In any event, I've found that the transport is not populating the Message with any of the information I need, so I'd like to propose what I think should be a simple solution.
> First, I understand the fact that there are potentially many different transport implementations, even perhaps for the same protocols.  So in some cases, this information may not be accessible by the transport, which is unfortunate (and perhaps motivation for not using the transport all together, depending on the business requirements).  So the solution should allow for the possibility that some transports can't provide the needed info, so that consumers of the information can code defensively in these situations (throw an exception, log a warning, whatever).
> I can see how the transport destination implementations are instantiating the Message structures, which in turn get passed to the various interceptors (again, talking about the server-side here).  So I'd like the transports, as the divine creators of Messages, to populate said messages with the contextual information I need.  The question then becomes, what should this information look like, and how should it be keyed on the Message?
> We have several alternatives, which I'd like suggestions on before submitting a patch.
> First, I assume for purely organizational purposes we don't want a *huge* collection of tags on the Message.  Not that it matters much (the Message is currently implemented as a HashMap, so adding a lot of data should not have an impact on lookup), but perhaps for purely aestheic reasons, it would be better to aggregate this information in some comprehensible manner.
> Going on that assumption, we have some options.  We could define a type or collection thereof, each of which has a collection of accessors (and mutators, for the benefit of our transports), which define which data is available, where the types stowed on these structs are common, well-known, and guaranteed likely-to-exist types, e.g.,
> class/interface TLSTransportInfo {
>     java.security.cert.Certificate[] getPeerCertificateChain() ...
> }
> I started to do this, but the LISP programmer in me said "there has to be a better way".  (I have an innate repulsion to vacuous code, but I'm old-fashioned that way :)  So I turned to our good friend java.util.Map for inspiration (who needs types when you have a cons!).  Why not define leverage a Map<String, Object>, and define a contract for what the structure of the map needs to be -- what tags are associated which what values, which entries are required, vs which are optional.  Hey, they might even be able to be recursive structures, if that's not too difficult for consumers to manage.  The idea is that the data contract is all documented somewhere, so the producers and consumers of the information just need to consult the docs for the expected behavior.
> This has the advantage that we don't have to hand-write all these structs, which are nothing but a collection of accessors and mutators, results in fewer types, and in general just seems a lot cleaner to me.  (I suppose if we could *codegen* these structs, then that would be an advantage, but I'm not sure if you can codegene structs from schema, where the objects stored on the structs are native Java objects.)
> I realize that the Message type is a lot like this (it implements Map<String, Object>), but the semantics of "Message" are probably not appropriate for this use.  Perhaps this new type could be a base-type for Message, so that it has better visibility/use in CF as a whole.  Then a Message would extend this type, which it may also contain.  Nothing like confusing our users! :)
> Anyway, do folks see this as a potentially valuable addition to CXF?  Either way, I need the information from the transport.  I think it just boils down to how we want that information to be represented.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.