Hello, Just an info: I am not using maven only Eclipse. So I just add slf4j-jdk14-1.6.4.jar in the build path of my eclipse project but again no cxf log :-( I have downloaded the src code of apache cxf 2.5.3 and have a look to the systests folder but I have only found in the systests/ws-security/src/test/resources a sample file logging.properties as a sample.
So I have tried to adapt my previous logging config file, cxf-logging.properties with the content: java.util.logging.ConsoleHandler.level = FINEST java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter org.apache.cxf.level = FINEST Again no cxf log ??? Really I need some help in order to solve my issue. Best Regards. -----Original Message----- From: Colm O hEigeartaigh [mailto:cohei...@apache.org] Sent: mardi 17 avril 2012 11:26 To: users@cxf.apache.org Subject: Re: Aware of compatibility issue between CXF and Metro/Weblogic ? 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.courta...@gemalto.com> wrote: > Hello, > > I have set in my Eclipse environment > with-Djava.util.logging.config.file=D:/Temp/ 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:cohei...@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.courta...@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.j >> k >> s >> >> org.apache.ws.security.crypto.merlin.keystore.password=myClientKeysto >> r >> 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:cohei...@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.courta...@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:cohei...@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.courta...@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.courta...@gemalto.com] >>>> Sent: mercredi 11 avril 2012 17:59 >>>> To: cohei...@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:cohei...@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#x509toke >>>> n >>>> 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.courta...@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:Signat >>>>> u >>>>> 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:DigestMeth >>>>> o >>>>> 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:DigestMeth >>>>> o >>>>> d >>>>> > >>>>> >>>>> <ds:DigestValue>YZ0E9NbYropID0uM5ZQInOgSmYA=</ds:DigestValue> >>>>> </ds:Reference> >>>>> </ds:SignedInfo> >>>>> >>>>> Best Regards. >>>>> >>>>> -----Original Message----- >>>>> From: Colm O hEigeartaigh [mailto:cohei...@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.courta...@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:KeyIde >>>>>> n >>>>>> 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:KeyIde >>>>>> n >>>>>> 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: 'cohei...@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:dk...@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:cohei...@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.courta...@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:gma...@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 >>>>>> dk...@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
