[
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
--
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"?
--
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
