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.
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.
Again, my experience is very narrow. I would be interested in hearing
if there are JVMs out there that do not have this behavior.
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.
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
Alan Cabrera ---02/28/2008 04:53:13 PM---It's a java concept. All
classes
have protection domains. All
From:
Alan Cabrera <[EMAIL PROTECTED]>
To:
OSGi Developer Mail List <[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.
Regards,
Alan
On Feb 28, 2008, at 1:08 PM, Kyrill Alyoshin wrote:
Alan,
I am sorry. I am a complete OSGi novice as far as APIs are
concerned. How do I get to codesource URLs? Do you mean
URLClassLoader#getURLs()?
Thanks,
-Kyrill
Alan Cabrera wrote:
I think that the best you can do is list the codesource URLs.
Regards,
Alan
On Feb 28, 2008, at 10:28 AM, Kyrill Alyoshin wrote:
Interesting... How would you start approaching this problem?...
-Kyrill
BJ Hargrave wrote:
OSGi does not require class loaders to be backed by jar files.
Jars are the typically distribution (and install) format for
bundles. But once installed, the framework is free to manage the
bundle contents in anyway (e.g. put them in a database.) OSGi
also does not require bundles to be in jar format. Many OSGi
implementations support installing bundles in directory format
or even VM implementation proprietary formats (e.g. J9 JXE).
So I don't see that there is any way to map a bundle's
classloader onto a set of jar files for that bundle.
A better problem to look at for OSGi, would be what bundles are
installed but not used. This could be determined by analyzing
that state of the installed bundles (are they started? will they
be started at some startlevel?) and the dependencies between
bundles (does some other bundle depend upon this bundle?). This
analysis could find "orhpan" bundles which can safely be
uninstalled.
My main point is that in OSGi you should not think in terms of
jars (and classloaders which reference them) but in terms of
bundles (and which bundles reference them).
_______________________________________________
OSGi Developer Mail List
[email protected]
https://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://www2.osgi.org/mailman/listinfo/osgi-dev
