On May 23, 2009, at 10:05 AM, Ivan wrote:
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.