Richard S. Hall wrote:
> 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.
>
Thanks for confirming. We will proceed with this approach.
Sahoo