You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Mark Streit <mc...@gmail.com> on 2012/10/28 01:24:36 UTC
question re: JAX-WS SOAP Handlers (alternative to Interceptors)
Hello
Wondering if anyone has seen this ... As I am still hunting down on my own.
I recently started using the latest CXF 2.7.0 release with a standalone
java client program we have been doing some simple POC work with. I
created an entire new project (simple Java client) and included the CXF
2.7.0 JARs (except the jetty stuff and geronimo stuff) in the classpath of
the IDE project (I double checked the .classpath file manually)....
I am running this using plain Eclipse Indigo and DO NOT RELY on any JARs
provided by the IDE specifying explicitly all of the JARs to be used by the
java app configuration. This was working before with 2.6.x.
It all works fine until I attempt to use SOAP Headers using ONLY standard
jaxws handlers and NOT CXF interceptors. When I run the client ... I see
the following stacktrace which raises 2 questions...
1) why the IBM class for SAAJ is showing up is suspicious and
2) some Xerces related class can't be found but there is no Xerces related
JAR that I can find in the 2.7.0 distribution.
I am guessing that something in my environment is fouled up. The
IBM-specific class is obviously wrong...I assume?. I am using this all
with Sun/Oracle JDK 1.6.0-34 and no IBM jars.
I must have missed something. Still looking.
Fwiw... The CXF interceptor related classes in the trace are NOT explicitly
used in my code but are showing up as a result of using only the java
standard jaxws API .
Exception in thread "main"* java.lang.NoClassDefFoundError:
org/apache/xerces/dom/AttrImpl*
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at
com.ibm.ws.webservices.engine.soap.MessageFactoryImpl.<init>(MessageFactoryImpl.java:116)
at
com.ibm.ws.webservices.engine.soap.SAAJMetaFactoryImpl.newMessageFactory(SAAJMetaFactoryImpl.java:56)
at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:148)
at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:114)
at
org.apache.cxf.binding.soap.saaj.SAAJFactoryResolver.createMessageFactory(SAAJFactoryResolver.java:56)
at
org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor.getFactory(SAAJOutInterceptor.java:86)
at
org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor.handleMessage(SAAJOutInterceptor.java:122)
at
org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.handleMessage(SOAPHandlerInterceptor.java:120)
at
org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.handleMessage(SOAPHandlerInterceptor.java:71)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:531)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:464)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:367)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:320)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:89)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:134)
at $Proxy30.getBook(Unknown Source)
at
com.acme.book.client.ws.CXFBookOrderManagerClient.main(CXFBookOrderManagerClient.java:116)
Thanks
Mark
Re: question re: JAX-WS SOAP Handlers (alternative to Interceptors)
Posted by Mark Streit <mc...@gmail.com>.
Thanks. I was going to try that next....as I have, on numerous occasions,
referred people to your web services tutorials.
In fact I was looking at the one you have on SOAP handlers vs CXF
interceptors. Will try the maven thing outside the IDE with your project
and look at the .classpath file with Navigator to see what diffs I can find.
Appreciate the quick response.
Mark
On Oct 27, 2012 8:21 PM, "Glen Mazza" <gm...@talend.com> wrote:
> Are you running a Mavenized project so you can run it out of Eclipse to
> rule out CXF being the problem? If yes, did you import the project into
> Eclipse using mvn eclipse:eclipse? (http://www.jroller.com/**
> gmazza/entry/web_service_**tutorial#EclipseSetup<http://www.jroller.com/gmazza/entry/web_service_tutorial#EclipseSetup><
> http://www.jroller.com/**gmazza/entry/web_service_**tutorial#EclipseSetup<http://www.jroller.com/gmazza/entry/web_service_tutorial#EclipseSetup>>).
> If yes again, you can see the libraries CXF is using via looking at the
> Eclipse .classpath file in the Navigator.
>
> You can also download my soap handler tutorial (
> http://www.jroller.com/gmazza/**entry/jaxws_handler_tutorial<http://www.jroller.com/gmazza/entry/jaxws_handler_tutorial>),
> mvn eclipse:eclipse it into your IDE, and check the .classpath file to see
> if there's any difference between my tuturial and your code in the JARs
> being used.
>
> HTH,
> Glen
>
> On 10/27/2012 07:24 PM, Mark Streit wrote:
>
>> Hello
>>
>> Wondering if anyone has seen this ... As I am still hunting down on my
>> own.
>>
>> I recently started using the latest CXF 2.7.0 release with a standalone
>> java client program we have been doing some simple POC work with. I
>> created an entire new project (simple Java client) and included the CXF
>> 2.7.0 JARs (except the jetty stuff and geronimo stuff) in the classpath of
>> the IDE project (I double checked the .classpath file manually)....
>>
>> I am running this using plain Eclipse Indigo and DO NOT RELY on any JARs
>> provided by the IDE specifying explicitly all of the JARs to be used by
>> the
>> java app configuration. This was working before with 2.6.x.
>>
>> It all works fine until I attempt to use SOAP Headers using ONLY standard
>> jaxws handlers and NOT CXF interceptors. When I run the client ... I see
>> the following stacktrace which raises 2 questions...
>>
>> 1) why the IBM class for SAAJ is showing up is suspicious and
>> 2) some Xerces related class can't be found but there is no Xerces related
>> JAR that I can find in the 2.7.0 distribution.
>>
>> I am guessing that something in my environment is fouled up. The
>> IBM-specific class is obviously wrong...I assume?. I am using this all
>> with Sun/Oracle JDK 1.6.0-34 and no IBM jars.
>>
>> I must have missed something. Still looking.
>>
>> Fwiw... The CXF interceptor related classes in the trace are NOT
>> explicitly
>> used in my code but are showing up as a result of using only the java
>> standard jaxws API .
>>
>> Exception in thread "main"* java.lang.**NoClassDefFoundError:
>> org/apache/xerces/dom/**AttrImpl*
>>
>> at java.lang.ClassLoader.**defineClass1(Native Method)
>>
>> at java.lang.ClassLoader.**defineClassCond(ClassLoader.**java:631)
>>
>> at java.lang.ClassLoader.**defineClass(ClassLoader.java:**615)
>>
>> at java.security.**SecureClassLoader.defineClass(**
>> SecureClassLoader.java:141)
>>
>> at java.net.URLClassLoader.**defineClass(URLClassLoader.**java:283)
>>
>> at java.net.URLClassLoader.**access$000(URLClassLoader.**java:58)
>>
>> at java.net.URLClassLoader$1.run(**URLClassLoader.java:197)
>>
>> at java.security.**AccessController.doPrivileged(**Native Method)
>>
>> at java.net.URLClassLoader.**findClass(URLClassLoader.java:**190)
>>
>> at java.lang.ClassLoader.**loadClass(ClassLoader.java:**306)
>>
>> at sun.misc.Launcher$**AppClassLoader.loadClass(**Launcher.java:301)
>>
>> at java.lang.ClassLoader.**loadClass(ClassLoader.java:**247)
>>
>> at
>> com.ibm.ws.webservices.engine.**soap.MessageFactoryImpl.<init>**
>> (MessageFactoryImpl.java:116)
>>
>> at
>> com.ibm.ws.webservices.engine.**soap.SAAJMetaFactoryImpl.**
>> newMessageFactory(**SAAJMetaFactoryImpl.java:56)
>>
>> at javax.xml.soap.MessageFactory.**newInstance(MessageFactory.**java:148)
>>
>> at javax.xml.soap.MessageFactory.**newInstance(MessageFactory.**java:114)
>>
>> at
>> org.apache.cxf.binding.soap.**saaj.SAAJFactoryResolver.**
>> createMessageFactory(**SAAJFactoryResolver.java:56)
>>
>> at
>> org.apache.cxf.binding.soap.**saaj.SAAJOutInterceptor.**
>> getFactory(SAAJOutInterceptor.**java:86)
>>
>> at
>> org.apache.cxf.binding.soap.**saaj.SAAJOutInterceptor.**handleMessage(**
>> SAAJOutInterceptor.java:122)
>>
>> at
>> org.apache.cxf.jaxws.handler.**soap.SOAPHandlerInterceptor.**
>> handleMessage(**SOAPHandlerInterceptor.java:**120)
>>
>> at
>> org.apache.cxf.jaxws.handler.**soap.SOAPHandlerInterceptor.**
>> handleMessage(**SOAPHandlerInterceptor.java:**71)
>>
>> at
>> org.apache.cxf.phase.**PhaseInterceptorChain.**doIntercept(**
>> PhaseInterceptorChain.java:**271)
>>
>> at org.apache.cxf.endpoint.**ClientImpl.doInvoke(**ClientImpl.java:531)
>>
>> at org.apache.cxf.endpoint.**ClientImpl.invoke(ClientImpl.**java:464)
>>
>> at org.apache.cxf.endpoint.**ClientImpl.invoke(ClientImpl.**java:367)
>>
>> at org.apache.cxf.endpoint.**ClientImpl.invoke(ClientImpl.**java:320)
>>
>> at org.apache.cxf.frontend.**ClientProxy.invokeSync(**
>> ClientProxy.java:89)
>>
>> at org.apache.cxf.jaxws.**JaxWsClientProxy.invoke(**
>> JaxWsClientProxy.java:134)
>>
>> at $Proxy30.getBook(Unknown Source)
>>
>> at
>> com.acme.book.client.ws.**CXFBookOrderManagerClient.**main(**
>> CXFBookOrderManagerClient.**java:116)
>>
>>
>> Thanks
>>
>> Mark
>>
>>
>
> --
> Glen Mazza
> Talend Community Coders - coders.talend.com
> blog: www.jroller.com/gmazza
>
>
Re: question re: JAX-WS SOAP Handlers (alternative to Interceptors)
Posted by Mark Streit <mc...@gmail.com>.
Thanks for the suggestion. I did precisely what you listed and did find
ONE major difference. Your .classpath as created with mvn eclipse:ecclipse
did reveal something --- the presence of
geronimo-javamail_1.4_spec-1.7.1.jar HOWEVER,
I also later did find that the client app I have in the IDE also had a
source project dependency on another "utility" project (Java project that
compiles to a JAR) which itself had a reference a few older IBM libraries
(Websphere 7 related). Upon discovering that, I removed those errant JARs
from the path and added the same geronimo-javamail_1.4_spec-1.7.1.jar that
yours had. IT WORKED without getting the interference from the obvious
older IBM stuff. Then I tried something... I went back and removed
that geronimo-javamail_1.4_spec-1.7.1.jar and re-ran it... and it STILL
WORKED. I suspect that the older JARs which were left over from some other
work were interfering and such older classes were shoved into the
classloader causing the problem.
In the end, I got it working. As always, your tutorials and articles are
extremely helpful. I am a bit puzzled over whether this "javamail" related
JAR is really required. (the project I used from your site to do this was
the soap_client_tutorial).
Thanks again for your input.
Mark
On Sat, Oct 27, 2012 at 8:20 PM, Glen Mazza <gm...@talend.com> wrote:
> Are you running a Mavenized project so you can run it out of Eclipse to
> rule out CXF being the problem? If yes, did you import the project into
> Eclipse using mvn eclipse:eclipse? (http://www.jroller.com/**
> gmazza/entry/web_service_**tutorial#EclipseSetup<http://www.jroller.com/gmazza/entry/web_service_tutorial#EclipseSetup><
> http://www.jroller.com/**gmazza/entry/web_service_**tutorial#EclipseSetup<http://www.jroller.com/gmazza/entry/web_service_tutorial#EclipseSetup>>).
> If yes again, you can see the libraries CXF is using via looking at the
> Eclipse .classpath file in the Navigator.
>
> You can also download my soap handler tutorial (
> http://www.jroller.com/gmazza/**entry/jaxws_handler_tutorial<http://www.jroller.com/gmazza/entry/jaxws_handler_tutorial>),
> mvn eclipse:eclipse it into your IDE, and check the .classpath file to see
> if there's any difference between my tuturial and your code in the JARs
> being used.
>
> HTH,
> Glen
>
>
> On 10/27/2012 07:24 PM, Mark Streit wrote:
>
>> Hello
>>
>> Wondering if anyone has seen this ... As I am still hunting down on my
>> own.
>>
>> I recently started using the latest CXF 2.7.0 release with a standalone
>> java client program we have been doing some simple POC work with. I
>> created an entire new project (simple Java client) and included the CXF
>> 2.7.0 JARs (except the jetty stuff and geronimo stuff) in the classpath of
>> the IDE project (I double checked the .classpath file manually)....
>>
>> I am running this using plain Eclipse Indigo and DO NOT RELY on any JARs
>> provided by the IDE specifying explicitly all of the JARs to be used by
>> the
>> java app configuration. This was working before with 2.6.x.
>>
>> It all works fine until I attempt to use SOAP Headers using ONLY standard
>> jaxws handlers and NOT CXF interceptors. When I run the client ... I see
>> the following stacktrace which raises 2 questions...
>>
>> 1) why the IBM class for SAAJ is showing up is suspicious and
>> 2) some Xerces related class can't be found but there is no Xerces related
>> JAR that I can find in the 2.7.0 distribution.
>>
>> I am guessing that something in my environment is fouled up. The
>> IBM-specific class is obviously wrong...I assume?. I am using this all
>> with Sun/Oracle JDK 1.6.0-34 and no IBM jars.
>>
>> I must have missed something. Still looking.
>>
>> Fwiw... The CXF interceptor related classes in the trace are NOT
>> explicitly
>> used in my code but are showing up as a result of using only the java
>> standard jaxws API .
>>
>> Exception in thread "main"* java.lang.**NoClassDefFoundError:
>> org/apache/xerces/dom/**AttrImpl*
>>
>>
>> at java.lang.ClassLoader.**defineClass1(Native Method)
>>
>> at java.lang.ClassLoader.**defineClassCond(ClassLoader.**java:631)
>>
>> at java.lang.ClassLoader.**defineClass(ClassLoader.java:**615)
>>
>> at java.security.**SecureClassLoader.defineClass(**
>> SecureClassLoader.java:141)
>>
>> at java.net.URLClassLoader.**defineClass(URLClassLoader.**java:283)
>>
>> at java.net.URLClassLoader.**access$000(URLClassLoader.**java:58)
>>
>> at java.net.URLClassLoader$1.run(**URLClassLoader.java:197)
>>
>> at java.security.**AccessController.doPrivileged(**Native Method)
>>
>> at java.net.URLClassLoader.**findClass(URLClassLoader.java:**190)
>>
>> at java.lang.ClassLoader.**loadClass(ClassLoader.java:**306)
>>
>> at sun.misc.Launcher$**AppClassLoader.loadClass(**Launcher.java:301)
>>
>> at java.lang.ClassLoader.**loadClass(ClassLoader.java:**247)
>>
>> at
>> com.ibm.ws.webservices.engine.**soap.MessageFactoryImpl.<init>**
>> (MessageFactoryImpl.java:116)
>>
>> at
>> com.ibm.ws.webservices.engine.**soap.SAAJMetaFactoryImpl.**
>> newMessageFactory(**SAAJMetaFactoryImpl.java:56)
>>
>> at javax.xml.soap.MessageFactory.**newInstance(MessageFactory.**java:148)
>>
>> at javax.xml.soap.MessageFactory.**newInstance(MessageFactory.**java:114)
>>
>> at
>> org.apache.cxf.binding.soap.**saaj.SAAJFactoryResolver.**
>> createMessageFactory(**SAAJFactoryResolver.java:56)
>>
>> at
>> org.apache.cxf.binding.soap.**saaj.SAAJOutInterceptor.**
>> getFactory(SAAJOutInterceptor.**java:86)
>>
>> at
>> org.apache.cxf.binding.soap.**saaj.SAAJOutInterceptor.**handleMessage(**
>> SAAJOutInterceptor.java:122)
>>
>> at
>> org.apache.cxf.jaxws.handler.**soap.SOAPHandlerInterceptor.**
>> handleMessage(**SOAPHandlerInterceptor.java:**120)
>>
>> at
>> org.apache.cxf.jaxws.handler.**soap.SOAPHandlerInterceptor.**
>> handleMessage(**SOAPHandlerInterceptor.java:**71)
>>
>> at
>> org.apache.cxf.phase.**PhaseInterceptorChain.**doIntercept(**
>> PhaseInterceptorChain.java:**271)
>>
>> at org.apache.cxf.endpoint.**ClientImpl.doInvoke(**ClientImpl.java:531)
>>
>> at org.apache.cxf.endpoint.**ClientImpl.invoke(ClientImpl.**java:464)
>>
>> at org.apache.cxf.endpoint.**ClientImpl.invoke(ClientImpl.**java:367)
>>
>> at org.apache.cxf.endpoint.**ClientImpl.invoke(ClientImpl.**java:320)
>>
>> at org.apache.cxf.frontend.**ClientProxy.invokeSync(**
>> ClientProxy.java:89)
>>
>> at org.apache.cxf.jaxws.**JaxWsClientProxy.invoke(**
>> JaxWsClientProxy.java:134)
>>
>> at $Proxy30.getBook(Unknown Source)
>>
>> at
>> com.acme.book.client.ws.**CXFBookOrderManagerClient.**main(**
>> CXFBookOrderManagerClient.**java:116)
>>
>>
>> Thanks
>>
>> Mark
>>
>>
>
> --
> Glen Mazza
> Talend Community Coders - coders.talend.com
> blog: www.jroller.com/gmazza
>
>
Re: question re: JAX-WS SOAP Handlers (alternative to Interceptors)
Posted by Glen Mazza <gm...@talend.com>.
Are you running a Mavenized project so you can run it out of Eclipse to
rule out CXF being the problem? If yes, did you import the project into
Eclipse using mvn eclipse:eclipse?
(http://www.jroller.com/gmazza/entry/web_service_tutorial#EclipseSetup
<http://www.jroller.com/gmazza/entry/web_service_tutorial#EclipseSetup>). If
yes again, you can see the libraries CXF is using via looking at the
Eclipse .classpath file in the Navigator.
You can also download my soap handler tutorial (
http://www.jroller.com/gmazza/entry/jaxws_handler_tutorial), mvn
eclipse:eclipse it into your IDE, and check the .classpath file to see
if there's any difference between my tuturial and your code in the JARs
being used.
HTH,
Glen
On 10/27/2012 07:24 PM, Mark Streit wrote:
> Hello
>
> Wondering if anyone has seen this ... As I am still hunting down on my own.
>
> I recently started using the latest CXF 2.7.0 release with a standalone
> java client program we have been doing some simple POC work with. I
> created an entire new project (simple Java client) and included the CXF
> 2.7.0 JARs (except the jetty stuff and geronimo stuff) in the classpath of
> the IDE project (I double checked the .classpath file manually)....
>
> I am running this using plain Eclipse Indigo and DO NOT RELY on any JARs
> provided by the IDE specifying explicitly all of the JARs to be used by the
> java app configuration. This was working before with 2.6.x.
>
> It all works fine until I attempt to use SOAP Headers using ONLY standard
> jaxws handlers and NOT CXF interceptors. When I run the client ... I see
> the following stacktrace which raises 2 questions...
>
> 1) why the IBM class for SAAJ is showing up is suspicious and
> 2) some Xerces related class can't be found but there is no Xerces related
> JAR that I can find in the 2.7.0 distribution.
>
> I am guessing that something in my environment is fouled up. The
> IBM-specific class is obviously wrong...I assume?. I am using this all
> with Sun/Oracle JDK 1.6.0-34 and no IBM jars.
>
> I must have missed something. Still looking.
>
> Fwiw... The CXF interceptor related classes in the trace are NOT explicitly
> used in my code but are showing up as a result of using only the java
> standard jaxws API .
>
> Exception in thread "main"* java.lang.NoClassDefFoundError:
> org/apache/xerces/dom/AttrImpl*
>
> at java.lang.ClassLoader.defineClass1(Native Method)
>
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
>
> at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
>
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
>
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
>
> at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
>
> at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
>
> at java.security.AccessController.doPrivileged(Native Method)
>
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>
> at
> com.ibm.ws.webservices.engine.soap.MessageFactoryImpl.<init>(MessageFactoryImpl.java:116)
>
> at
> com.ibm.ws.webservices.engine.soap.SAAJMetaFactoryImpl.newMessageFactory(SAAJMetaFactoryImpl.java:56)
>
> at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:148)
>
> at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:114)
>
> at
> org.apache.cxf.binding.soap.saaj.SAAJFactoryResolver.createMessageFactory(SAAJFactoryResolver.java:56)
>
> at
> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor.getFactory(SAAJOutInterceptor.java:86)
>
> at
> org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor.handleMessage(SAAJOutInterceptor.java:122)
>
> at
> org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.handleMessage(SOAPHandlerInterceptor.java:120)
>
> at
> org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.handleMessage(SOAPHandlerInterceptor.java:71)
>
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)
>
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:531)
>
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:464)
>
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:367)
>
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:320)
>
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:89)
>
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:134)
>
> at $Proxy30.getBook(Unknown Source)
>
> at
> com.acme.book.client.ws.CXFBookOrderManagerClient.main(CXFBookOrderManagerClient.java:116)
>
>
> Thanks
>
> Mark
>
--
Glen Mazza
Talend Community Coders - coders.talend.com
blog: www.jroller.com/gmazza