geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Set those service implemetations in the sytsem properties.
Date Sat, 23 May 2009 22:01:36 GMT

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


Mime
View raw message