Return-Path: X-Original-To: apmail-incubator-any23-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-any23-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3658B91DA for ; Fri, 17 Feb 2012 09:22:14 +0000 (UTC) Received: (qmail 43551 invoked by uid 500); 17 Feb 2012 09:22:14 -0000 Delivered-To: apmail-incubator-any23-dev-archive@incubator.apache.org Received: (qmail 43516 invoked by uid 500); 17 Feb 2012 09:22:14 -0000 Mailing-List: contact any23-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: any23-dev@incubator.apache.org Delivered-To: mailing list any23-dev@incubator.apache.org Received: (qmail 43508 invoked by uid 99); 17 Feb 2012 09:22:14 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Feb 2012 09:22:14 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of simone.tripodi@gmail.com designates 209.85.216.54 as permitted sender) Received: from [209.85.216.54] (HELO mail-qw0-f54.google.com) (209.85.216.54) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Feb 2012 09:22:08 +0000 Received: by qaea17 with SMTP id a17so3849955qae.6 for ; Fri, 17 Feb 2012 01:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=p8c0fIZwTNdm+LdlQO6T+9aj0sZJGsfHRx6RstTu+3s=; b=ZeLVMfNxeJnPA+mWSnGiWbCf/QFZI1XF2kUXx1Mv7R7S9WAi/Wdgdb+kM6ol8SHp83 PhuSoYg0MxwYb7kBli3utxGnQiuzkhlQCvPoAyGGFWde48suUxg8u2ekTsnUxJmRrl7C pNu8vE++NbuIZUIagMGg42+4LbM2yqEs2v1zw= MIME-Version: 1.0 Received: by 10.229.78.135 with SMTP id l7mr4270611qck.113.1329470507635; Fri, 17 Feb 2012 01:21:47 -0800 (PST) Sender: simone.tripodi@gmail.com Received: by 10.224.195.73 with HTTP; Fri, 17 Feb 2012 01:21:47 -0800 (PST) In-Reply-To: References: Date: Fri, 17 Feb 2012 10:21:47 +0100 X-Google-Sender-Auth: l7fj1a74pmM9DodG6_Ha8nbJaZg Message-ID: Subject: Re: Plugins loading From: Simone Tripodi To: any23-dev@incubator.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Hi all guys, The ML at ASF is the best place where we can discuss ;) Also because the more people can access to the info, then easier would be involving new volunteers that wants to help :) Anyway, speaking more about technical details: I had a look at the current codebase and even if we restrict the package where performing the plugins research, this operation has always the same complexity, because it needs to visit the whole ClassPath Moreover, it consumes memory: it loads ALL classes for any recognized item that has to be passed to the filter, that checks if the current item is a plugin or not. Just for the record, have a look at The Jersey approach is a little different, IIRC they did a little trick on (and is not efficient as well) What I am proposing is something really simpler, using the ServiceLoader that would still allow dynamic definition of the plugins loaded at runtime, but since plugins are already known at compile time, we can drastically reduce the class loading. There are tools as well that will help us on generating META-INF/services metadata: Ah, and just for the record: I prototyped a general purpose lib for scanning the classpath, using fluent APIs, @commons, see - commons sandbox is open to all ASF committers, in the case you are interested... ;) All the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Feb 17, 2012 at 1:14 AM, Michele Mostarda wrote: > Hi Simo, > > =C2=A0we scan a set of packages that can be specified programmatically, a= s done > by Jersey for example to detect providers. > There are several optimizations that can be done like building a local > cache to avoid a full rescan every time (for example while > running CLI tools). =C2=A0ATM the best choice is to use the more strictes= t > packages as possible. > > I would like to spend some time optimizing the PluginManager, implementin= g > for example a local cache based on, classpath > files modifications. I think we could arrive to a general purpose lib > for classpath scanning in Java (that ATM is missing AFAIK). > > Let me know when you're available for a deeper discussion about it. > > The best. > > Mic > > On 16 February 2012 23:24, Lewis John Mcgibbney > wrote: > >> I'm here Simo, but of little help.. I'm nearly burnt out for the day.... >> >> If we can initiate a discussion it is better than nothing at all I suppo= se. >> >> >> On Thu, Feb 16, 2012 at 10:21 PM, Simone Tripodi >> wrote: >> >> > Hi all, >> > >> > I started having a look at the current plugins architecture and just >> > noticed we scan the classpath: that is the most expensive operation, >> > because no optimization can be applied and it is always linear - that >> > also means that more jars plugin we add, the more is memory/time >> > consumption. >> > >> > There is an improvement we can apply switching over the ServiceLoader >> > pattern, I need anyway more details about the plugins architecture... >> > anyone available? >> > >> > TIA, >> > -Simo >> > >> > http://people.apache.org/~simonetripodi/ >> > http://simonetripodi.livejournal.com/ >> > http://twitter.com/simonetripodi >> > http://www.99soft.org/ >> > >> >> >> >> -- >> *Lewis* >> > > > > -- > Michele Mostarda > Senior Software Engineer > skype: michele.mostarda > twitter: micmos > mail: me@michelemostarda.com > site : http://www.michelemostarda.com