Thanks, David. Multiplace apps may be cause an issue, but I think it is caused by the search policy, for the system property is seen globally. By the way, I always think set those values in the system property are not a good idea, and I notice that in Geronimo, more and more system control properties are used. I just feel that it is somewhat out of control. About the jar tracking, I read some codes, MultiparentClassLoader will really record those unfound jars, It seems that the changes are made after 2.1.4. I will suggest the user to use the new version. If the problem still exists, I will set the system property. Ivan
2009/5/24 David Jencks <[email protected]> > > 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 > > > -- Ivan
