Re: [cp-patches] [GNU ClassPath] porting the GTK+3 AWT support
added AM_CFLAGS Macro Line 62: -DGTK_DISABLE_SINGLE_INCLUDES * native/jni/gtk-peer/gnu_java_awt_peer_gtk_CairoGraphics2D.c Changed includes Line 42: #include gdk/gdktypes.h to #include gdk/gdk.h Line 43: #include gdk/gdkprivate.h to #include gdk/gdkx.h * native/jni/gtk-peer/gnu_java_awt_peer_gtk_ComponentGraphics.c Changed includes Line 41: #include gdk/gdktypes.h to #include gdk/gdk.h Line 44: #include gdk/gdkprivate.h to #include gdk/gdkx.h * native/jni/gtk-peer/gnu_java_awt_peer_gtk_ComponentGraphicsCopy.c Changed includes Line 41: #include gdk/gdktypes.h to #include gdk/gdk.h Line 44: #include gdk/gdkprivate.h to #include gdk/gdkx.h * native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkComponentPeer.c Changed includes Line 43: #include gtk/gtkprivate.h to #include gtk/gtk.h * native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkVolatileImage.c Changed includes Line 42: #include gdk/gdktypes.h to #include gdk/gdk.h Line 45: #include gdk/gdkprivate.h to #include gdk/gdkx.h From: Andrew Hughes [gnu.and...@redhat.com] Sent: Friday, May 31, 2013 4:22 AM To: Farshad Muhammad Cc: classpath-patches@gnu.org Subject: Re: [cp-patches] [GNU ClassPath] porting the GTK+3 AWT support - Original Message - Hey guys, My name is Farshad Muhammad and i've recently been accepted to GSoC 2013. I will be working to port GTK+3 AWT support for the gtk-peer in the classpath following a migration guide provided here: https://developer.gnome.org/gtk3/3.5/gtk-migrating-2-to-3.html The porting process requires the classpath first to be prepared under GTK + 2.24 and built under certain CFLAG macros. I have successfully resolved one of the macros which require there to be no single includes in the gtk-peer of the classpath. The classpath now builds successfully using the command : make CFLAGS+=-DGTK_DISABLE_SINGLE_INCLUDES Here is a list of changes I had to make to achieve this: LOG FOR SINGLE INCLUDE CHANGES: gtk_CairoGraphics2D.c Line 42: #include gdk/gdktypes.h to #include gdk/gdk.h Line 43: #include gdk/gdkprivate.h to #include gdk/gdkx.h gtk_ComponentGraphics.c Line 41: #include gdk/gdktypes.h to #include gdk/gdk.h Line 44: #include gdk/gdkprivate.h to #include gdk/gdkx.h gtk_ComponentGraphicsCopy.c Line 41: #include gdk/gdktypes.h to #include gdk/gdk.h Line 44: #include gdk/gdkprivate.h to #include gdk/gdkx.h gtk_ComponentPeer.c Line 43: #include gtk/gtkprivate.h to #include gtk/gtk.h gtk_VolatileImage.c Line 42: #include gdk/gdktypes.h to #include gdk/gdk.h Line 45: #include gdk/gdkprivate.h to #include gdk/gdkx.h I would like to commit these changes as a classpath patch. Hi Farshad, First of all, welcome to the project and I hope you enjoy working with us for Google's Summer of Code. For your patch, you should attach the output of 'git diff' to your mail. You also need to make the CFLAGS change permanent in the Makefile.am. Each change also needs a ChangeLog entry. You can look in the file ChangeLog for examples and add yours there. Include the entry in the mail but not as part of the attached patch (though it should be part of the final commit), as this makes it easier for others to apply and test your patch. Thanks and congratulations on your first contribution! -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
Re: [cp-patches] [GNU ClassPath] porting the GTK+3 AWT support
- Original Message - Hey guys, My name is Farshad Muhammad and i've recently been accepted to GSoC 2013. I will be working to port GTK+3 AWT support for the gtk-peer in the classpath following a migration guide provided here: https://developer.gnome.org/gtk3/3.5/gtk-migrating-2-to-3.html The porting process requires the classpath first to be prepared under GTK + 2.24 and built under certain CFLAG macros. I have successfully resolved one of the macros which require there to be no single includes in the gtk-peer of the classpath. The classpath now builds successfully using the command : make CFLAGS+=-DGTK_DISABLE_SINGLE_INCLUDES Here is a list of changes I had to make to achieve this: LOG FOR SINGLE INCLUDE CHANGES: gtk_CairoGraphics2D.c Line 42: #include gdk/gdktypes.h to #include gdk/gdk.h Line 43: #include gdk/gdkprivate.h to #include gdk/gdkx.h gtk_ComponentGraphics.c Line 41: #include gdk/gdktypes.h to #include gdk/gdk.h Line 44: #include gdk/gdkprivate.h to #include gdk/gdkx.h gtk_ComponentGraphicsCopy.c Line 41: #include gdk/gdktypes.h to #include gdk/gdk.h Line 44: #include gdk/gdkprivate.h to #include gdk/gdkx.h gtk_ComponentPeer.c Line 43: #include gtk/gtkprivate.h to #include gtk/gtk.h gtk_VolatileImage.c Line 42: #include gdk/gdktypes.h to #include gdk/gdk.h Line 45: #include gdk/gdkprivate.h to #include gdk/gdkx.h I would like to commit these changes as a classpath patch. Hi Farshad, First of all, welcome to the project and I hope you enjoy working with us for Google's Summer of Code. For your patch, you should attach the output of 'git diff' to your mail. You also need to make the CFLAGS change permanent in the Makefile.am. Each change also needs a ChangeLog entry. You can look in the file ChangeLog for examples and add yours there. Include the entry in the mail but not as part of the attached patch (though it should be part of the final commit), as this makes it easier for others to apply and test your patch. Thanks and congratulations on your first contribution! -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
Re: [cp-patches] [GNU ClassPath] porting the GTK+3 AWT support
/jni/gtk-peer/gnu_java_awt_peer_gtk_ComponentGraphicsCopy.c Changed includes Line 41: #include gdk/gdktypes.h to #include gdk/gdk.h Line 44: #include gdk/gdkprivate.h to #include gdk/gdkx.h * native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkComponentPeer.c Changed includes Line 43: #include gtk/gtkprivate.h to #include gtk/gtk.h * native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkVolatileImage.c Changed includes Line 42: #include gdk/gdktypes.h to #include gdk/gdk.h Line 45: #include gdk/gdkprivate.h to #include gdk/gdkx.h From: Andrew Hughes [gnu.and...@redhat.com] Sent: Friday, May 31, 2013 4:22 AM To: Farshad Muhammad Cc: classpath-patches@gnu.org Subject: Re: [cp-patches] [GNU ClassPath] porting the GTK+3 AWT support - Original Message - Hey guys, My name is Farshad Muhammad and i've recently been accepted to GSoC 2013. I will be working to port GTK+3 AWT support for the gtk-peer in the classpath following a migration guide provided here: https://developer.gnome.org/gtk3/3.5/gtk-migrating-2-to-3.html The porting process requires the classpath first to be prepared under GTK + 2.24 and built under certain CFLAG macros. I have successfully resolved one of the macros which require there to be no single includes in the gtk-peer of the classpath. The classpath now builds successfully using the command : make CFLAGS+=-DGTK_DISABLE_SINGLE_INCLUDES Here is a list of changes I had to make to achieve this: LOG FOR SINGLE INCLUDE CHANGES: gtk_CairoGraphics2D.c Line 42: #include gdk/gdktypes.h to #include gdk/gdk.h Line 43: #include gdk/gdkprivate.h to #include gdk/gdkx.h gtk_ComponentGraphics.c Line 41: #include gdk/gdktypes.h to #include gdk/gdk.h Line 44: #include gdk/gdkprivate.h to #include gdk/gdkx.h gtk_ComponentGraphicsCopy.c Line 41: #include gdk/gdktypes.h to #include gdk/gdk.h Line 44: #include gdk/gdkprivate.h to #include gdk/gdkx.h gtk_ComponentPeer.c Line 43: #include gtk/gtkprivate.h to #include gtk/gtk.h gtk_VolatileImage.c Line 42: #include gdk/gdktypes.h to #include gdk/gdk.h Line 45: #include gdk/gdkprivate.h to #include gdk/gdkx.h I would like to commit these changes as a classpath patch. Hi Farshad, First of all, welcome to the project and I hope you enjoy working with us for Google's Summer of Code. For your patch, you should attach the output of 'git diff' to your mail. You also need to make the CFLAGS change permanent in the Makefile.am. Each change also needs a ChangeLog entry. You can look in the file ChangeLog for examples and add yours there. Include the entry in the mail but not as part of the attached patch (though it should be part of the final commit), as this makes it easier for others to apply and test your patch. Thanks and congratulations on your first contribution! -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
Re: [cp-patches] GNU Classpath
On 10/20/2012 10:03 AM, Chris Burdess wrote: Mario Torre wrote: No. Updating the ChangeLog is a requirement. Maybe it's a requirement, but to be honest, is also a very redundant piece of information that is already in the commit log, The commit log is not part of the package. People may want to download the package and see who the contributors were and when; the ChangeLog is a long established convention for them to do this. Exactly. It makes no sense to make such a process change at this point in Classpath's history. We have always been able, in theory, to build the ChangeLog from the commit log. Nothing in this respect has changed. It's not a very onerous requirement. Andrew.
Re: [cp-patches] GNU Classpath
Mario Torre wrote: No. Updating the ChangeLog is a requirement. Maybe it's a requirement, but to be honest, is also a very redundant piece of information that is already in the commit log, The commit log is not part of the package. People may want to download the package and see who the contributors were and when; the ChangeLog is a long established convention for them to do this.
Re: [cp-patches] GNU Classpath
Am Samstag, den 20.10.2012, 10:03 +0100 schrieb Chris Burdess: Mario Torre wrote: No. Updating the ChangeLog is a requirement. Maybe it's a requirement, but to be honest, is also a very redundant piece of information that is already in the commit log, The commit log is not part of the package. People may want to download the package and see who the contributors were and when; the ChangeLog is a long established convention for them to do this. I don't get it. All of the information of the Changelog is also in the commit history, and if it isn't, it's only a matter of convention to put it there. Then, when doing a release, it should be a matter of a simple script to create a ChangeLog in whatever format is required and put it in the package (I am sure there are existing scripts that accomplish exactly this out there). *All* of it can be automated, and it makes branching, merging, etc much easier, especially in the face of distributed VCSs. Roman
Re: [cp-patches] GNU Classpath
Roman Kennke wrote: Am Samstag, den 20.10.2012, 10:03 +0100 schrieb Chris Burdess: Mario Torre wrote: No. Updating the ChangeLog is a requirement. Maybe it's a requirement, but to be honest, is also a very redundant piece of information that is already in the commit log, The commit log is not part of the package. People may want to download the package and see who the contributors were and when; the ChangeLog is a long established convention for them to do this. I don't get it. All of the information of the Changelog is also in the commit history, and if it isn't, it's only a matter of convention to put it there. Then, when doing a release, it should be a matter of a simple script to create a ChangeLog in whatever format is required and put it in the package (I am sure there are existing scripts that accomplish exactly this out there). *All* of it can be automated, and it makes branching, merging, etc much easier, especially in the face of distributed VCSs. I am agnostic on the issue of how the ChangeLog is maintained, only that it should be present and maintained. It is not reasonable to expect a user, having downloaded a GNU package, to have to search around the Web to find the development project resources, download and install configuration management systems with which they may not be familiar, etc etc, simply to see what changes have been made since the last version.
Re: [cp-patches] GNU Classpath
On Oct 20, 2012, at 5:04 AM, Chris Burdess d...@bluezoo.org wrote: Mario Torre wrote: No. Updating the ChangeLog is a requirement. Maybe it's a requirement, but to be honest, is also a very redundant piece of information that is already in the commit log, The commit log is not part of the package. People may want to download the package and see who the contributors were and when; the ChangeLog is a long established convention for them to do this. We did maintain the ChangeLog using commits originally and a script to suck them out and generate a file, but at some point we went to keeping a file instead, because it did not require a script. I suggest those merging changes into trunk/master have the ultimate responsibility regarding ensuring the ChangeLog is up to date and since it cannot be auto merged perhaps do not make changes to it except when merging to the release and trunk/master branches. As an aside I always found it easier to maintain my own ChangeLog entries in a separate file and only when committing upstream to add them to the project's file. Brian
Re: [cp-patches] GNU Classpath
Hi Andrew, Wed, 17 Oct 2012 09:45:40 +0300 от Pekka Enberg penb...@kernel.org: On Wed, Oct 17, 2012 at 5:59 AM, Andrew Hughes gnu.and...@redhat.com wrote: No. Updating the ChangeLog is a requirement. GNU Coding Standards 6.8.1 Change Log Concepts ... Another alternative is to record change log information with a version control system such as RCS or CVS. ... Ivan, I highly recommend setting up git-merge-changelog as per Mark's instructions which makes git merge and git cherry-pick work properly again. Ok. Thanks. Regards, Ivan
Re: [cp-patches] GNU Classpath
Il giorno 17/ott/2012, alle ore 04:59, Andrew Hughes gnu.and...@redhat.com ha scritto: - Original Message - Hi team, There could be another way if we can't drop old-style ChangeLog for some reason: do not alter ChangeLog (i.e. use commit log instead) until the patch is fully accepted (e.g., Andrew could get log notes (one or even several) from git log of processed patches (of master savannah/master) and update ChangeLog (as a separate commit). No magic, just deferred update. No. Updating the ChangeLog is a requirement. Hi Andrew. Maybe it's a requirement, but to be honest, is also a very redundant piece of information that is already in the commit log, so I for one would like to see this going away. In Thermostat we add the review thread of the mailing list to keep better track of the actual history of the patch (something that doesn't really show up in the Changelog anyway), which proves to be more useful that duplicating the Changelog info. Cheers, Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/
Re: [cp-patches] GNU Classpath
On Wed, Oct 17, 2012 at 5:59 AM, Andrew Hughes gnu.and...@redhat.com wrote: No. Updating the ChangeLog is a requirement. Ivan, I highly recommend setting up git-merge-changelog as per Mark's instructions which makes git merge and git cherry-pick work properly again.
Re: [cp-patches] GNU Classpath
Hi team, There could be another way if we can't drop old-style ChangeLog for some reason: do not alter ChangeLog (i.e. use commit log instead) until the patch is fully accepted (e.g., Andrew could get log notes (one or even several) from git log of processed patches (of master savannah/master) and update ChangeLog (as a separate commit). No magic, just deferred update. Regards, Ivan Mon, 15 Oct 2012 09:31:59 +0300 от Pekka Enberg penb...@kernel.org: On Sun, Oct 14, 2012 at 11:55 PM, Andrew Hughes gnu.and...@redhat.com wrote: May be it's time to change the policy of patch acceptance from please find a person who reviews (among 1 or 2 guys) your code to if signed FSF paper, and you have patches, post them to ML, commit to some feature development branch and, if no objections within 2-3 weeks, merge the branch to master, in case of further objections revert the patches. No, I don't think this is suitable. And more importantly, not really necessary now that we're using Git. That said, we really need to do something with ChangeLog because it causes unnecessary rejects when merging from one git tree to another. Can we drop it or did someone have some Git magic to deal with it? Pekka
Re: [cp-patches] GNU Classpath
- Original Message - Hi team, There could be another way if we can't drop old-style ChangeLog for some reason: do not alter ChangeLog (i.e. use commit log instead) until the patch is fully accepted (e.g., Andrew could get log notes (one or even several) from git log of processed patches (of master savannah/master) and update ChangeLog (as a separate commit). No magic, just deferred update. No. Updating the ChangeLog is a requirement. Regards, Ivan Mon, 15 Oct 2012 09:31:59 +0300 от Pekka Enberg penb...@kernel.org: On Sun, Oct 14, 2012 at 11:55 PM, Andrew Hughes gnu.and...@redhat.com wrote: May be it's time to change the policy of patch acceptance from please find a person who reviews (among 1 or 2 guys) your code to if signed FSF paper, and you have patches, post them to ML, commit to some feature development branch and, if no objections within 2-3 weeks, merge the branch to master, in case of further objections revert the patches. No, I don't think this is suitable. And more importantly, not really necessary now that we're using Git. That said, we really need to do something with ChangeLog because it causes unnecessary rejects when merging from one git tree to another. Can we drop it or did someone have some Git magic to deal with it? Pekka -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
Re: [cp-patches] GNU Classpath
On Sun, Oct 14, 2012 at 11:55 PM, Andrew Hughes gnu.and...@redhat.com wrote: May be it's time to change the policy of patch acceptance from please find a person who reviews (among 1 or 2 guys) your code to if signed FSF paper, and you have patches, post them to ML, commit to some feature development branch and, if no objections within 2-3 weeks, merge the branch to master, in case of further objections revert the patches. No, I don't think this is suitable. And more importantly, not really necessary now that we're using Git. That said, we really need to do something with ChangeLog because it causes unnecessary rejects when merging from one git tree to another. Can we drop it or did someone have some Git magic to deal with it? Pekka
Re: [cp-patches] GNU Classpath
On 10/13/2012 02:50 AM, Ivan Maidanski wrote: May be it's time to change the policy of patch acceptance from please find a person who reviews (among 1 or 2 guys) your code to if signed FSF paper, and you have patches, post them to ML, commit to some feature development branch and, if no objections within 2-3 weeks, merge the branch to master, in case of further objections revert the patches. Sorry about that. There are quite a few people who can review patches, but we might need prompting. No reason why you shouldn't review patches too, but you should still have someone else look at them. It is true that it's better to accept a patch that looks basically OK than hold it back because no-one has time to go through it line-by-line. Please post a summary mail of the patches. Andrew.
Re: [cp-patches] Gnu classpath permission patch ?
Il giorno sab, 26/05/2007 alle 11.45 +0200, Pierre Parrend ha scritto: Hello, Gnu classpath version is the 0.9.3 (on my machine the 0.9.5 compilation quickly ends with a StackOverflowError) Try add -Xmx512m to the compiler settings, this should make you able to compile it. Thanks, Mario -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Jabber: [EMAIL PROTECTED] - Profile: http://www.gtalkprofile.com/profile/9661.html pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Re: [cp-patches] Gnu classpath permission patch ?
Hello,
thanks for the tip, to tell the Classes to use the right policy reader
is usefull. However, I now get a ugly NullPointerException in policy
reading, it seems that the given reader has problem reading the name
of the ProtectionDomain:
java.lang.ExceptionInInitializerError
at
gnu.java.security.x509.X509Certificate.toString(X509Certificate.java:455)
at java.lang.StringBuffer.append(StringBuffer.java:348)
at java.security.CodeSource.toString(CodeSource.java:269)
at java.lang.StringBuffer.append(StringBuffer.java:348)
at java.security.ProtectionDomain.toString(ProtectionDomain.java:212)
at java.lang.StringBuffer.append(StringBuffer.java:348)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:157)
at java.security.AccessController.checkPermission(AccessController.java:76)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:356)
at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:820)
at java.lang.System.getProperty(System.java:397)
at org.apache.felix.main.Main.clinit(Main.java:66)
Caused by: java.lang.NullPointerException
at java.io.PrintWriter.println(PrintWriter.java:395)
at java.io.PrintWriter.println(PrintWriter.java:523)
at
gnu.java.security.x509.X509Certificate.toString(X509Certificate.java:456)
at java.lang.StringBuffer.append(StringBuffer.java:348)
at java.security.CodeSource.toString(CodeSource.java:269)
at java.lang.StringBuffer.append(StringBuffer.java:348)
at java.security.ProtectionDomain.toString(ProtectionDomain.java:212)
at java.lang.StringBuffer.append(StringBuffer.java:348)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:157)
at java.security.AccessController.checkPermission(AccessController.java:76)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:356)
at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:820)
at java.lang.System.getProperty(System.java:418)
at java.io.PrintWriter.clinit(PrintWriter.java:381)
at
gnu.java.security.x509.X509Certificate.toString(X509Certificate.java:455)
Quoting Casey Marshall [EMAIL PROTECTED]:
On May 24, 2007, at 1:58 PM, Pierre Parrend wrote:
Hello,
for instance, I have the following command:
jamvm -Djava.security.manager -Djava.security.policy=conf/java.policy -cp
bin/felix.jar: org.apache.felix.main.Main
(jamvm uses the Gnu classpath, with default configuration)
with following conf/java.policy file:
grant codeBase /code/osgi-projects/sfelix/sfelix0.2.2/main/- {
permission java.io.FilePermission
/home/pierre/.felix/testSF, read;
permission java.lang.RuntimePermission exitVM;
};
which gives me following error:
Error creating bundle cache:
permission (java.io.FilePermission /home/pierre/.felix/testSF read)
not granted:
no protection domains
Could not create framework: java.security.AccessControlException: permission
(java.lang.RuntimePermission exitVM ) not granted: no protection domains
java.security.AccessControlException: permission
(java.lang.RuntimePermission
exitVM ) not granted: no protection domains
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:149)
at
java.security.AccessController.checkPermission(AccessController.java:76)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:356)
at java.lang.SecurityManager.checkExit(SecurityManager.java:475)
at java.lang.Runtime.exit(Runtime.java:171)
at java.lang.System.exit(System.java:506)
at
org.apache.felix.framework.util.SecureAction$Actions.run(SecureAction.java:843)
at java.security.AccessController.doPrivileged(AccessController.java:195)
at
org.apache.felix.framework.util.SecureAction.exit(SecureAction.java:624)
at org.apache.felix.framework.Felix.start(Felix.java:276)
at org.apache.felix.main.Main.main(Main.java:208)
(executed platform is the Felix OSGi implementation, which work
well without the
security set)
One problem here is that Classpath still unfortunately uses a bogus
DefaultPolicy class for its policy, not the one that reads policy
files. You can force using the policy file reader by adding the option:
-Dpolicy.provider=gnu.java.security.PolicyFile
...I don't know why the default policy would reject the permission
checks, though, since (AFAIK) the default policy grants AllPermission.
Re: [cp-patches] Gnu classpath permission patch ?
On May 25, 2007, at 12:37 AM, Pierre Parrend wrote:
Hello,
thanks for the tip, to tell the Classes to use the right policy
reader is usefull. However, I now get a ugly NullPointerException
in policy reading, it seems that the given reader has problem
reading the name of the ProtectionDomain:
Hmm, no, this looks more like a problem with recursive permission
checks; that is, something needs to have a permission checked while
it's checking a permission. It also looks like Classpath will
eventually deny the permission your code is requesting.
This is a little odd, because it looks like Classpath internal code
is being denied a permission. That's wrong; library code should be
able to do what it pleases.
This feels like a regression. What version of Classpath and jamvm are
you using?
Thanks.
java.lang.ExceptionInInitializerError
at gnu.java.security.x509.X509Certificate.toString
(X509Certificate.java:455)
at java.lang.StringBuffer.append(StringBuffer.java:348)
at java.security.CodeSource.toString(CodeSource.java:269)
at java.lang.StringBuffer.append(StringBuffer.java:348)
at java.security.ProtectionDomain.toString(ProtectionDomain.java:
212)
at java.lang.StringBuffer.append(StringBuffer.java:348)
at java.security.AccessControlContext.checkPermission
(AccessControlContext.java:157)
at java.security.AccessController.checkPermission
(AccessController.java:76)
at java.lang.SecurityManager.checkPermission
(SecurityManager.java:356)
at java.lang.SecurityManager.checkPropertyAccess
(SecurityManager.java:820)
at java.lang.System.getProperty(System.java:397)
at org.apache.felix.main.Main.clinit(Main.java:66)
Caused by: java.lang.NullPointerException
at java.io.PrintWriter.println(PrintWriter.java:395)
at java.io.PrintWriter.println(PrintWriter.java:523)
at gnu.java.security.x509.X509Certificate.toString
(X509Certificate.java:456)
at java.lang.StringBuffer.append(StringBuffer.java:348)
at java.security.CodeSource.toString(CodeSource.java:269)
at java.lang.StringBuffer.append(StringBuffer.java:348)
at java.security.ProtectionDomain.toString(ProtectionDomain.java:
212)
at java.lang.StringBuffer.append(StringBuffer.java:348)
at java.security.AccessControlContext.checkPermission
(AccessControlContext.java:157)
at java.security.AccessController.checkPermission
(AccessController.java:76)
at java.lang.SecurityManager.checkPermission
(SecurityManager.java:356)
at java.lang.SecurityManager.checkPropertyAccess
(SecurityManager.java:820)
at java.lang.System.getProperty(System.java:418)
at java.io.PrintWriter.clinit(PrintWriter.java:381)
at gnu.java.security.x509.X509Certificate.toString
(X509Certificate.java:455)
Quoting Casey Marshall [EMAIL PROTECTED]:
On May 24, 2007, at 1:58 PM, Pierre Parrend wrote:
Hello,
for instance, I have the following command:
jamvm -Djava.security.manager -Djava.security.policy=conf/
java.policy -cp
bin/felix.jar: org.apache.felix.main.Main
(jamvm uses the Gnu classpath, with default configuration)
with following conf/java.policy file:
grant codeBase /code/osgi-projects/sfelix/sfelix0.2.2/main/- {
permission java.io.FilePermission /home/pierre/.felix/
testSF, read;
permission java.lang.RuntimePermission exitVM;
};
which gives me following error:
Error creating bundle cache:
permission (java.io.FilePermission /home/pierre/.felix/testSF
read) not granted:
no protection domains
Could not create framework: java.security.AccessControlException:
permission
(java.lang.RuntimePermission exitVM ) not granted: no protection
domains
java.security.AccessControlException: permission
(java.lang.RuntimePermission
exitVM ) not granted: no protection domains
at
java.security.AccessControlContext.checkPermission
(AccessControlContext.java:149)
at java.security.AccessController.checkPermission
(AccessController.java:76)
at java.lang.SecurityManager.checkPermission
(SecurityManager.java:356)
at java.lang.SecurityManager.checkExit(SecurityManager.java:475)
at java.lang.Runtime.exit(Runtime.java:171)
at java.lang.System.exit(System.java:506)
at
org.apache.felix.framework.util.SecureAction$Actions.run
(SecureAction.java:843)
at java.security.AccessController.doPrivileged
(AccessController.java:195)
at org.apache.felix.framework.util.SecureAction.exit
(SecureAction.java:624)
at org.apache.felix.framework.Felix.start(Felix.java:276)
at org.apache.felix.main.Main.main(Main.java:208)
(executed platform is the Felix OSGi implementation, which work
well without the
security set)
One problem here is that Classpath still unfortunately uses a bogus
DefaultPolicy class for its policy, not the one that reads policy
files. You can force using the policy file reader by adding the
option:
-Dpolicy.provider=gnu.java.security.PolicyFile
...I don't know why the default policy would reject the permission
checks,
Re: [cp-patches] Gnu classpath permission patch ?
Hello, in a different test context, it works. But I do not manage to get the java.policy file read, so my code aborts very soon. Does someone knows whether the supported syntax of this file is identical as in the sun jvm ? It seems that jamvm+Gnu Classpath has some difficulties in reading the properties that are defined (such a -Djava.security.policy). Any idea ? Pierre Quoting David Daney [EMAIL PROTECTED]: Pierre Parrend wrote: Hello, I am looking for a small and efficient java class project to program secure java application. The Gnu Classpath seems to be very efficient, but there seem to be no java permission support. Is there some specific patch that would already be available ? Are you sure? The last time I checked (about 30 seconds ago), there were quite a few Permission checks. You can grep the source code for the strings checkPermission checkRead, etc. to see that there are several places were we do the checks. Is there a particular place that you believe a check is missing? David Daney -- Pierre Parrend doctorant, moniteur laboratoire CITI, 21, Av. Jean Capelle 69621 Villeurbanne Cedex [EMAIL PROTECTED] www.rzo.free.fr
Re: [cp-patches] Gnu classpath permission patch ?
On May 24, 2007, at 11:03 AM, Pierre Parrend wrote: Hello, in a different test context, it works. But I do not manage to get the java.policy file read, so my code aborts very soon. Does someone knows whether the supported syntax of this file is identical as in the sun jvm ? It seems that jamvm+Gnu Classpath has some difficulties in reading the properties that are defined (such a - Djava.security.policy). Any idea ? We do have a Policy implementation that reads Sun-style policy files, but we don't know if it is 100% compatible. If there is something we don't correctly support, I'd encourage you to file a bug report. We can't offer any more help unless you can be more specific about what error you are running into.
Re: [cp-patches] Gnu classpath permission patch ?
On May 24, 2007, at 1:58 PM, Pierre Parrend wrote:
Hello,
for instance, I have the following command:
jamvm -Djava.security.manager -Djava.security.policy=conf/
java.policy -cp
bin/felix.jar: org.apache.felix.main.Main
(jamvm uses the Gnu classpath, with default configuration)
with following conf/java.policy file:
grant codeBase /code/osgi-projects/sfelix/sfelix0.2.2/main/- {
permission java.io.FilePermission /home/pierre/.felix/
testSF, read;
permission java.lang.RuntimePermission exitVM;
};
which gives me following error:
Error creating bundle cache:
permission (java.io.FilePermission /home/pierre/.felix/testSF read)
not granted:
no protection domains
Could not create framework: java.security.AccessControlException:
permission
(java.lang.RuntimePermission exitVM ) not granted: no protection
domains
java.security.AccessControlException: permission
(java.lang.RuntimePermission
exitVM ) not granted: no protection domains
at
java.security.AccessControlContext.checkPermission
(AccessControlContext.java:149)
at java.security.AccessController.checkPermission
(AccessController.java:76)
at java.lang.SecurityManager.checkPermission
(SecurityManager.java:356)
at java.lang.SecurityManager.checkExit(SecurityManager.java:475)
at java.lang.Runtime.exit(Runtime.java:171)
at java.lang.System.exit(System.java:506)
at
org.apache.felix.framework.util.SecureAction$Actions.run
(SecureAction.java:843)
at java.security.AccessController.doPrivileged
(AccessController.java:195)
at org.apache.felix.framework.util.SecureAction.exit
(SecureAction.java:624)
at org.apache.felix.framework.Felix.start(Felix.java:276)
at org.apache.felix.main.Main.main(Main.java:208)
(executed platform is the Felix OSGi implementation, which work
well without the
security set)
One problem here is that Classpath still unfortunately uses a bogus
DefaultPolicy class for its policy, not the one that reads policy
files. You can force using the policy file reader by adding the option:
-Dpolicy.provider=gnu.java.security.PolicyFile
...I don't know why the default policy would reject the permission
checks, though, since (AFAIK) the default policy grants AllPermission.
Re: [cp-patches] Gnu classpath permission patch ?
Pierre Parrend wrote: Hello, I am looking for a small and efficient java class project to program secure java application. The Gnu Classpath seems to be very efficient, but there seem to be no java permission support. Is there some specific patch that would already be available ? Are you sure? The last time I checked (about 30 seconds ago), there were quite a few Permission checks. You can grep the source code for the strings checkPermission checkRead, etc. to see that there are several places were we do the checks. Is there a particular place that you believe a check is missing? David Daney
