Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] PermissionInfoCollection issues with perms cloning

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
hargrave@xxxxxxxxxx

office: +1 386 848 1781
mobile: +1 386 848 3788





From:        Raymond Auge <raymond.auge@xxxxxxxxxxx>
To:        Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date:        2013/04/18 11:23
Subject:        Re: [equinox-dev] PermissionInfoCollection issues with perms cloning
Sent by:        equinox-dev-bounces@xxxxxxxxxxx





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 <hargrave@xxxxxxxxxx> 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
hargrave@xxxxxxxxxx





From:        
Raymond Auge <raymond.auge@xxxxxxxxxxx>
To:        
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date:        2013/04/17 18:23
Subject:        [equinox-dev] PermissionInfoCollection issues with perms cloning
Sent by:        
equinox-dev-bounces@xxxxxxxxxxx





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

equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list

equinox-dev@xxxxxxxxxxx
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
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


Back to the top