On Thu, 2005-05-19 at 21:54 +0200, Sascha Brawer wrote: > Hi Nicolas, > > http://developer.classpath.org/doc/java/util/logging/LogManager.html > > I think the default config file should not be shipped as part of > glibj.zip, but instead installed as a separate file. Sorry, I don't have > the time right now to fix it myself... >
OK. Thank you Sascha for the answer. So, properties files inside a jar (or zip) archive are always handled by the application (or the gnu classpath files)? Nothing should be done at the opening of the jar file? If I'm asking, it's because i'm afraid as a vm implementor to make some code that will read a jar file (like glibj.zip) and do things like looking for *.properties files from it. > -- Sascha > > Nicolas Geoffray wrote: > > >On Thu, 2005-05-19 at 16:27 +0200, Michael Koch wrote: > > > > > >>On Thu, May 19, 2005 at 03:14:44PM +0200, Nicolas Geoffray wrote: > >> > >> > >>>Hello all, > >>> > >>> > >>>I'm a student in a french university and finalizing a jvm > >>>implementation, using the gnu classpath. I'm having a few questions (i > >>>hope it's the right place to ask). > >>> > >>>First question : how can i handle properties file stored in the > >>>glibj.zip. A simple example is the readConfiguration function in > >>>java/util/logging/LogManager class file. It first trys to get a > >>>"java.util.logging.config.file" property which should be a path in the > >>>filesystem. The thing is, it's in the glibj.zip file. There might be a > >>>hack somewhere in the FileInputStream to read from a zip file, but i'm > >>>not aware of it. > >>> > >>> > >>Use java.lang.Class.getResourceAsStream(String) > >> > >> > >> > > > >I didn't know that function. Powerfull! So then, shouldn't the function > >readConfiguration from LogManager make a call like > > > >LogManager.class.getResourceAsStream("java/util/logging/logging.properties"); > > > >to have an InputStream instead of looking for system properties? > > > > > > > >>>Other question : shouldn't the function postInit from > >>>vm/reference/gnu/classpath/VMSystemProperties be native? It's my vm that > >>>reads the commande line that stands before the name of the class to > >>>execute. > >>> > >>> > >>The VM* classes are special to the VM, they may be native but does not has > >>to be. E.g. in JikesRVM and JNode nearly all stuff is implemented in Java > >>itself. So it depends on your VM. > >> > >> > >> > >OK > > > > > > > >>Michael > >> > >> > > > > > > > _______________________________________________ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath