On 5/27/09 1:29 PM, Sahoo wrote:
> 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.
Ok, so we are using boot delegation to create the union of the partial
JRE package with the bundle exported package, essentially. Yes, I don't
see another way to deal with that. The proper approach would be to
replace the JRE packages completely, since they appear to be faulty
(since they are incomplete); however, I agree that this would likely
entail re-packaging much more than the offending package due to "uses"
constraints.
-> richard