geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <>
Subject Re: Set those service implemetations in the sytsem properties.
Date Sun, 24 May 2009 09:57:03 GMT
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.

2009/5/24 David Jencks <>

> On May 23, 2009, at 10:05 AM, Ivan wrote:
> Hi
>     Currently, I am working on the JIRA
>     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


View raw message