[
https://issues.apache.org/jira/browse/GROOVY-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15449136#comment-15449136
]
Andrew Garcia edited comment on GROOVY-7623 at 8/30/16 2:19 PM:
----------------------------------------------------------------
For anyone who is attempting to use the IBM JDK 8 for a grails project, here is
how I did it in my development environment for a Grails 2.5.5 project. I'm
sure there is a lower common denominator of a solution but, this is what I did.
I'm currently deploying to Heroku in production and developing on Mac OSX so
it made things a little trickier since I didn't have a Linux environment handy
to unpack the .bin from IBM.
Once you've got the .tar.gz in hand, I had to untar it, remove jre/lib/xml.jar
since it's using old versions of xerces/xalan/etc classes and weren't playing
nice with my Grails 2.5.5 project. Then, I added the following files into
jre/lib/endorsed:
jaxp-api-1.4.2.jar, serializer-2.7.2.jar, xalan-2.7.2.jar,
xercesImpl-2.9.1.jar, xml-apis-1.3.04.jar
Now, there's a fun little piece of code in ClasspathConfigurer that likes to
force you to use a particular javax.xml.parsers.DocumentBuilderFactory if
Grails finds a xercesImpl dependency (transitive or not) in your BuildConfig.
And, ClasspathConfigurer gets invoked when using ./grailsw (which Heroku makes
use of). So, that's why I "had" to put xercesImpl in the endorsed lib instead
of just using the version in my project. I attempted to use the IBM JDK as it
was combined with Heroku's support for a .jdk-overlay directory but it wasn't
strong enough of an override.
{code:title=ClasspathConfigurer.java|borderStyle=solid}
protected void addDependenciesToURLs(Set<String> excludes, List<URL> urls,
List<File> runtimeDeps) throws MalformedURLException {
if (runtimeDeps == null) {
return;
}
for (File file : runtimeDeps) {
if (file == null ) {
continue;
}
if (file.getName().contains("xercesImpl")) {
// workaround for GRAILS-9708
System.setProperty("javax.xml.parsers.DocumentBuilderFactory","com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl");
}
if (excludes != null && !excludes.contains(file.getName())) {
URL url = file.toURI().toURL();
if (urls.contains(url)) continue;
urls.add(url);
excludes.add(file.getName());
}
}
}
{code}
In my BuildConfig.groovy I had to add setting the following dependencies:
{code}
runtime ('org.codehaus.groovy.modules.http-builder:http-builder:0.7.1')
{excludes 'xercesImpl'}
runtime "xalan:xalan:2.7.2"
runtime "com.fasterxml.woodstox:woodstox-core:5.0.3"
{code}
The xercesImpl exclusion I explained and the woodstox is because the xml.jar
IBM had included some streaming XML class files that needed replenishing.
Then......
After I re-tared up the IBM JDK with the xml.jar removed and my other jars
inserted I was able to start the Heroku server and get past the step of grailsw
that auto-generates the war file.
Then....
I ran into the problem where IBM's JSSE loves to default to using TLS 1.0 and
my integration with Stripe was failing since that requires TLSv1.2 "or higher".
After some more headbanging I ran into this IBM support doc that was
satisfyingly infuriating. I was simultaneously pissed they made the choice not
to operate like every other JDK but at least they made it possible to play nice.
{quote}
Use the system property com.ibm.jsse2.overrideDefaultTLS to match the behavior
of SSLContext.getInstance("TLS") in the IBM SDK with the Oracle implementation.
com.ibm.jsse2.overrideDefaultTLS =true|false
{quote}
from [IBM
Support|http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/matchsslcontext_tls.html#matchsslcontext_tls]
After all of that and I'm still not seeing the classes get garbage collected.
I pray it's because I'm somehow misusing groovy.use.classvalue=true
!Screen Shot 2016-08-30 at 10.11.18 AM.png!
was (Author: gsandrew):
For anyone who is attempting to use the IBM JDK 8 for a grails project, here is
how I did it in my development environment for a Grails 2.5.5 project. I'm
sure there is a lower common denominator of a solution but, this is what I did.
I'm currently deploying to Heroku in production and developing on Mac OSX so
it made things a little trickier since I didn't have a Linux environment handy
to unpack the .bin from IBM.
Once you've got the .tar.gz in hand, I had to untar it, remove jre/lib/xml.jar
since it's using old versions of xerces/xalan/etc classes and weren't playing
nice with my Grails 2.5.5 project. Then, I added the following files into
jre/lib/endorsed:
jaxp-api-1.4.2.jar, serializer-2.7.2.jar, xalan-2.7.2.jar,
xercesImpl-2.9.1.jar, xml-apis-1.3.04.jar
Now, there's a fun little piece of code in ClasspathConfigurer that likes to
force you to use a particular javax.xml.parsers.DocumentBuilderFactory if
Grails finds a xercesImpl dependency (transitive or not) in your BuildConfig.
And, ClasspathConfigurer gets invoked when using ./grailsw (which Heroku makes
use of). So, that's why I "had" to put xercesImpl in the endorsed lib instead
of just using the version in my project. I attempted to use the IBM JDK as it
was combined with Heroku's support for a .jdk-overlay directory but it wasn't
strong enough of an override.
{code:title=ClasspathConfigurer.java|borderStyle=solid}
protected void addDependenciesToURLs(Set<String> excludes, List<URL> urls,
List<File> runtimeDeps) throws MalformedURLException {
if (runtimeDeps == null) {
return;
}
for (File file : runtimeDeps) {
if (file == null ) {
continue;
}
if (file.getName().contains("xercesImpl")) {
// workaround for GRAILS-9708
System.setProperty("javax.xml.parsers.DocumentBuilderFactory","com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl");
}
if (excludes != null && !excludes.contains(file.getName())) {
URL url = file.toURI().toURL();
if (urls.contains(url)) continue;
urls.add(url);
excludes.add(file.getName());
}
}
}
{code}
In my BuildConfig.groovy I had to add setting the following dependencies:
{code}
runtime ('org.codehaus.groovy.modules.http-builder:http-builder:0.7.1')
{excludes 'xercesImpl'}
runtime "xalan:xalan:2.7.2"
runtime "com.fasterxml.woodstox:woodstox-core:5.0.3"
{code}
The xercesImpl exclusion I explained and the woodstox is because the xml.jar
IBM had included some streaming XML class files that needed replenishing.
Then......
After I re-tared up the IBM JDK with the xml.jar removed and my other jars
inserted I was able to start the Heroku server and get past the step of grailsw
that auto-generates the war file.
Then....
I ran into the problem where IBM's JSSE loves to default to using TLS 1.0 and
my integration with Stripe was failing since that requires TLSv1.2 "or higher".
After some more headbanging I ran into this IBM support doc that was
satisfyingly infuriating. I was simultaneously pissed they made the choice not
to operate like every other JDK but at least they made it possible to play nice.
{quote}
Use the system property com.ibm.jsse2.overrideDefaultTLS to match the behavior
of SSLContext.getInstance("TLS") in the IBM SDK with the Oracle implementation.
com.ibm.jsse2.overrideDefaultTLS =true|false
{quote}
from [IBM
Support|http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/matchsslcontext_tls.html#matchsslcontext_tls]
After all of that and I'm still not seeing the classes get garbage collected.
!Screen Shot 2016-08-30 at 10.11.18 AM.png!
> IBM Java (J9) ClassValue works correctly so should use it by default
> --------------------------------------------------------------------
>
> Key: GROOVY-7623
> URL: https://issues.apache.org/jira/browse/GROOVY-7623
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 2.4.5
> Reporter: Craig
> Assignee: Pascal Schumacher
> Fix For: 2.4.6
>
> Attachments: Screen Shot 2016-08-30 at 10.11.18 AM.png
>
>
> GROOVY-7591 disabled the use of java.lang.ClassValue by default due to a bug
> in OpenJDK: https://bugs.openjdk.java.net/browse/JDK-8136353 The result is
> that GROOVY-6704 occurs on all versions of Java again.
> The bug in OpenJDK does not impact IBM Java, so when running on IBM Java,
> java.lang.ClassValue should be used by default. So at least users on IBM
> Java will not experience GROOVY-6704.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
