What shall we do if context classloader is null?
RI still could load the configuration file even if context classloader is
null.
On 8/4/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Jimmy, Jing Lv wrote:
> Paulex Yang wrote:
>> Andrew Zhang wrote:
>>> Hi, all
>>>
>>> Things are a little bit complex when I tried to implement this
>>> workaround.
>>>
>>> Consider availableCharsets() method from Charset.java, which loads
>>> provider
>>> classes from configuration file.
>>>
>>> Please see my comments inline.
>>>
>>> final ClassLoader cl = getContextClassLoader();
>>> if (null != cl) { // what shall we do if context class loader is
null?
>>> try {
>>> // context classloader is used to get resources.
>>> Enumeration e = cl
>>> .getResources(PROVIDER_CONFIGURATION_FILE_NAME);
>>> // Examine each configuration file
>>> while (e.hasMoreElements()) {
>>> // here, context classloader is used to load class.
>>> // If system classloader is used as backup when context classloader
>>> fails to
>>> load, it seems illogical, because it's context classloader who get
>>> resources.
>>> // It should be the same classloader who gets resources and loads
>>> corresponding classes.
>>> loadConfiguredCharsets((URL) e.nextElement(), cl, charsets);
>>> }
>>> } catch (IOException ex) {
>>> // Unexpected ClassLoader exception, ignore
>>> }
>>> }
>>>
>>> If we put another copy code after this section, using "system
>>> classloader"
>>> instead of "context classloader", it also seems illogical. What shall
>>> we do
>>> if context classloader fails to load a provider charset class? Should
it
>>> throw an error as spec requires or pass silently?
>> Hmm... I think more serious problem here is that the classloader is
>> used not only to load the CharsetProvider class, but also to load the
>> configuration files, so if we choose to try context classloader then
>> system classloader, they may load different config files! IMHO, the
>> behavior will be contradict with both RI and spec. I suggest we give
>> up the *third way* and choose one(RI or spec) to follow, from others'
>> comments, Sun has been aware of this for long time, so they must have
>> reason not to fix the codes, maybe just because this is a not trivial
>> difference(it may be significant for server application which has
>> multi classloaders and special charsets), so I suggest we follow RI.
>>
>
> I notice some lines of spec of CharsetProvider:
> in the end of Para 1, it reads clearly:
> "Charset providers are looked up via the current thread's context class
> loader."
> and in the Para 3, it reads:
> "The provider must be accessible from the same class loader that was
> initially queried to locate the configuration file; this is *not*
> necessarily the class loader that loaded the file."
>
> Seems Spec says nothing about which classloader is used to locate
> configuration file, but the tests has shown that it can be the system
> classloader.
>
> OK, then I think we can do like this:
> use System Classloader to locate the configuration file, then use
> thread's context class loader to load providers; if fails, use System
> Classloader to load providers; if fails again, throw exception.
Sound like a good idea.
Regards,
Tim
> This shall not break "following RI" nor Spec because: 1. we has used
> context class(follow spec Para1); 2. we use System Classloader to locate
> configuration file, and the provider must be accessible to this
> classloader or it will throw exception(follow spec Para3, the first
> sentence); 3. spec never forbid us from using difference
> classloader(spec Para3, the second sentence); 4. at last we use System
> Classloader to load the provider if context classloader fails(we follow
> RI).
>
> I feel very curious what does sun think about this problem. :) However
> let's work around, waiting for RI to correct code, or correct spec.
>
>>
>>>
>>> To sum up, it's hard to follow RI, and comply with spec
>>> simultaneously. We
>>> have to choose one of them. Spec or RI?
>>>
>>> I don't think RI would change its behaviour in later release. In
>>> fact, the
>>> "bug" still exists in SUN 6.0 rc version. Personally, +1 for
>>> following RI.
>>>
>>> Any comments or better suggestions?
>>>
>>> Thanks!
>>>
>>>
>>
>>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrew Zhang
China Software Development Lab, IBM
