Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 5E228200C14 for ; Tue, 7 Feb 2017 11:58:45 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 5CBD5160B4B; Tue, 7 Feb 2017 10:58:45 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id A843B160B3E for ; Tue, 7 Feb 2017 11:58:44 +0100 (CET) Received: (qmail 43889 invoked by uid 500); 7 Feb 2017 10:58:43 -0000 Mailing-List: contact notifications-help@groovy.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@groovy.apache.org Delivered-To: mailing list notifications@groovy.apache.org Received: (qmail 43880 invoked by uid 99); 7 Feb 2017 10:58:43 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Feb 2017 10:58:43 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 6600E1A07AD for ; Tue, 7 Feb 2017 10:58:43 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, RP_MATCHES_RCVD=-2.999] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id xLKFG8K8ykbZ for ; Tue, 7 Feb 2017 10:58:42 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 6759B5FBE1 for ; Tue, 7 Feb 2017 10:58:42 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id DD86AE0012 for ; Tue, 7 Feb 2017 10:58:41 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 992C524D2F for ; Tue, 7 Feb 2017 10:58:41 +0000 (UTC) Date: Tue, 7 Feb 2017 10:58:41 +0000 (UTC) From: "ANDREY GRIGORYEV (JIRA)" To: notifications@groovy.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (GROOVY-8076) A more helpful error message should be logged when a custom Java class cannot be resolved by the Groovy component due to a Java major/minor version mismatch MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Tue, 07 Feb 2017 10:58:45 -0000 ANDREY GRIGORYEV created GROOVY-8076: ---------------------------------------- Summary: A more helpful error message should be logged when a custom Java class cannot be resolved by the Groovy component due to a Java major/minor version mismatch Key: GROOVY-8076 URL: https://issues.apache.org/jira/browse/GROOVY-8076 Project: Groovy Issue Type: Bug Components: groovy-runtime Reporter: ANDREY GRIGORYEV I spent a couple of hours investigating why my application would no longer successfully deploy to the mule standalone ESB server, yet it would deploy fine to the embedded mule ESB runtime in Anypoint Studio. The error message that I found in the server log was something along the lines of the following: "... Script1.groovy: 1: unable to resolve class com.mycompany.MyReallyUsefulCustomClass ..." I went down all the wrong avenues trying to figure out why the Java class was not being resolved by the Groovy interpreter. Eventually I stumbled upon an explanation of the problem via a Google search: a Java major/minor version mismatch between the version of the Java runtime being used by the Mule ESB runtime and the Java target version of the compiled custom Java classes used by a Mule application being deployed to the Mule ESB server. The cause of my problem was indeed due to a Java version mismatch: the ESB server runtime was running JRE 1.7, but the custom class being referenced by the embedded Groovy script was compiled in Anypoint Studio using JDK 1.8. I would like to formally submit an Enhancement Request for Engineering to improve the customer experience for us developers; possibly by updating the Groovy interpreter component to detect the conflicting Java version issues and log a more helpful error message to the logger. The current message "... unable to resolve class ..." is too general and does not adequately reflect the problem of a mismatch between the JRE version and the compiled byte-code version. An "Unsupported major.minor version x.yy" error message instead would be an improvement. -- This message was sent by Atlassian JIRA (v6.3.15#6346)