[osgi-dev] OSGI ClassLoader discover process

Alan Cabrera adc at toolazydogs.com
Thu Feb 28 18:40:02 EST 2008


Interesting.  So, if Eclipse started from scratch and its classes  
have no protection domains, how would you do permissions?


Regards,
Alan

On Feb 28, 2008, at 3:26 PM, Thomas Watson wrote:

> I would be careful here.
>
> All classes do not need protection domains if the security manager  
> is not enabled and all protection domains do not have to have a  
> code source. With that said, Equinox does always define a  
> protection domain for every class and it does populate the  
> CodeSource objects with URLs, but this is all implementation  
> details. The only reason Equinox was forced to do this was because  
> we were replacing a framework (from Eclipse 2.1) that used simple  
> URLClassLoaders for its implementation. URLClassLoader creates  
> protection domains and code sources. Several clients were dependant  
> on this implementation detail so we had to preserve the behavior  
> for compatibility reasons.
>
> I would not be surprised if other implementations of the OSGi  
> Framework did not provide the CodeSource objects as you are expecting.
>
> Tom
>
>
>
> <graycol.gif>Alan Cabrera ---02/28/2008 04:53:13 PM---It's a java  
> concept. All classes have protection domains. All
>
> <ecblank.gif>
> From:	<ecblank.gif>
> Alan Cabrera <adc at toolazydogs.com>
> <ecblank.gif>
> To:	<ecblank.gif>
> OSGi Developer Mail List <osgi-dev at www2.osgi.org>
> <ecblank.gif>
> Date:	<ecblank.gif>
> 02/28/2008 04:53 PM
> <ecblank.gif>
> Subject:	<ecblank.gif>
> 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
> >>> osgi-dev at www2.osgi.org
> >>> https://www2.osgi.org/mailman/listinfo/osgi-dev
> >>>
> >>
> >> _______________________________________________
> >> OSGi Developer Mail List
> >> osgi-dev at www2.osgi.org
> >> https://www2.osgi.org/mailman/listinfo/osgi-dev
> >>
> > _______________________________________________
> > OSGi Developer Mail List
> > osgi-dev at www2.osgi.org
> > https://www2.osgi.org/mailman/listinfo/osgi-dev
> >
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev at www2.osgi.org
> https://www2.osgi.org/mailman/listinfo/osgi-dev
>
> <graycol.gif><ecblank.gif>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev at www2.osgi.org
> https://www2.osgi.org/mailman/listinfo/osgi-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www2.osgi.org/pipermail/osgi-dev/attachments/20080228/314af6a3/attachment.html


More information about the osgi-dev mailing list