on ‎2023 Jun 17 9:07 AM
The Groovy script
import com.sap.gateway.ip.core.customdev.util.Message
Message slurper_test(Message message){
def result = 'XmlSlurper: ' + new XmlSlurper().getClass() + '\n'
result += 'Groovy version: ' + GroovySystem.getVersion()
message.setBody(result)
return message
}
gives currently the following output on my CPI trial:
XmlSlurper: class groovy.util.XmlSlurper
Groovy version: 2.4.21
In the Groovy documentation on the processing of xml are the xml parsers (XmlSlurper and XmlParser) discussed which are contained in the groovy.xml package. So I added the import statement
import groovy.xml.XmlSlurper
to the above script and ran it again, but I received the following error:
javax.script.ScriptException: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: script1__Script.groovy: 2: unable to resolve class groovy.xml.XmlSlurper @ line 2, column 1. import groovy.xml.XmlSlurper
By consulting the Groovy documentation of the package groovy.xml for version 2.4.21 this error becomes clear as there is no XmlSlurper class within the groovy.xml package in this version of Groovy. However it seems that starting with Groovy version 3.0.0 the xml parser classes in the groovy.util package are marked as deprecated and with Groovy version 4.0.0 the xml parser classes are even removed from the groovy.util package. My questions are:
Request clarification before answering.
Hi Benjamin
Interesting observation and some very nice research you did before posting your question - well done!
Looking at the documentation of groovy.util.XmlSlurper in 2.4.21 and groovy.xml.XmlSlurper in 3.0.0, I would assume that they are in fact the same class, only now located in a more appropriate package. So if you just skip the import, you'll instantiate the XmlSlurper that's on the classpath and your code will keep running.
(If you want to make absolutely sure, check the source code.)
Regarding your second question, updates to underlying components like the Groovy runtime are too low-level to be on the roadmap. That's actually why I created CPITracker a few years back, but it's not updating the Twitter feed at the moment (not since the Twitter API was changed (I'll get around to fixing it at some point)).
Regards,
Morten
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi 7a519509aed84a2c9e6f627841825b5a,
thanks for your response! I just tested this on my computer with Groovy version 3 and 4. If we don't specify any import in Groovy 3 we will keep using groovy.util.XmlSlurper and in Groovy 4 the compiler throws the error: unable to resolve class XmlSlurper. groovy.util belongs to the packages which are by default imported in Groovy, but groovy.xml does not. Maybe it makes sense to add the import
import groovy.xml.*already to all Groovy scripts (to future proof them)? This way groovy.xml.XmlSlurper is used in Groovy 3 and 4.
BR, Benjamin
Hi bng
I see your point. I do feel fairly sure that this will not be implemented as a breaking change, though.
If you want to monitor it to make sure, you could implement a small, scheduled iflow that checks for XmlSlurper in those two packages and, for instance, sends you an email, if there is a change.
Regards,
Morten
| User | Count |
|---|---|
| 8 | |
| 7 | |
| 6 | |
| 6 | |
| 5 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.