Sahoo wrote:
> Marina Vatkina wrote:
>> Richard S. Hall wrote:
>>>
>>>
>>> On 5/27/09 4:59 PM, Marina Vatkina wrote:
>>>
>>>> Ken,
>>>>
>>>> Is it possible to remove duplicate classes from the
>>>> glassfish-corba-xxx modules?
>>>
>>>
>>> The duplicate classes are not really the issue. The issue is that
>>> the built-in JRE package is incomplete, so we somehow need to add
>>> the missing classes to the package.
>>
>> If we really need to. Do we have the list of must-haves add-ons?
>>
>> For the org.omg.CORBA package, I know about TSIdentification that Ken
>> Cavanaugh said is possible to be moved to jts module, and the ORB
>> class that exists in 2 locations, JRE and glassfish-corba-omgapi.jar.
>> May be there are more case that I don't know about. If there are, and
>> there is nothing we can do to fix them, yes, we need to work around
>> the problem. Otherwise we might be able to fix it the right way (i.e.
>> remove duplicates and split packages).
>>
>> If we do fall back into the bootdelegation solution, unless it's too
>> time consuming, it would be nice to have the list of those classes
>> that we can't fix otherwise, won't it?
>>
> The solution is *not* time consuming. Here is how the final solution
> looks like.
>
> 1. Add org.omg.CORBA and org.omg.CORBA.* to bootdelegation list of
> packages.
> 2. Stop system bundle from exporting them. Either we can completely
> remove them or add a mandatory attribute. See how javax.transaction is
> handled in felix/conf.properties.
> 3. Package all the additional org.omg.CORBA classes in an osgi bundle
> and export them. The bundle *can* continue to contain all the
> org.omg.CORBA classes that exist in JRE. The duplication won't cause
> any problem because of bootdelegation. How we determine what are the
> extra classes? That's up to us. We can grow that list as time progresses.
>
> Sahoo
I forgot to mention. Look at the explanation in one of Richard's email
for why duplicate classes is not an issue with this approach.
Thanks,
Sahoo