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?
-> richard
p.s. I have the "uses" information for the JRE packages if you want me
to send it to you.
>
> Thanks,
> Sahoo
>
> Richard S. Hall wrote:
>> I played around with BND to see if I could generate this information.
>> I did see the following "used by" relationships, which are correctly
>> captured in "uses" constraints:
>>
>> * org.omg.CORBA used by:
>> o javax.management.remote.rmi
>> o javax.rmi
>> o javax.rmi.CORBA
>> o org.omg.CORBA.DynAnyPackage
>> o org.omg.CORBA.ORBPackage
>> o org.omg.CORBA.TypeCodePackage
>> o org.omg.CORBA.portable
>> o org.omg.CORBA_2_3
>> o org.omg.CORBA_2_3.portable
>> o org.omg.CosNaming
>> o org.omg.CosNaming.NamingContextExtPackage
>> o org.omg.CosNaming.NamingContextPackage
>> o org.omg.Dynamic
>> o org.omg.DynamicAny
>> o org.omg.DynamicAny.DynAnyFactoryPackage
>> o org.omg.DynamicAny.DynAnyPackage
>> o org.omg.IOP
>> o org.omg.IOP.CodecFactoryPackage
>> o org.omg.IOP.CodecPackage
>> o org.omg.Messaging
>> o org.omg.PortableInterceptor
>> o org.omg.PortableInterceptor.ORBInitInfoPackage
>> o org.omg.PortableServer
>> o org.omg.PortableServer.CurrentPackage
>> o org.omg.PortableServer.POAManagerPackage
>> o org.omg.PortableServer.POAPackage
>> o org.omg.PortableServer.ServantLocatorPackage
>> o org.omg.PortableServer.portable
>> o org.omg.SendingContext
>> o org.omg.stub.javax.management.remote.rmi
>>
>> I did this on a Mac, so it is not necessarily clear if this
>> information is universal, but it could potentially work.
>>
>> -> richard
>>
>> On 5/27/09 10:20 AM, Richard S. Hall wrote:
>>> On 5/27/09 4:19 AM, Sahoo wrote:
>>>> Now let's see why the error was so cryptic in an OSGi environment.
>>>> After all, OSGi is supposed to give us more helpful errors. The
>>>> problem is our system packages are exported without any "uses"
>>>> clause. "uses" clause plays a vital role in package resolution and
>>>> correct specification of uses attribute might have given us a
>>>> better error stating the class space was not consistent.
>>>
>>> Yes, you are correct. The system packages for the JRE do not
>>> correctly express "uses" constraints. Not sure what we can do here.
>>> I wonder if BND could generate that information. I wonder if it
>>> would have any negative consequences. It would be interesting
>>> information, nonetheless.
>>>
>>> -> richard
>>>
>>>>
>>>> Hope that helps,
>>>> Thanks,
>>>> Sahoo
>>>>
>>>> Marina Vatkina wrote:
>>>>> Team,
>>>>>
>>>>> Does anybody know what can cause this type of a LinkageError:
>>>>>
>>>>> Caused by: java.lang.VerifyError: (class:
>>>>> org/glassfish/enterprise/iiop/impl/GlassFishORBManager, method:
>>>>> initORB signature: (Ljava/util/Properties;)V) Bad type in
>>>>> putfield/putstatic
>>>>> at
>>>>> org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.postConstruct(GlassFishORBFactoryImpl.java:29)
>>>>>
>>>>> at
>>>>> com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:170)
>>>>>
>>>>>
>>>>>
>>>>> I see this error if I remove org.omg.CORBA package (only it, not
>>>>> its subpackages) from the
>>>>> glassfishv3/glassfish/osgi/felix/conf/config.properties (because
>>>>> it's available in the glassfish-corba-omgapi module) and then try
>>>>> to deploy an app with remote EJBs (i.e. force orb integration
>>>>> modules to be loaded). The same error happens on server restart if
>>>>> I first deploy the app, then modify the
>>>>> felix/conf/config.properties file.
>>>>>
>>>>> Googling for this error brings cases when 2 versions of the same
>>>>> class was present in 2 jars. But GlassFishORBManager is there in
>>>>> only one. Or a jdk 1.4 bug where you downcast the result to one of
>>>>> the interfaces (String to Clonable), which a) had been fixed back
>>>>> then and b) doesn't seem to be the case here as well :(.
>>>>>
>>>>> It doesn't make a difference whether I start GF via 'java -jar' or
>>>>> asadmin.
>>>>>
>>>>> Any ideas are greatly appreciated.
>>>>>
>>>>> thank you,
>>>>> -marina
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>