Return-Path: Delivered-To: apmail-felix-dev-archive@www.apache.org Received: (qmail 47278 invoked from network); 3 Sep 2009 16:25:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 3 Sep 2009 16:25:14 -0000 Received: (qmail 15089 invoked by uid 500); 3 Sep 2009 16:25:14 -0000 Delivered-To: apmail-felix-dev-archive@felix.apache.org Received: (qmail 15011 invoked by uid 500); 3 Sep 2009 16:25:13 -0000 Mailing-List: contact dev-help@felix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@felix.apache.org Delivered-To: mailing list dev@felix.apache.org Received: (qmail 15001 invoked by uid 99); 3 Sep 2009 16:25:13 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Sep 2009 16:25:13 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of heavy@ungoverned.org designates 69.89.22.9 as permitted sender) Received: from [69.89.22.9] (HELO outbound-mail-109.bluehost.com) (69.89.22.9) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 03 Sep 2009 16:25:03 +0000 Received: (qmail 18251 invoked by uid 0); 3 Sep 2009 16:24:42 -0000 Received: from unknown (HELO host118.hostmonster.com) (74.220.207.118) by outboundproxy3.bluehost.com with SMTP; 3 Sep 2009 16:24:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=ungoverned.org; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=SrcMb2FpmEjYFeJX2zFGYBEnFxmdbxZ+Xwxn5S5tJofFB9YrAOnDZEmcXOaITqR5h3REVBU0OjRnno0LaLyaOMxEzsV+xZWLVlpbIMxg8hEEpV3WC7Q4OO8wLPZwhb8C; Received: from adsl-75-40-240-247.dsl.klmzmi.sbcglobal.net ([75.40.240.247] helo=[192.168.1.71]) by host118.hostmonster.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MjF74-0005HM-9R for dev@felix.apache.org; Thu, 03 Sep 2009 10:24:42 -0600 Message-ID: <4A9FEDC8.8080502@ungoverned.org> Date: Thu, 03 Sep 2009 12:24:40 -0400 From: "Richard S. Hall" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: dev@felix.apache.org Subject: Re: Packages exported by fileinstall References: <81f0d9c0909030706y21b7cd8eof9b96ebdc7a3a891@mail.gmail.com> <81f0d9c0909030743j33a6a581gac762b8641b41352@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1027:host118.hostmonster.com:ungovern:ungoverned.org} {sentby:smtp auth 75.40.240.247 authed with heavy@ungoverned.org} X-Virus-Checked: Checked by ClamAV on apache.org On 9/3/09 11:56, Guillaume Nodet wrote: > But this means the code has to dynamically load the class, right ? Or at > least try to load it each time it will log something. Wouldn't that hurt > performance ? I like the idea of being able to automatically detect the log > api when installed though. > No, it doesn't need to dynamically load it, just try to use it, which will result in an exception like a normal class load attempt...the only difference is that it may eventually become resolved in the future. If you were doing lots of logging, it would likely hurt performance, but you don't have to try to load the class each time. You could devise your logging methods to probe for the package once day, for example. -> richard > On Thu, Sep 3, 2009 at 16:43, Stuart McCulloch wrote: > > >> 2009/9/3 Guillaume Nodet >> >> >>> On Thu, Sep 3, 2009 at 16:06, Stuart McCulloch >>> >> wrote: >> >>> >>>> 2009/9/3 Guillaume Nodet >>>> >>>> >>>>> Fileinstall exports the org.osgi.service.cm and org.osgi.service.log >>>>> packages. >>>>> I wonder if this would make more sense to make them optional import >>>>> >> and >> >>>>> make >>>>> sure the code can run if those are not wired. >>>>> >>>>> >>>> yep, this comes down to whether you should package the API with the >>>> >>> bundle >>> >>>> or not >>>> ( and as Richard says FileInstall doesn't implement the API, so no need >>>> >>> to >>> >>>> export it ) >>>> >>>> http://www.mail-archive.com/osgi-dev@mail.osgi.org/msg00097.html >>>> >>>> for an optional dependency it can make sense to use an optional import >>>> >> - >> >>>> although >>>> it does then make the code a little bit more involved, as your recent >>>> commit >>>> shows >>>> >>>> >>> >>> >>>> you should also remember optional imports are only checked *once* at >>>> resolution >>>> >>>> for example, if I start the FileInstall bundle without the LogService >>>> >> API >> >>>> available and >>>> only later on install a logger, then FileInstall won't pick up this >>>> >>> service >>> >>>> until its bundle >>>> is refreshed >>>> >>> But if fileinstall exports the package, then you install a log service, >>> >> the >> >>> log service will be wired to fileinstall if it has the same api, which >>> means >>> if you later uninstall fileinstall, the log service need to be refreshed. >>> >>> >> yes I'm not talking about exporting it, I totally agree FileInstall doesn't >> need the export >> >> I'm talking about the difference between: >> >> Import-Package: org.osgi.service.log;resolution:=optional >> >> and: >> >> DynamicImport-Package: org.osgi.service.log >> >> the former means a "one-time" check when the bundle resolves, the latter >> will continue >> to check on each request until the import can be satisfied (and then won't >> recheck until >> the bundle is refreshed) >> >> so for the optional import case, if I install and resolve FileInstall on a >> system without the >> LogService API, then I install and resolve a logger (along with the >> compendium API) then >> I don't believe FileInstall will see the logger unless it's refreshed >> >> whereas with the dynamic import, it would be able to pick up the newly >> installed logger >> >> >> >>> And if the log service implements a higher version of the api, the >>> fileinstall won't be able to use it either because it already exports its >>> own package and you have to refresh anyway. >>> So in all cases, I think you need to refresh at some point, unless the >>> service is really optional and it does not really matter so much if it is >>> imported or not, which is the case here. >>> >>> >>>> ( to handle this use-case you would need DynamicImport-Package >>>> ) >>>> >>>> >>> >>> Or retrieve the service and use introspection to call it, which is quite >>> ugly too. >>> >>> >>> >>>> As a side effect would also reduce the size of the jar and simplify the >>>> >>>>> resolution process (I don't having having bundles exporting the same >>>>> package >>>>> really helps ...) >>>>> >>>>> >>>> well some people will want to bundle APIs with their implementations >>>> (potentially one >>>> less bundle to manage) and in this case exporting+importing the API >>>> >> makes >> >>>> sense >>>> >>>> >>> Right, and that's what most of our services do afaik. >>> >>> >>> >>>> most of the performance issues I've seen wrt. resolution have been from >>>> >>> bad >>> >>>> APIs >>>> which have lots of uses constraints - I think that's more of a problem >>>> >> to >> >>>> be >>>> honest >>>> >>>> Thoughts ? >>>> >>>>> -- >>>>> Cheers, >>>>> Guillaume Nodet >>>>> ------------------------ >>>>> Blog: http://gnodet.blogspot.com/ >>>>> ------------------------ >>>>> Open Source SOA >>>>> http://fusesource.com >>>>> >>>>> >>>> >>>> >>>> -- >>>> Cheers, Stuart >>>> >>>> >>> >>> >>> -- >>> Cheers, >>> Guillaume Nodet >>> ------------------------ >>> Blog: http://gnodet.blogspot.com/ >>> ------------------------ >>> Open Source SOA >>> http://fusesource.com >>> >>> >> -- >> Cheers, Stuart >> >> > > >