Richard S. Hall wrote:
> On 5/27/09 12:31 PM, Sahoo wrote:
>> This is good information. This can be used to arrive at a proper
>> solution. I am inclined to say solution #2 (see my previous email)
>> will require us to package a lot of classes in OSGi bundles, because
>> there will be other JDK packages which depends on this set of
>> packages and all of them have to be repackaged. It may not be legal
>> to do so. Even if it is legal, it may just be too heavyweight a
>> solution. So, #1 may be only viable solution. Do you agree?
>
> I think the answer depends, but ultimately you may be correct.
>
> However, if we can adopt boot delegation as a solution, then it seems
> to be equivalent of saying that it is not necessary for any other
> bundle to export what we are boot delegating, since everyone will use
> the JRE package. If that is true, then we should be able to remove the
> duplicate package from the exporting bundle and just export it from
> the system bundle from which every bundle will import it, no?
>
Not really unless I am misunderstanding you. It's an ugly split-package
issue. As I mentioned somewhere in that email, JDK contains partial list
of classes for some of those packages. So, we need to have another
bundle export those packages, so that when bootdelegation fails to
locate one of those extra classes, it can be found traversing
Import-Package wiring.
We have the same issue with javax.transaction. javas.sql, which is
coming from rt.jar, depends on javax.transaction, but rt.jar has only a
few of the javax.transaction classes. So, we bootdelegate
javax.transaction in addition to having our own javax.transaction bundle
which has all the classes.
Thanks,
Sahoo