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