From dev-return-73549-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org Sat May 23 22:01:57 2009 Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 12561 invoked from network); 23 May 2009 22:01:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 23 May 2009 22:01:57 -0000 Received: (qmail 58908 invoked by uid 500); 23 May 2009 22:02:09 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 58805 invoked by uid 500); 23 May 2009 22:02:09 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 58796 invoked by uid 99); 23 May 2009 22:02:09 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 23 May 2009 22:02:09 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [76.13.13.44] (HELO smtp105.prem.mail.ac4.yahoo.com) (76.13.13.44) by apache.org (qpsmtpd/0.29) with SMTP; Sat, 23 May 2009 22:02:01 +0000 Received: (qmail 29568 invoked from network); 23 May 2009 22:01:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-Id:From:To:In-Reply-To:Content-Type:Mime-Version:Subject:Date:References:X-Mailer; b=HKmLDAQ2XgQrc6TBREVdG3ZUhDw+l18Zt/FlXRnk5pskXHxkYw43xn5gLy2lsuSXaN6GjX4+iTO95C1ioYB5g4VE0okTyIpHNzrFPAKTXqhl6SNQz012fQmjOwsfApQSDCRZb6+zyQIyzqbpE7z3Qwkh9TZqcbAtqDlbuo1tTTg= ; Received: from h-66-167-248-225.cmbrmaor.dynamic.covad.net (david_jencks@66.167.248.225 with plain) by smtp105.prem.mail.ac4.yahoo.com with SMTP; 23 May 2009 15:01:37 -0700 PDT X-Yahoo-SMTP: .9oIUzyswBANsYgUm_5uPui0skTnzGJXJQ-- X-YMail-OSG: DZ9c8SwVM1l83rhbqQwf.80HaJ2YSmD9jncWVDbbXaLL_Z6.U1BjX6bueSyNRjAQPakH22dilw6cbXslV5RvtHmPo6ngPKhP9sEsTFx9Oxlwel5DRkeNGyfgiy6MXPlDi6LSQ0sGhoczojY19IaxAf00ne5L2vayRYTa3AfqDRF5E9iCVIs9fuFyjcOjaQHZ9UFtkfspttvKzPrruv7n21Dnx2X2WFVFz.L5LNP6dlFG_fA8SWJxQRBBytWQb841eZG_.OILkuiCKKFSOx9EcE_aLYPyEMZZNtuSXtsRITc7Hc5kTWKRxJwZ1z8azMt5Vqk5HlKLgJdqkAtZ_Arwk3U- X-Yahoo-Newman-Property: ymail-3 Message-Id: From: David Jencks To: dev@geronimo.apache.org In-Reply-To: <45f744e40905230705m668d4ae5x31c7b4e681afebc7@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2-668407665 Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Set those service implemetations in the sytsem properties. Date: Sat, 23 May 2009 18:01:36 -0400 References: <45f744e40905230705m668d4ae5x31c7b4e681afebc7@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-2-668407665 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 23, 2009, at 10:05 AM, Ivan wrote: > Hi > Currently, I am working on the JIRA https://issues.apache.org/jira/browse/GERONIMO-4623 > . > The issus is caused by the implementation search, the solution I > could see is that to keep a reference to the factory instance, so > that we do not need to execute the searching work each time > But the question is that we could not change some codes in the third- > party libraries, so the costly search still exists. > I have an idea is that, since most service API has the same > order to search the service implemtation, usually, the first order > is to check the system properties. So, I wish to set those > properties. the logic may be like: > a. Check whether the coressponding system properties are set. > b. If not, we manually create an instance, like > TransformerFactory.newInstance(), then set the system property for > them, > From my view, the SystemProperties may be the place to do it. The > related properties include TransformerFactory, > DocumentBuilderFactory etc > Thanks for any comment ! This might be a good idea, I'm not sure. The danger is, I think, that with the current behavior different apps with different parents can possibly get different TransformerFactory, etc. IIUC with your suggestion the first app to successfully create a TF will force its choice on everyone else. Possibly other apps won't even be able to create the TF specified by the first one. If you think this danger is unlikely, go ahead and set the system properties. However we should probably review in g. 3 to make sure its still a problem with osgi classloading. I also wonder if we are properly tracking jars we've already searched. I suspect that the "multiple searches for same missing jar" is because there are a lot of ways to get to a particular jar. Classloading keeps track of which jars have already been searched, maybe looking for resources does not. thanks david jencks > > > -- > Ivan --Apple-Mail-2-668407665 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On May 23, 2009, = at 10:05 AM, Ivan wrote:

Hi
    Currently, I am working on the = JIRA https://issue= s.apache.org/jira/browse/GERONIMO-4623.
    The = issus is caused by the implementation search, the solution I could see = is that to keep a reference to the factory instance, so that we do not = need to execute the searching work each time
But the question is = that we could not change some codes in the third-party libraries, so the = costly search still exists.
    I have an idea is = that, since most service API has the same order to search the service = implemtation, usually, the first order is to check the system = properties. So, I wish to set those properties. the logic may be = like:
   a. Check whether the coressponding system = properties are set.
   b. If not, we manually create an = instance, like TransformerFactory.newInstance(), then set the system = property for them,
   =46rom my view, the SystemProperties = may be the place to do it. The related properties include = TransformerFactory, DocumentBuilderFactory etc
   Thanks = for any comment !

This might be a good = idea, I'm not sure.

The danger is, I think, = that with the current behavior different apps with different parents can = possibly get different TransformerFactory, etc.  IIUC with your = suggestion the first app to successfully create a TF will force its = choice on everyone else.  Possibly other apps won't even be able to = create the TF specified by the first one.

If = you think this danger is unlikely, go ahead and set the system = properties.  However we should probably review in g. 3 to make sure = its still a problem with osgi classloading.

I = also wonder if we are properly tracking jars we've already searched. =  I suspect that the "multiple searches for same missing jar" is = because there are a lot of ways to get to a particular jar. =  Classloading keeps track of which jars have already been searched, = maybe looking for resources does = not.

thanks
david = jencks





-- =
Ivan

= --Apple-Mail-2-668407665--