You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Shrivallabh Deshmukh <sh...@gmail.com> on 2010/04/20 20:59:22 UTC
Classloading issue with the core jdk classes
My plugin uses the webservices api which relies on creating an https
connection.
The bundle class loader cannot resolve the classes present with the jre
(jsse jar)
java.lang.NoClassDefFoundError: javax/net/ssl/HostnameVerifier
I tried adding jsse.jar explicitly using the manifest (duplicate classes
loaded by the classloader), then it began to crib about internal sun
packages.
Any idea why this could be happening? Is there any reason why the bundle
class loader would not see these classes?
Regards
Shrivallabh
Re: Classloading issue with the core jdk classes
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/20/10 15:36, Shrivallabh Deshmukh wrote:
> Once I did that, it started cribbing for sun internal packages. Isnt there a
> simpler method to ensure that all jdk classes are available by default?
>
Not really. Bundles have to express their dependencies.
However, javax.* packages shouldn't have any issue finding sun internal
packages, unless you are saying your bundle is using these sun internal
packages, in which case you need to import them too (and export them
from the system bundle using org.osgi.framework.system.packages.extra
property).
-> richard
> On Wed, Apr 21, 2010 at 12:34 AM, Ali Naddaf<al...@gmail.com> wrote:
>
>
>> I believe you need to import javax.* packages explicitly; only java.*
>> packages are visible by default.
>>
>> Ali.
>>
>>
>> On 4/20/2010 1:59 PM, Shrivallabh Deshmukh wrote:
>>
>>
>>> My plugin uses the webservices api which relies on creating an https
>>> connection.
>>>
>>>
>>>
>>> The bundle class loader cannot resolve the classes present with the jre
>>> (jsse jar)
>>>
>>>
>>>
>>> java.lang.NoClassDefFoundError: javax/net/ssl/HostnameVerifier
>>>
>>>
>>>
>>>
>>>
>>> I tried adding jsse.jar explicitly using the manifest (duplicate classes
>>> loaded by the classloader), then it began to crib about internal sun
>>> packages.
>>>
>>>
>>>
>>> Any idea why this could be happening? Is there any reason why the bundle
>>> class loader would not see these classes?
>>>
>>>
>>>
>>> Regards
>>>
>>>
>>> Shrivallabh
>>>
>>>
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Classloading issue with the core jdk classes
Posted by Stuart McCulloch <mc...@gmail.com>.
On 21 April 2010 03:36, Shrivallabh Deshmukh <sh...@gmail.com> wrote:
> Once I did that, it started cribbing for sun internal packages. Isnt there
> a
> simpler method to ensure that all jdk classes are available by default?
>
the standard set of public packages in the JDK is automatically exported by
the
system bundle, but to make them visible in your client bundle you need to
import
them (except the java.* packages which are always visible to everyone)
this is so you can choose between the JDK provided javax libraries and
alternative
implementations/versions of them - otherwise everyone would be forced to use
the
JDK implementation (which could be back-level / broken)
but if you're not worried about using other versions of these packages you
could
always add them to the "org.osgi.framework.bootdelegation" property which
then
means you wouldn't need to add imports for them:
"org.osgi.framework.bootdelegation=javax.*,sun.*,com.sun.*"
note: the reason you saw the message about internal sun packages is probably
because you added the jsse.jar to the bundle classpath, which meant its
content
was loaded by the bundle classloader and was therefore limited to only see
what
the bundle contained/imported - if you add "javax.net.ssl" to the bundle
imports,
or use the bootdelegation approach then you shouldn't see this error because
the
jsse.jar will be loaded by the extension class loader (as in classic java)
and will
be able to see the internal sun packages from the JDK
HTH
> On Wed, Apr 21, 2010 at 12:34 AM, Ali Naddaf <al...@gmail.com> wrote:
>
> > I believe you need to import javax.* packages explicitly; only java.*
> > packages are visible by default.
> >
> > Ali.
> >
> >
> > On 4/20/2010 1:59 PM, Shrivallabh Deshmukh wrote:
> >
> >> My plugin uses the webservices api which relies on creating an https
> >> connection.
> >>
> >>
> >>
> >> The bundle class loader cannot resolve the classes present with the jre
> >> (jsse jar)
> >>
> >>
> >>
> >> java.lang.NoClassDefFoundError: javax/net/ssl/HostnameVerifier
> >>
> >>
> >>
> >>
> >>
> >> I tried adding jsse.jar explicitly using the manifest (duplicate classes
> >> loaded by the classloader), then it began to crib about internal sun
> >> packages.
> >>
> >>
> >>
> >> Any idea why this could be happening? Is there any reason why the bundle
> >> class loader would not see these classes?
> >>
> >>
> >>
> >> Regards
> >>
> >>
> >> Shrivallabh
> >>
> >>
> >>
> >
>
--
Cheers, Stuart
Re: Classloading issue with the core jdk classes
Posted by Shrivallabh Deshmukh <sh...@gmail.com>.
Once I did that, it started cribbing for sun internal packages. Isnt there a
simpler method to ensure that all jdk classes are available by default?
On Wed, Apr 21, 2010 at 12:34 AM, Ali Naddaf <al...@gmail.com> wrote:
> I believe you need to import javax.* packages explicitly; only java.*
> packages are visible by default.
>
> Ali.
>
>
> On 4/20/2010 1:59 PM, Shrivallabh Deshmukh wrote:
>
>> My plugin uses the webservices api which relies on creating an https
>> connection.
>>
>>
>>
>> The bundle class loader cannot resolve the classes present with the jre
>> (jsse jar)
>>
>>
>>
>> java.lang.NoClassDefFoundError: javax/net/ssl/HostnameVerifier
>>
>>
>>
>>
>>
>> I tried adding jsse.jar explicitly using the manifest (duplicate classes
>> loaded by the classloader), then it began to crib about internal sun
>> packages.
>>
>>
>>
>> Any idea why this could be happening? Is there any reason why the bundle
>> class loader would not see these classes?
>>
>>
>>
>> Regards
>>
>>
>> Shrivallabh
>>
>>
>>
>
Re: Classloading issue with the core jdk classes
Posted by Ali Naddaf <al...@gmail.com>.
I believe you need to import javax.* packages explicitly; only java.*
packages are visible by default.
Ali.
On 4/20/2010 1:59 PM, Shrivallabh Deshmukh wrote:
> My plugin uses the webservices api which relies on creating an https
> connection.
>
>
>
> The bundle class loader cannot resolve the classes present with the jre
> (jsse jar)
>
>
>
> java.lang.NoClassDefFoundError: javax/net/ssl/HostnameVerifier
>
>
>
>
>
> I tried adding jsse.jar explicitly using the manifest (duplicate classes
> loaded by the classloader), then it began to crib about internal sun
> packages.
>
>
>
> Any idea why this could be happening? Is there any reason why the bundle
> class loader would not see these classes?
>
>
>
> Regards
>
>
> Shrivallabh
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org