Re: How to handle properties file
On Mon, 2005-05-23 at 10:31 +0200, Mark Wielaard wrote: Hi Nicolas, On Thu, 2005-05-19 at 23:24 +0200, Nicolas Geoffray wrote: 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. I am afraid I have some bad news in that case. sorry. If you want to support our glibj.zip approach then you will need to provide that functionality. VMClassLoader (see vm/reference) depends on the runtime to provide a loadClass() method that reads the glibj.zip file to find the actual class (of provide the classes for the bootstrap classloader in some other way). There is also the VMClassLoader.getResource() and getResource() methods that finds bootstrap classloader resources. we currently provide a default implementation that uses java.util.zip for reading the glibj.zip file, but that is neither efficient (opens a new ZipFile each time) not completely safe (since reading zip files can trigger Date/Calendar calculations which need additional resources, which can get into endless recursion). Maybe we could actually provide the native glibj.zip file reading functionality completely in our vm reference code through zlib. That might not be such a bad idea since almost every runtime will need zlib to load the bootstrap classes and resources. The only trick is to make it flexible enough to be integrated into the various ways runtimes load classes. In fact, I already implemented the native glibj.zip file reading in my vm. It uses zlib but isn't usable for other vms (it's written with a dsl). What i was afraid of, is to take care of the .properties files (or whatever ressources apart form .class files) inside the glibj.zip file. Archie, I believe you said you had such code for JCVM and that you would consider donating that to GNU Classpath for use with other runtimes. If you have and want to could you send that code to the (patches) list? Do other runtime implementers think they would adopt such shared bootstrap class loading code, or is that something that is too wired into the actual runtime to be easy to share in a generic way? Good idea, might be interesting. Cheers, Mark -- Nicolas Geoffray [EMAIL PROTECTED] ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How to handle properties file
Hi Nicolas, On Thu, 2005-05-19 at 23:24 +0200, Nicolas Geoffray wrote: 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. I am afraid I have some bad news in that case. sorry. If you want to support our glibj.zip approach then you will need to provide that functionality. VMClassLoader (see vm/reference) depends on the runtime to provide a loadClass() method that reads the glibj.zip file to find the actual class (of provide the classes for the bootstrap classloader in some other way). There is also the VMClassLoader.getResource() and getResource() methods that finds bootstrap classloader resources. we currently provide a default implementation that uses java.util.zip for reading the glibj.zip file, but that is neither efficient (opens a new ZipFile each time) not completely safe (since reading zip files can trigger Date/Calendar calculations which need additional resources, which can get into endless recursion). Maybe we could actually provide the native glibj.zip file reading functionality completely in our vm reference code through zlib. That might not be such a bad idea since almost every runtime will need zlib to load the bootstrap classes and resources. The only trick is to make it flexible enough to be integrated into the various ways runtimes load classes. Archie, I believe you said you had such code for JCVM and that you would consider donating that to GNU Classpath for use with other runtimes. If you have and want to could you send that code to the (patches) list? Do other runtime implementers think they would adopt such shared bootstrap class loading code, or is that something that is too wired into the actual runtime to be easy to share in a generic way? Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How to handle properties file
Mark Wielaard wrote: Maybe we could actually provide the native glibj.zip file reading functionality completely in our vm reference code through zlib. That might not be such a bad idea since almost every runtime will need zlib to load the bootstrap classes and resources. The only trick is to make it flexible enough to be integrated into the various ways runtimes load classes. Archie, I believe you said you had such code for JCVM and that you would consider donating that to GNU Classpath for use with other runtimes. If you have and want to could you send that code to the (patches) list? Do other runtime implementers think they would adopt such shared bootstrap class loading code, or is that something that is too wired into the actual runtime to be easy to share in a generic way? The ZIP file reader in JC is welcome to anyone to use. It's fairly well self-contained in one file (zip.c) plus structure and macro definitions in structures.h and definitions.h. I believe SableVM is already using it. I'll happy re-license and/or donate to Classpath. However, it doesn't seem appropriate for it to go into Classpath, or at least I'm not sure I understand how it would work exactly, since there is the obvious bootstrap problem with Java binding. The relevant files for perusal... http://cvs.sourceforge.net/viewcvs.py/jcvm/jcvm/libjc/zip.c http://cvs.sourceforge.net/viewcvs.py/jcvm/jcvm/libjc/definitions.h http://cvs.sourceforge.net/viewcvs.py/jcvm/jcvm/libjc/structures.h -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How to handle properties file
Archie == Archie Cobbs [EMAIL PROTECTED] writes: Archie However, it doesn't seem appropriate for it to go into Classpath, Archie or at least I'm not sure I understand how it would work exactly, Archie since there is the obvious bootstrap problem with Java binding. I think if we have pieces of code that are usable by a number of VMs, Classpath would make a good clearinghouse for them, whether they are written in C or Java or whatever. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How to handle properties file
Tom Tromey wrote: Archie However, it doesn't seem appropriate for it to go into Classpath, Archie or at least I'm not sure I understand how it would work exactly, Archie since there is the obvious bootstrap problem with Java binding. I think if we have pieces of code that are usable by a number of VMs, Classpath would make a good clearinghouse for them, whether they are written in C or Java or whatever. Perhaps we can install a /usr/local/lib/classpath/libzipjar.so or whatever shared library. Then VM's can link to it (or dlopen() it) if they please... we'll also need a header file. I don't have time to do this right now (I'm slow when it comes to automake, etc.) but can help get the source files ready for import, etc. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How to handle properties file
On Fri, May 20, 2005 at 07:46:05AM +0200, Nicolas Geoffray wrote: On Fri, 2005-05-20 at 06:40 +0200, Michael Koch wrote: On Thu, May 19, 2005 at 11:24:16PM +0200, Nicolas Geoffray wrote: 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. Now I understand your original request. Sorry for my stupidity. No, not all *.properties files have to be outside of glibj.zip. E.g. we use property files to define locale data. These need to be still inside glibj.zip. Others should be outside to be editable by the administrator of the GNU classpath installation. Can you please file a No problem Michael, maybe i wasn't clear enough. So these property files inside the glibj.zip, who (the java application? gnu classpath? the vm?) handles it? GNU classpath has to handle them. The VM should not need to handle them. This would be them same work for each VM. We can generalize this easy in GNU classpath. bug report for this? Robert Schuster has. Cool. Cu Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
How to handle properties file
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. 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. Thanks in advance for any replies -- Nicolas Geoffray [EMAIL PROTECTED] ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How to handle properties file
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) 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. Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How to handle properties file
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 -- Nicolas Geoffray [EMAIL PROTECTED] ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How to handle properties file
On Thu, May 19, 2005 at 08:39:12PM +0200, 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? Use java.util.Properties.load(InputStream) with it. Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How to handle properties file
Michael Koch wrote: 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? Use java.util.Properties.load(InputStream) with it. I think people are missing Nicolas' point here. The class LogManager is broken, because it is looking in the wrong place for the properties file. Does anyone know what the correct behavior is supposed to be? -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How to handle properties file
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... -- 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
Re: How to handle properties file
On Thu, 2005-05-19 at 14:50 -0500, Archie Cobbs wrote: Michael Koch wrote: 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? Use java.util.Properties.load(InputStream) with it. Yes, this is what is done in the java.util.logging.LogManager.readconfiguration(InputStream). The thing is, i'm a vm implementor (not written in java) using the gnu classpath. So when a call to LogManager.readConfiguration is made in a java application, the ressource is not found. I can't use any of the functions you're pointing me, because i'm not the application, just the vm. I think people are missing Nicolas' point here. The class LogManager is broken, because it is looking in the wrong place for the properties file. Yes, that's it Archie. Does anyone know what the correct behavior is supposed to be? -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How to handle properties file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I think people are missing Nicolas' point here. The class LogManager is broken, because it is looking in the wrong place for the properties file. Does anyone know what the correct behavior is supposed to be? A certain Jay-too-es-ee implementation loads it's logger configuration property file directly from the filesystem (at least it is stored there). I think this is what is intended to be emulated here. Due to certain packaging problems this would not work anyway on my distribution but this is a separate issue. A real problem is that our logging.properties file lives in java/util/logging inside the glibj.zip or more correctly: it is part of our system class path (remember that zipping the class library is an optional step) and the code is simply not correct. Maybe that is the reason for nicolas' initial problem. I file a bug for this. Thanks nicolas ;) cu Robert -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCjRfvG9cfwmwwEtoRAirNAJ9Zq1uff4DgTvt+Izu042Pfkb5zIwCcCe0W i4FsnhCOWAMFCTu0stJHCGQ= =k4X7 -END PGP SIGNATURE- ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How to handle properties file
On Thu, May 19, 2005 at 11:24:16PM +0200, Nicolas Geoffray wrote: 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. Now I understand your original request. Sorry for my stupidity. No, not all *.properties files have to be outside of glibj.zip. E.g. we use property files to define locale data. These need to be still inside glibj.zip. Others should be outside to be editable by the administrator of the GNU classpath installation. Can you please file a bug report for this? Thanks, Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How to handle properties file
On Fri, 2005-05-20 at 00:49 +0200, Robert Schuster wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I think people are missing Nicolas' point here. The class LogManager is broken, because it is looking in the wrong place for the properties file. Does anyone know what the correct behavior is supposed to be? A certain Jay-too-es-ee implementation loads it's logger configuration property file directly from the filesystem (at least it is stored there). I think this is what is intended to be emulated here. Due to certain packaging problems this would not work anyway on my distribution but this is a separate issue. A real problem is that our logging.properties file lives in java/util/logging inside the glibj.zip or more correctly: it is part of our system class path (remember that zipping the class library is an optional step) and the code is simply not correct. Maybe that is the reason for nicolas' initial problem. I file a bug for this. Thanks nicolas ;) OK, thx Robert for clearing up the situation, and for the bug report. cu Robert -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCjRfvG9cfwmwwEtoRAirNAJ9Zq1uff4DgTvt+Izu042Pfkb5zIwCcCe0W i4FsnhCOWAMFCTu0stJHCGQ= =k4X7 -END PGP SIGNATURE- ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath -- Nicolas Geoffray [EMAIL PROTECTED] ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How to handle properties file
On Fri, 2005-05-20 at 06:40 +0200, Michael Koch wrote: On Thu, May 19, 2005 at 11:24:16PM +0200, Nicolas Geoffray wrote: 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. Now I understand your original request. Sorry for my stupidity. No, not all *.properties files have to be outside of glibj.zip. E.g. we use property files to define locale data. These need to be still inside glibj.zip. Others should be outside to be editable by the administrator of the GNU classpath installation. Can you please file a No problem Michael, maybe i wasn't clear enough. So these property files inside the glibj.zip, who (the java application? gnu classpath? the vm?) handles it? bug report for this? Robert Schuster has. Thanks, Michael ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
