Yeah. I drifted off to PDs and permissions, leaving CS objects, you,
and Tom behind. Sorry.
As you noted and I already knew if you don't pass a PD or the CS into
the defineClass method you get a shared default one. I took Tom's
earlier statement to mean that PDs didn't need to be generated. Maybe
that's not what he meant and he was merely focusing on the CS and
there was my disconnect. If *frameworks* did not generate PDs then
they all get the same shared default one and so I didn't understand
how permissions could work.
Anyway, in short, you and Tom are correct, CS do not need to be
assigned to Class instances. Using clasloaders for keys, as you
suggested, seems the best way to go.
Regards,
Alan
On Feb 29, 2008, at 1:16 AM, Mirko Jahn wrote:
Hi Alan,
I think there some minor misunderstandings. First of all, I (and I
guess Tom as well) was just talking about CS objects, not PDs. The
Permissions a class have are provided by the PD
(someObject.getClass().getProtectionDomain().getPermissions() ) and
the implies method, which is called by the AC doesn't require the CS
as well. Of course, if you then call the getCodeSource() method on the
PD, it will return null if you haven't provided one during PD
creation. Actually, you are interested in the Permissions and these
you can be assigned during class loading, when you know where you
loaded these classes from. You can store the location information in
let's say a database instead of a CS object, if you need this
information later internally. PDs are not final, so you can create
your own custom PD in order to achieve the behavior you want (like the
one in OSGi with dynamism and Conditions). This is NOT related to the
JVM at all, so this is an application behavior.
Cheers,
Mirko
On Fri, Feb 29, 2008 at 1:59 AM, Alan Cabrera <[EMAIL PROTECTED]>
wrote:
My experience is w/ a handful of desktop and server JVMs.
IIRC it's up to the implementation of the classloader whether PD/CSs
get generated or not. Whether an SM is installed doesn't seem
relevant to that behavior. And so, it's up to the framework's
implementation of the bundle classloader as to whether a PD/CS gets
created for a particular class.
well, if the custom class loader doesn't provide a PD, the default PD
will be attached.
As far as the number of PDs and CS objects created, I think that
there
is usually a one-to-one correspondence between a jar/bundle and the
PD/
CS pair. Doesn't seem like much to me.
Well, I guess this makes sense to put it that way.
Again, my experience is very narrow. I would be interested in
hearing
if there are JVMs out there that do not have this behavior.
No, this is not JVM related.
About testing permissions. I realize that permission collections are
attached to the PD. But, IIUC, Tom claimed that there could be valid
frameworks that do not install PDs. If this is true, then I am
wondering how the frameworks support permissions, if at all. If they
did, I would be really interested in seeing how that would work.
Especially with code executing outside the framework.
No, PDs are always required. Only CS objects are not necessarily part
of the permission evaluation, so they can be left out.
Regards,
Alan
On Feb 28, 2008, at 4:22 PM, Mirko Jahn wrote:
I agree with Tom on this one. Unless you have the SecurityManager
enabled, you can't assume you have either a PD or a CS object
available. Just for performance reasons, there are scenarios, where
you don't want to wast your resources on usually unused objects.
I would not be surprised if other implementations of the OSGi
Framework did
not provide the CodeSource objects as you are expecting.
As I learned through the last couple of weeks, this is true for at
least one implementation I know about and it just works fine.
CodeSource objects are only one way to keep the information. No
one is
forced to use it, although it is pretty common, I guess.
I am actually not sure how fare you can go with the regular Java
APIs
on this one, but I guess AOP might be the way to go. Here you can
use
the distinct ClassLoader interface to keep track of all activities
and
be aware of everything loaded, including input parameters and even
callers. This might be worth more investigations...
Cheers,
Mirko
BTW.: Permissions are only enforced with a SecurityManager enabled
and
bound to ProtectionDomains. The checking itself does not necessarily
involve CodeSource objects, if you look at the ProtectionDomain
class.
Tom
From: Alan Cabrera <[EMAIL PROTECTED]>
Date: 02/28/2008 04:53 PM
Subject: Re: [osgi-dev] OSGI ClassLoader discover process
________________________________
It's a java concept. All classes have protection domains. All
protection domains have a code source. All code sources have a URL
that represents where the code came from.
_______________________________________________
OSGi Developer Mail List
[email protected]
https://www2.osgi.org/mailman/listinfo/osgi-dev
