cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fred Dushin (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CXF-445) Accessing Connection-based info from the transport
Date Fri, 09 Mar 2007 10:28:24 GMT

     [ 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

Corrected version, with Eoghan's comments incorporated

> 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, 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.


Mime
View raw message