I think it is pretty clear that permission classes must have a public
constructor that is either empty or takes one or two strings. This is
effectively required by the Java policy file grant format:
grant {
permission java.io.FilePermission "C:\\users\\cathy\\foo.bat",
"read";
};
and by the OSGi spec:
permissions ::= ( ’(’ qname (quoted-string quoted-string?)? ’)’ )+
If your permission classes do not conform to this convention, how do you
create PermissionInfos for them? (Of course we are discussing
PermissionInfoCollection which maps PermissionInfos into a
PermissionCollection.)
You seem to be proposing something rather large which is a replacement of
the PermissionInfo encoded format [1] which is the serialized form of
permissions in the OSGi spec.
What do the constructors look like on your permissions?
[1]
http://www.osgi.org/javadoc/r5/core/org/osgi/service/permissionadmin/PermissionInfo.html#getEncoded%28%29
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[email protected]
office: +1 386 848 1781
mobile: +1 386 848 3788
From: Raymond Auge <[email protected]>
To: Equinox development mailing list <[email protected]>
Date: 2013/04/18 11:23
Subject: Re: [equinox-dev] PermissionInfoCollection issues with
perms cloning
Sent by: [email protected]
Hey guys, thanks for responding.
Forgive me for using the work "clone" (however, it really should be a
clone in my mind, the base class should have implemented Cloneable in
addition to Serializable).
Essentially the PermissionInfoCollection.addPermissions method attempts to
create a "copy" of the permission for the purpose adding to it's
collection.
However, there is nowhere in the spec that states a permission impl must
have either a 0, 1 or 2 String constructor.
The only requirements are:
- they extend from the base Permission class
- thereby should be Serializable
- they be immutable.
So, the "reconstitution" if you will, using the 0, 1 or 2 String
constructor is really just working on assumption and accidentally works
because all of the implementations in standard java are just that simple.
I'm proposing a different "copy" mechanism that will work for any
implementation based on the assumption that they respect Serializable as
they must. I'm not quite sure what that looks like yet, but I have a few
ideas.
However, before going that far, I'm trying to see if I can make a change
in our code to avoid the need the change the equinox impl... but i'm
struggling with this.
Sincerely,
- Ray
On Thu, Apr 18, 2013 at 8:02 AM, BJ Hargrave <[email protected]> wrote:
Can you please provide more detail on the issue? What do you mean by
"cloning"?
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[email protected]
office: +1 386 848 1781
mobile: +1 386 848 3788
From: Raymond Auge <[email protected]>
To: Equinox development mailing list <[email protected]>
Date: 2013/04/17 18:23
Subject: [equinox-dev] PermissionInfoCollection issues with perms
cloning
Sent by: [email protected]
Hello All,
The current implementation of PermissionInfoCollection uses a rather odd
method of cloning permissions which breaks our implementation.
Would anyone object to a new cloning technique which relies purely on
serialization (which is a required interface of permission impls)?
I'll provide an impl unless someone has a problem with changing the
current mechanism.
Thoughts?
--
Raymond Augé | Senior Software Architect | Liferay, Inc.
---
24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012
16 November 2012 | Liferay Italy Symposium | liferay.com/italy2012
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
Raymond Augé | Senior Software Architect | Liferay, Inc.
---
24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012
16 November 2012 | Liferay Italy Symposium | liferay.com/italy2012
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
