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 > >> > >> > >> > >> 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 > _______________________________________________ OSGi Developer Mail List [email protected] https://www2.osgi.org/mailman/listinfo/osgi-dev
