You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Fred Dushin (JIRA)" <ji...@apache.org> on 2007/03/05 03:15:50 UTC
[jira] Created: (CXF-445) Accessing Connection-based info from the
transport
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
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.
[jira] Closed: (CXF-445) Accessing Connection-based info from the
transport
Posted by "Bozhong Lin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bozhong Lin closed CXF-445.
---------------------------
Resolution: Fixed
I verified that this patch has been applied ... please correct me if this is wrong.
> 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.
[jira] Updated: (CXF-445) Accessing Connection-based info from the
transport
Posted by "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:
----------------------------
Note that the patch file submitted 9/Mar/07 is off rev 516352.
As posted to cxf-dev:
A new patch has been uploaded. Unfortunately, Jira does not seem to allow me to remove the old one.
Most of the changes Eoghan suggested have been incorporated. In particular
* Scratched the idea of a ContextInfo type, since no one took the bait
* Added a TLSessionInfo struct (or the best Java has) to carry TLS Session data
to the org.apache.cxf.security.transport namespace (API package)
* Supported in the Jetty and servlet http transports (http and http2)
(We gotta fix that!)
* Refactored Message and Exchange interfaces (and Impls) to now extend
from a common base type -- not strictly needed, but definitely a tidy cleanup
in the API
Patch is off rev 516352.
If someone could quickly review and install the patch, I'd be much obliged.
I have no ontological commitments to the proposed changes -- mostly just the idea, so please feel free to morph the proposal to the idiom du jour (As long as I can extract the needed information out of the transport!).
Thanks!
-Fred
Here's a listing of the changes, as seen from my snapshot:
05:20:09 spock:~/src/apache/cxf/cxf-445> svn status
M rt/transports/http/src/main/java/org/apache/cxf/transport/http/JettyHTTPDestination.java
M rt/transports/http/src/main/java/org/apache/cxf/transport/servlet/ServletController.java
M rt/transports/http2/src/test/java/org/apache/cxf/transport/http/JettyHTTPDestinationTest.java
M rt/transports/http2/src/main/java/org/apache/cxf/transport/http/JettyHTTPDestination.java
M rt/transports/http2/src/main/java/org/apache/cxf/transport/servlet/ServletController.java
M api/src/main/java/org/apache/cxf/message/Exchange.java
M api/src/main/java/org/apache/cxf/message/ExchangeImpl.java
M api/src/main/java/org/apache/cxf/message/Message.java
A api/src/main/java/org/apache/cxf/message/StringMap.java
M api/src/main/java/org/apache/cxf/message/MessageImpl.java
A api/src/main/java/org/apache/cxf/message/StringMapImpl.java
A api/src/main/java/org/apache/cxf/security
A api/src/main/java/org/apache/cxf/security/transport
A api/src/main/java/org/apache/cxf/security/transport/TLSSessionInfo.java
And additionally:
One other thing -- I did not "refactor" the callout to the JettySSLListenerFactory to do this work, because there in no information in the SSL code that is needed to retrieve this information. It would make sense to have the lookup of the TLS Session information in the https namespace, but doing so introduces an artifical separation that's not really needed. Besides, there are already SSL abstractions in the http namespace, so the proposed change introduces no fundamental differences in behavior.
> 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.
[jira] Updated: (CXF-445) Accessing Connection-based info from the
transport
Posted by "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.
[jira] Updated: (CXF-445) Accessing Connection-based info from the
transport
Posted by "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
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.