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?
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
>>