harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Zhang" <zhanghuang...@gmail.com>
Subject Re: [classlib][nio-charset] RI is inconsistent with spec when loading charset provider
Date Mon, 07 Aug 2006 04:54:42 GMT
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 <t.p.ellison@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Andrew Zhang
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message