cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
Date Tue, 17 Apr 2012 09:26:27 GMT
Try adding in the following dependency:

<groupId>org.slf4j</groupId>
<artifactId>slf4j-jdk14</artifactId>

Failing that take a look at any of the STS systests in CXF to see how
logging works there.

Colm.

On Mon, Apr 16, 2012 at 5:41 PM, COURTAULT Francois
<Francois.COURTAULT@gemalto.com> wrote:
> Hello,
>
> I have set in my Eclipse environment with-Djava.util.logging.config.file=D:/Temp/cxf-logging.properties
in the VM arguments.
>
> Where in the cxf-logging.properties I have:
>        .level= FINEST
>        java.util.logging.ConsoleHandler.level = FINEST
>
> But it doesn't help a lot :-( No cxf dedicated logs appear :-(
>
> Best Regards.
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: lundi 16 avril 2012 18:24
> To: COURTAULT Francois
> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>
> The best way to find out what's going on is to turn logging up to FINEST, and see whether
it's a problem with trust verification, or digest comparison.
>
> Colm.
>
> On Mon, Apr 16, 2012 at 4:35 PM, COURTAULT Francois <Francois.COURTAULT@gemalto.com>
wrote:
>> Hello,
>>
>> I have modified the policy at the server side in order to add a signed
>> part (body) in the response. If I dump the exchanges, the good news is
>> that now I got no error from the server but I got one at the client
>> side: seems that the signature coming from the server was invalid :-(
>>
>> My code looks like:
>>                        Map<String, Object> ctx = ((BindingProvider)
>> port).getRequestContext();
>>                        ctx.put("ws-security.username",
>> "myClientKeystoreAlias");
>>                        ctx.put("ws-security.callback-handler",
>> ClientX509CB.class.getName());
>>                        ctx.put("ws-security.signature.properties",
>> "clientKeystore.properties");
>>
>> where clientKeystore.properties contains:
>>
>> org.apache.ws.security.crypto.merlin.keystore.file=myClientKeystore.jk
>> s
>>
>> org.apache.ws.security.crypto.merlin.keystore.password=myClientKeystor
>> ePassword
>>        org.apache.ws.security.crypto.merlin.keystore.type=jks
>>        org.apache.ws.security.crypto.merlin.keystore.alias=
>> myClientKeystoreAlias
>>
>> So the clientKeystore is used for signing the SOAP request sent to the server but
how can the client verify the server signature ? What can I do ? What information is missing
?
>>
>> Best Regards.
>>
>> -----Original Message-----
>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> Sent: vendredi 13 avril 2012 15:01
>> To: COURTAULT Francois
>> Cc: users@cxf.apache.org
>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>
>>>    - *if* message level signature is used in the request: how do you know that
message level signature is required ?
>>
>> By the use of a SignedParts or SignedElements policy.
>>
>>> More generally, in the ws-securitypolicy-1.3-spec-os.pdf document there no real
explanation about the meaning of OnlySignEntireHeadersAndBody. So my own interpretation, for
this one, is that:
>>>         - a signature is required for each header blocks and for the body:
no need to say more.
>>
>> That's not my interpretation of the spec. As I said previously, my reading is that
a signature can't be on a Body or Header child element if it exists. I agree that the spec
isn't exactly clear though. What's the problem with just including a SignedParts policy?
>>
>> Colm.
>>
>> On Fri, Apr 13, 2012 at 1:55 PM, COURTAULT Francois <Francois.COURTAULT@gemalto.com>
wrote:
>>> Hello,
>>>
>>> Thanks for your answer.
>>> But I still have one question:
>>>    - *if* message level signature is used in the request: how do you know that
message level signature is required ? I was expecting that this is the purpose of the policy
you attach to a webservice endpoint and, in my case, OnlySignEntireHeadersAndBody policy means
that signature is required at message level.
>>>
>>> More generally, in the ws-securitypolicy-1.3-spec-os.pdf document there no real
explanation about the meaning of OnlySignEntireHeadersAndBody. So my own interpretation, for
this one, is that:
>>>         - a signature is required for each header blocks and for the body:
no need to say more.
>>>
>>> So, just for me to know: where did you find such information with more details
regarding OnlySignEntireHeadersAndBody ?
>>>
>>> Best Regards.
>>>
>>> -----Original Message-----
>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>> Sent: vendredi 13 avril 2012 12:02
>>> To: COURTAULT Francois
>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ?
>>>
>>> Hi Francois,
>>>
>>> My reading of the spec is that a "OnlySignEntireHeadersAndBody" policy means
that *if* message level signature is used in the request, then it must not be a child element
of the SOAP Body, or a child element of a particular header, excepting the security header.
It does not mandate that signature must be performed, only that if signature is performed
it must conform to that policy. Therefore, a SignedParts or SignedElements policy is needed
to specify what must actually be signed.
>>>
>>> Colm.
>>>
>>>
>>> On Thu, Apr 12, 2012 at 11:32 AM, COURTAULT Francois <Francois.COURTAULT@gemalto.com>
wrote:
>>>> Hello,
>>>>
>>>> I have looked at the security policy spec (1.3) and it seems that SignedParts
is OPTIONAL: right ?
>>>> However this spec is not clear at all regarding the relationship
>>>> between the <sp:OnlySignEntireHeadersAndBody/> directive and the <sp:SignedParts/>
directive :-( Does the presence of the  <sp:OnlySignEntireHeadersAndBody/> directive
requires the <sp:SignedParts/> directive ?
>>>>
>>>> Any spec or document which can provide more clear explanation about the relationship
between these 2 above directives ?
>>>> So let's suppose that the <sp:OnlySignEntireHeadersAndBody/> could
be used alone, in such case does it mean that all the security headers and the body have to
be signed ?
>>>>
>>>> Best Regards.
>>>>
>>>> -----Original Message-----
>>>> From: COURTAULT Francois [mailto:Francois.COURTAULT@gemalto.com]
>>>> Sent: mercredi 11 avril 2012 17:59
>>>> To: coheigea@apache.org
>>>> Cc: users@cxf.apache.org
>>>> Subject: RE: Aware of compatibility issue between CXF and Metro/Weblogic
?
>>>> Importance: High
>>>>
>>>> Hello,
>>>>
>>>> Regarding your last question: Is there such a policy in your WSDL?
>>>> I have looked at the policy used (attached) and I only see <sp:OnlySignEntireHeadersAndBody/>
with no SignedParts.
>>>> So my question is: with the policy used(attached), is it required or not
to sign the body ?
>>>>
>>>> A corollary question is, with only the <sp:OnlySignEntireHeadersAndBody/>
directive in the policy, the webservice endpoint has to accept only SOAP request with at least
a body signature ?
>>>>
>>>> Best Regards.
>>>>
>>>> -----Original Message-----
>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>> Sent: mercredi 11 avril 2012 17:21
>>>> To: COURTAULT Francois
>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic
?
>>>>
>>>> Hi Francois,
>>>>
>>>>>        - first, for them, in the <dsig:KeyInfo> section, they
refer
>>>>> the wsse11 namespace which is used in
>>>>> wsse11:TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3".
Is this TokenType mandatory ?
>>>>
>>>> Not according to my reading of the Basic Security Profile 1.1:
>>>>
>>>> http://www.ws-i.org/profiles/basicsecurityprofile-1.1.html#x509token
>>>> t
>>>> y
>>>> pes
>>>>
>>>> They give the example:
>>>>
>>>> CORRECT:
>>>>
>>>>          <wsse:SecurityTokenReference>
>>>>          <wsse:KeyIdentifier
>>>> EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
>>>>          ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier"
>>>>>
>>>>          MIGfMa0GCSq
>>>>          </wsse:KeyIdentifier>
>>>>          </wsse:SecurityTokenReference>
>>>>
>>>>>  - second, in the <ds:SignedInfo> section, the body signature
seems missing in the CXF SOAP request. Is it normal ?
>>>>
>>>> CXF will only sign the SOAP Body if there is a SignedParts policy that specifies
the SOAP Body. Is there such a policy in your WSDL?
>>>>
>>>> Colm.
>>>>
>>>>
>>>> On Wed, Apr 11, 2012 at 3:56 PM, COURTAULT Francois <Francois.COURTAULT@gemalto.com>
wrote:
>>>>> Hello again,
>>>>>
>>>>> I have forwarded your answer to the Oracle support. They replied me 2
things:
>>>>>        - first, for them, in the <dsig:KeyInfo> section, they
refer the wsse11 namespace which is used in wsse11:TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3".
Is this TokenType mandatory ?
>>>>>
>>>>>        - second, in the <ds:SignedInfo> section, the body signature
seems missing in the CXF SOAP request. Is it normal ?
>>>>>             * In Weblogic request:
>>>>>                                <dsig:SignedInfo>
>>>>>                                        <dsig:CanonicalizationMethod
>>>>>
>>>>> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
>>>>>                                        <dsig:SignatureMethod
>>>>> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
>>>>>                                        <dsig:Reference
>>>>> URI="#Timestamp_WF911A291H4C9EVH">
>>>>>                                              
 <dsig:Transforms>
>>>>>
>>>>> <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
>>>>> />
>>>>>                                              
 </dsig:Transforms>
>>>>>                                              
 <dsig:DigestMethod
>>>>> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
>>>>>
>>>>> <dsig:DigestValue>FQdxW5uhQYvIlEjZ5eF6FwD0WWM=</dsig:DigestValue>
>>>>>                                        </dsig:Reference>
>>>>>                                        <dsig:Reference
>>>>> URI="#Body_6e1VPrhuvqnQBAe6">
>>>>>                                              
 <dsig:Transforms>
>>>>>
>>>>> <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
>>>>> />
>>>>>                                              
 </dsig:Transforms>
>>>>>                                              
 <dsig:DigestMethod
>>>>> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
>>>>>
>>>>> <dsig:DigestValue>hqQ8dypeB6mi9otTZftZ9wdaIpQ=</dsig:DigestValue>
>>>>>                                        </dsig:Reference>
>>>>>                                        <dsig:Reference
>>>>> URI="#bst_156mJ1UUoTA9ZP7b">
>>>>>                                              
 <dsig:Transforms>
>>>>>
>>>>> <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
>>>>> />
>>>>>                                              
 </dsig:Transforms>
>>>>>                                              
 <dsig:DigestMethod
>>>>> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
>>>>>
>>>>> <dsig:DigestValue>dmD/DqmQIf+LrHjcOgxLKhpCvZE=</dsig:DigestValue>
>>>>>                                        </dsig:Reference>
>>>>>                                </dsig:SignedInfo>
>>>>>
>>>>>             * In CXF request:
>>>>>                                <ds:SignedInfo>
>>>>>                                        <ds:CanonicalizationMethod
>>>>>
>>>>> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
>>>>>                                              
 <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
>>>>>
>>>>> PrefixList="soap"></ec:InclusiveNamespaces>
>>>>>                                        </ds:CanonicalizationMethod>
>>>>>                                        <ds:SignatureMethod
>>>>> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></ds:Signatu
>>>>> r
>>>>> e
>>>>> M
>>>>> ethod>
>>>>>                                        <ds:Reference
URI="#TS-1">
>>>>>                                              
 <ds:Transforms>
>>>>>
>>>>> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
>>>>>
>>>>> <ec:InclusiveNamespaces
>>>>>
>>>>> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="wsse
>>>>> soap"></ec:InclusiveNamespaces>
>>>>>
>>>>> </ds:Transform>
>>>>>                                              
 </ds:Transforms>
>>>>>                                              
 <ds:DigestMethod
>>>>> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMetho
>>>>> d
>>>>> >
>>>>>
>>>>> <ds:DigestValue>qqnMVp6ogLp4FbJuMaenBdYlm3E=</ds:DigestValue>
>>>>>                                        </ds:Reference>
>>>>>                                        <ds:Reference
>>>>> URI="#X509-A8BAAB773C57F7C94113313097001254">
>>>>>                                              
 <ds:Transforms>
>>>>>
>>>>> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
>>>>>
>>>>> <ec:InclusiveNamespaces
>>>>>
>>>>> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
>>>>> PrefixList="soap"></ec:InclusiveNamespaces>
>>>>>
>>>>> </ds:Transform>
>>>>>                                              
 </ds:Transforms>
>>>>>                                              
 <ds:DigestMethod
>>>>> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMetho
>>>>> d
>>>>> >
>>>>>
>>>>> <ds:DigestValue>YZ0E9NbYropID0uM5ZQInOgSmYA=</ds:DigestValue>
>>>>>                                        </ds:Reference>
>>>>>                                </ds:SignedInfo>
>>>>>
>>>>> Best Regards.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>>> Sent: mardi 10 avril 2012 17:18
>>>>> To: COURTAULT Francois
>>>>> Cc: users@cxf.apache.org
>>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic
?
>>>>>
>>>>>> So according to them, the following namespaces are missing in the
CXF request:
>>>>>>          -  wsu
>>>>>>          -  wsse
>>>>>
>>>>> This is incorrect as both of these namespaces are defined in the security
header element.
>>>>>
>>>>> Colm.
>>>>>
>>>>> On Tue, Apr 10, 2012 at 3:38 PM, COURTAULT Francois <Francois.COURTAULT@gemalto.com>
wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Just to inform you I have also entered an issue in MOS (My Oracle
Support).
>>>>>>
>>>>>> The answer they gave me was that,
>>>>>> In the Weblogic client request I  had:
>>>>>>
>>>>>>                                <dsig:KeyInfo>
>>>>>>
>>>>>> <wsse:SecurityTokenReference
>>>>>>                                            
   xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
>>>>>>                                            
   xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
>>>>>>                                            
   xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
>>>>>>                                            
   wsse11:TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
>>>>>>
>>>>>> wsu:Id="str_4RaFdeoK8oynP98t">
>>>>>>                                            
   <wsse:KeyIdentifier
>>>>>>                                            
           EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
>>>>>>
>>>>>> ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-s
>>>>>> e
>>>>>> c
>>>>>> u
>>>>>> r
>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIden
>>>>>> t
>>>>>> i
>>>>>> f
>>>>>> i
>>>>>> er>
>>>>>>
>>>>>> </wsse:SecurityTokenReference>
>>>>>>                                </dsig:KeyInfo>
>>>>>>
>>>>>> Whereas, in the CXF client (CXF 2.5.3 SNAPSHOT), I had:
>>>>>>
>>>>>>                                <ds:KeyInfo
>>>>>> Id="KI-A8BAAB773C57F7C94113313097001252">
>>>>>>
>>>>>> <wsse:SecurityTokenReference
>>>>>> wsu:Id="STR-A8BAAB773C57F7C94113313097001253">
>>>>>>                                            
   <wsse:KeyIdentifier
>>>>>>                                            
           EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
>>>>>>
>>>>>> ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-s
>>>>>> e
>>>>>> c
>>>>>> u
>>>>>> r
>>>>>> ity-1.1#ThumbprintSHA1">tDqtOB05FR2Q/BUdXx1X8rzDXMg=</wsse:KeyIden
>>>>>> t
>>>>>> i
>>>>>> f
>>>>>> i
>>>>>> er>
>>>>>>
>>>>>> </wsse:SecurityTokenReference>
>>>>>>                                </ds:KeyInfo>
>>>>>>
>>>>>> So according to them, the following namespaces are missing in the
CXF request:
>>>>>>          -  wsu
>>>>>>          -  wsse
>>>>>>
>>>>>> Do you agree ? If yes can we have a fix for that please ?
>>>>>>
>>>>>> Best Regards.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: COURTAULT Francois
>>>>>> Sent: vendredi 9 mars 2012 17:36
>>>>>> To: 'coheigea@apache.org'
>>>>>> Cc: users@cxf.apache.org
>>>>>> Subject: RE: Aware of compatibility issue between CXF and Metro/Weblogic
?
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I have picked up the 2.5.3-20120309.061736-28 snapshot.
>>>>>> In the SOAP request I saw now, in the SOAP request, the <wsse:KeyIdentifier>
section in the <dsig:KeyInfo> <wsse:SecurityTokenReference> section :-) (thanks
for this fix) but I still have a SOAP fault in the response coming from Weblogic :-(.
>>>>>>
>>>>>> Do you have an idea as I haven't so much information (log) on the
Weblogic side ?
>>>>>>
>>>>>> Best Regards.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Daniel Kulp [mailto:dkulp@apache.org]
>>>>>> Sent: mercredi 7 mars 2012 19:38
>>>>>> To: users@cxf.apache.org
>>>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic
?
>>>>>>
>>>>>> On Tuesday, March 06, 2012 06:52:41 PM COURTAULT Francois wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Thanks for the feedback :-)
>>>>>>> According to the issue, it should be fixed in the 2.5.3 release:
right ?
>>>>>>> When this version will be released ?
>>>>>>
>>>>>> Likely in a couple weeks.   We did a release on Jan 25th and we
>>>>>> normally shoot for about every 8 weeks or so.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Best Regards.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>>>>> Sent: mardi 6 mars 2012 18:36
>>>>>>> To: users@cxf.apache.org
>>>>>>> Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic
?
>>>>>>>
>>>>>>> It's an issue in CXF:
>>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/CXF-4166
>>>>>>>
>>>>>>> I'll merge a fix shortly.
>>>>>>>
>>>>>>> Colm.
>>>>>>>
>>>>>>> On Tue, Mar 6, 2012 at 3:13 PM, COURTAULT Francois
>>>>>> <Francois.COURTAULT@gemalto.com> wrote:
>>>>>>> > Hello Glen,
>>>>>>> >
>>>>>>> > The two issues (WSIT-1490 and WSIT-1590) you mention seem
not
>>>>>>> > related to the issue I have got :-( I am not using STS (WS-Trust)
at all:
>>>>>>> >        -  WSIT-1490: no SAML used in the KeyIdentifier
with a
>>>>>>> > #uuid in the SOAP request. -  WSIT-1590: no encoded email
in the SOAP request.
>>>>>>> >
>>>>>>> > Best Regards.
>>>>>>> >
>>>>>>> > -----Original Message-----
>>>>>>> > From: Glen Mazza [mailto:gmazza@talend.com]
>>>>>>> > Sent: mardi 6 mars 2012 15:20
>>>>>>> > To: users@cxf.apache.org
>>>>>>> > Subject: Re: Aware of compatibility issue between CXF and
>>>>>>> > Metro/Weblogic ?
>>>>>>> >
>>>>>>> > There's a couple of problems that seem to be on Metro's
side
>>>>>>> > (http://java.net/jira/browse/WSIT-1490,
>>>>>>> > http://java.net/jira/browse/WSIT-1590) affecting
>>>>>>> > interoperability between the two stacks.  It would be great
if
>>>>>>> > these were fixed, as both Metro and CXF are better off the
more
>>>>>>> > interoperable they are with each other.  Feel free to vote
for
>>>>>>> > these two issues.  :)
>>>>>>> >
>>>>>>> > Glen
>>>>>>> >
>>>>>>> > On 03/06/2012 07:03 AM, COURTAULT Francois wrote:
>>>>>>> >> Hello,
>>>>>>> >>
>>>>>>> >> I have tried to write a CXF client which talks to a
WSS
>>>>>>> >> protected
>>>>>>> >> (X509Token)  webservice hosted in Weblogic (Metro based)
but
>>>>>>> >> unfortunately I got a Soap fault error.
>>>>>>> >>
>>>>>>> >> If I compare a soap request which works and the one
generated
>>>>>>> >> by CXF, the only difference I have seen is that in
>>>>>>> >> the<dsig:KeyInfo> <wsse:SecurityTokenReference>
 section, I
>>>>>>> >> have a<wsse:KeyIdentifier>  section in the one
which succeeded
>>>>>>> >> whereas I haven't this section in the CXF one.
>>>>>>> >>
>>>>>>> >> Any advice ? Any idea ?
>>>>>>> >>
>>>>>>> >> Best Regards.
>>>>>>> >
>>>>>>> > --
>>>>>>> > Glen Mazza
>>>>>>> > Talend Community Coders - coders.talend.com
>>>>>>> > blog: www.jroller.com/gmazza
>>>>>>>
>>>>>>> --
>>>>>>> Colm O hEigeartaigh
>>>>>>>
>>>>>>> Talend Community Coder
>>>>>>> http://coders.talend.com
>>>>>> --
>>>>>> Daniel Kulp
>>>>>> dkulp@apache.org - http://dankulp.com/blog Talend Community Coder
>>>>>> - http://coders.talend.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Colm O hEigeartaigh
>>>>>
>>>>> Talend Community Coder
>>>>> http://coders.talend.com
>>>>
>>>>
>>>>
>>>> --
>>>> Colm O hEigeartaigh
>>>>
>>>> Talend Community Coder
>>>> http://coders.talend.com
>>>
>>>
>>>
>>> --
>>> Colm O hEigeartaigh
>>>
>>> Talend Community Coder
>>> http://coders.talend.com
>>
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Mime
View raw message