groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Garcia (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (GROOVY-7623) IBM Java (J9) ClassValue works correctly so should use it by default
Date Tue, 30 Aug 2016 14:19:21 GMT

    [ 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:18 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.  

!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.  

!http://imgur.com/a/be9JY!

> 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)

Mime
View raw message