From users-return-587-apmail-groovy-users-archive=groovy.apache.org@groovy.incubator.apache.org Thu Jul 30 14:47:33 2015 Return-Path: X-Original-To: apmail-groovy-users-archive@minotaur.apache.org Delivered-To: apmail-groovy-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1403418B32 for ; Thu, 30 Jul 2015 14:47:33 +0000 (UTC) Received: (qmail 56889 invoked by uid 500); 30 Jul 2015 14:47:20 -0000 Delivered-To: apmail-groovy-users-archive@groovy.apache.org Received: (qmail 56855 invoked by uid 500); 30 Jul 2015 14:47:20 -0000 Mailing-List: contact users-help@groovy.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@groovy.incubator.apache.org Delivered-To: mailing list users@groovy.incubator.apache.org Received: (qmail 56845 invoked by uid 99); 30 Jul 2015 14:47:20 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Jul 2015 14:47:20 +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 C70CB1A9286 for ; Thu, 30 Jul 2015 14:47:19 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=6.31 tests=[SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id xEOl64vrpr_m for ; Thu, 30 Jul 2015 14:47:18 +0000 (UTC) Received: from mail.finkzeit.at (ns.finkzeit.at [62.218.44.2]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id CDBC1210DF for ; Thu, 30 Jul 2015 14:47:17 +0000 (UTC) Received: from fzv1.finkzeit.at ([10.0.0.3]) by mail.finkzeit.at with esmtp (Exim 4.71) (envelope-from ) id 1ZKp6l-0001UP-9U for users@groovy.incubator.apache.org; Thu, 30 Jul 2015 16:46:55 +0200 Received: from fzvnb25.finkzeit.at ([10.0.0.14]) by fzv1.finkzeit.at with esmtpa (Exim 4.54) id 1ZKp6k-0002Dw-JY for users@groovy.incubator.apache.org; Thu, 30 Jul 2015 16:46:54 +0200 Message-ID: <55BA38DE.4090204@finkzeit.at> Date: Thu, 30 Jul 2015 16:46:54 +0200 From: Wolfgang Pedot User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: users@groovy.incubator.apache.org Subject: groovy-all OSGi bundle dependencies Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi again, searching for the causes of a sudden increase in script-compile time in an OSGi application I am now investigating classloading. Here is the simplified scenario: OSGi application with lots of bundles, one of which (lets call it bundle A) uses GroovyScriptEngines to load small scripts for customisations, these scripts can work with classes imported from other bundles. There are lots of other bundles to, one of which has some embedded jars in its bundle-classpath, lets call that one bundle B. And of corse there is also a groovy-all bundle (from embeddable-dir of binary distribution). As soon as there is a dependency from bundle B on anything from the groovy-bundle (like an import of groovy.lang) the script-compile times (and first execution-times) of the GroovyScriptEngine in bundle A skyrocket because the jars in the bundle-classpath of bundle B get accessed like crazy during compilation and first execution. I noticed that even though I use the classloader of bundle A as parent for the GroovyScriptEngine the groovy-bundle gains some dependencies on my bundles at runtime and that basically creates some sort of dependency-cycle between the groovy-bundle and bundles A/B which leads to those exessive reads of the lib-jars in bundle B. All I need in bundle B is a reference to Closure because there is one class that has gained a method which accepts a Closure as an argument.... I hope I have explained the situation clearly, does anyone have an idea or a tip what to do here? Whats interesting is that this only appears to be a problem in the deployed application, when I run it inside Eclipse I do not see that many read-accesses.... regards Wolfgang Pedot