On 5/21/09 12:29 AM, Peter Williams wrote:
> Richard S. Hall wrote:
>> On 5/20/09 10:34 PM, Bill Shannon wrote:
>>> Richard S. Hall wrote:
>>>> Yes, the main approach for solving such situations is to use
>>>> probing (i.e, the extender model) as opposed to asking the context
>>>> class loader.
>>>
>>> That's not acceptable. We need a way to make this work. We can't
>>> change the code in the JDK (e.g., JAF) to depend on some OSGi-specific
>>> workaround. Even if this means adding a non-standard feature to the
>>> OSGi class loaders, we need to fix this.
>>
>> Sahoo didn't rewrite the JDK to get META-INF/services working and I
>> don't think anyone proposed modifying the JDK to get this working
>> either.
> The extender pattern you describe requires replacing (via endorsed I
> suppose) the MailcapCommandMap class in the JDK.
>
> Is there another way?
Again, I don't know enough about JAF technology to say for sure.
Generally, you need to create a bridge somehow from the bundles
providing the extension to the technology needing it. So, if there is
someway to hook into its lookup mechanism so we can answer its requests
appropriately or inject it directly, then those are the general approaches.
>
> Suppose we did use this extender patten. What about the following
> situation: Bundle A contains and registers (or has registered for it)
> a mailcap file + handler implementation. Bundle B reads some piece of
> email that requires that handler. So we end up with B.foo -> JavaMail
> -> JAF -> A.handler. Now suppose while A.handler is active, bundle A
> is unloaded. First, is this conceivable and second, what should happen?
Yes, it is possible for a bundle to go away, it is always possible in
OSGi. Of course, this doesn't mean the application's management agent
allows this to happen. If it does, however, then it will be the
management agent's responsibility to refresh whatever parts of the
application need refreshing to ensure everyone has stopped using the
classes from the removed bundle.
-> richard