Andrew Zhang wrote:
> What shall we do if context classloader is null?
Try with the System classloader, and if that fails throw an exception.
Tim
> 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]
>>
>>
>
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
