Java 11 - Using Javax.xml.soap libraries

[JBristow]

We're currently upgrading from 7.2.1 to 8.0.1 - which requires Java 11. We're upgraded our Job Servers to Java 11 - and most jobs run without issue. However - we have one job currently identified which the developer added "custom Groovy code" - I HATE custom code being added - and the Groovy component imports a number of "javax.xml.soap" libraries and those no longer exist in Java 11. Thus the job compiled fine - but when the Groovy script executes we get "unable to resolve class javax.xml.soap.SOAPException" as an example.

I'm trying to avoid re-engineering the job to remove the custom coding - although that should be done IMO - but this would seem to be an issue with Java 11 for others and wonder if anyone else has encountered this issue and how they resolved it. I've added various libraries using the "tLibraryLoad" component and I can get around the error by using "saaj" platforms - but then I get a factory error when building the soap message so there are more dependencies missing I assume. I see nothing in the Maven list of platforms to include in the tLibraryLoad which relate to "javax.xml.soap" in any way.

There should be an easy way to include these needed libraries - but because we're importing them within a Groovy component - I think that complicates the issue.

Any direction/assistance from anyone would be helpful.

Thank You.

Errors:

Script1.groovy: 28: unable to resolve class javax.xml.soap.SOAPConnection

 @ line 28, column 1.

  import javax.xml.soap.SOAPConnection

  ^

Script1.groovy: 19: unable to resolve class javax.xml.soap.SOAPEnvelope

 @ line 19, column 1.

  import javax.xml.soap.SOAPEnvelope

  ^

Script1.groovy: 22: unable to resolve class javax.xml.soap.SOAPMessage

 @ line 22, column 1.

  import javax.xml.soap.SOAPMessage

.....(more)

[Anonymous]

Hmmm, I'll admit straight away that I have not done a great deal of work with Groovy in Talend. It's one of the areas where I am not terribly experienced. But the library dependancies (from experience in coming across this situation from using Routines a lot) will almost certainly need to be dealt with manually here. It's not ideal and I have raised a few feature requests to get an easier way of handling this.

You can either hunt out the dependencies (search for the Jars online and you will find the relevant dependencies) and set up tLibraryLoad components for them. Or (and this a theory rather than a guarantee) set up a dummy routine and link the libraries to the routine. Then attach the routine to your job. All of the libraries linked to the routine should be available to the whole job. I'd be interested to see if that works for you with regard to the Groovy component.

[JBristow]

Thanks. I've been able to get around the "import" errors by adding various libraries via the "tLibraryLoad" component; but then I get an error that the soap message can't be created. This is exactly the reason I have my developers avoid customized code. At some point - something will break. This has been running for almost 5 years now....and a Talend upgrade requiring Java 11 breaks it. I think it's time to look at re-engineering how this was built to use out-of-the-box components and associated code. 🙂

[Anonymous]

Ah, maybe I misunderstood your question. Sorry about that. How are you creating the SOAP message? Is it using the Groovy script? Or are you doing this with a tXMLMap? What error are you getting?

I would say that one of the benefits of Talend is that you can open A LOT of doors by using code, but it is best to keep as much of that in Routines and reuse the same code rather than let developers add a single tJava and do everything in Java. Essentially live by the rule of "Don't reinvent wheel". If there is a component to do something, use the component.

[JBristow]

The SOAP message is generated in the Groovy script. Importing a total of 41 libraries in essence makes this one component it's own job. While I avoid custom code, I agree with you that the ability to add custom code can open doors - I just think the usage should be limited to those instances where it makes sense; the impact is limited if it breaks; and confidence is high that moving forward with new versions will not break the processing. There are a lot of tools out there that might be better suited than Talend for whatever the custom code purpose might be. As I tell my team - Never say "never" - but be smart about it. 🙂 Thanks

[Anonymous]

I see. I think we are on the same page regarding the custom code. Another approach is to use the Talend Component Toolkit. This makes it so much easier to control during upgrades, etc.

But, back to your issue here. Why is the SOAP message not created using a tXMLMap? I suspect there is a reason, but maybe there is a way in which this can be overcome. The tXMLMap would be a lot easier to control.

[JBristow]

I believe when this was built back in 2016/2017...we were on version 6.0.1 and this was done as a way to process multiple attachments in a soap message. (It's been a long time...and I didn't built this, so i could be wrong - but that's what I recall).