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?
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?
-Peter
>
> -> richard
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>