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