NoClassDefFoundError for javax.net.ssl.HostnameVerifier in case of third party jars which I am installing as bundle. | Community
Skip to main content
vikask7567025
vikask7567025
January 8, 2020

NoClassDefFoundError for javax.net.ssl.HostnameVerifier in case of third party jars which I am installing as bundle.

  • January 8, 2020
  • 2 replies
  • 2860 views

Hi Experts,

 

I am trying to use one 3rd party jar (cloudinary) so that AEM can connect to cloudinary APIs, I have created bundle from these jars and installed in Felix console. Now when I am trying to invoke my logic to connect to cloudinary APIs, it is throwing  "java.lang.ClassNotFoundException: javax.net.ssl.HostnameVerifier not found" by jarBundle (3rd party jar bundle). while debugging I saw that this HostnameVerifier is available at rt.jar for 3rd party jar bundle still this issue is appearing.

 

Could someone help me here ?

 

Here is the exception stacktrace 

 

Caused by: java.lang.NoClassDefFoundError: javax/net/ssl/HostnameVerifier
at org.apache.http.impl.client.HttpClients.custom(HttpClients.java:48)
at com.cloudinary.http44.UploaderStrategy.init(UploaderStrategy.java:40)
at com.cloudinary.Uploader.<init>(Uploader.java:43)
at com.cloudinary.Cloudinary.uploader(Cloudinary.java:43)
at com.abhi.www.cloudinary.impl.workflow.UpdateAssetWorkflowProcess.execute(UpdateAssetWorkflowProcess.java:51)
at com.day.cq.workflow.compatibility.CQWorkflowProcessRunner.execute(CQWorkflowProcessRunner.java:93)
... 9 common frames omitted
Caused by: java.lang.ClassNotFoundException: javax.net.ssl.HostnameVerifier not found by cloudinaryBundle [570]
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1574)
at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
at java.lang.ClassLoader.loadClass(Unknown Source)

 

This issue is happening only in AEM environment, if I am trying to connect that cloudinary apis in standalone Java Maven by using maven dependencies rather than plugin bundle creation (which I did in AEM), there is no such issue while invoking the api access logic.

 

Regards,

Vikas

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

2 replies

P
Adobe Employee
prasanna965000Adobe Employee
Adobe Employee
January 24, 2023

Did you find the resolution for this?

    Ankur_Khare
    Community Advisor
    Ankur_KhareCommunity Advisor
    Community Advisor
    January 26, 2023

    can you share with us more details like whatare you trying to upload like which bundle ..

      P
      Adobe Employee
      prasanna965000Adobe Employee
      Adobe Employee
      January 30, 2023

      I am trying to use cloudmersive(third party) bundle 

      <dependency>
      <groupId>com.github.Cloudmersive</groupId>
      <artifactId>Cloudmersive.APIClient.Java</artifactId>
      <version>v2.75</version>
      </dependency>

       

      I exported the jar to a bundle and installed it in aem using system/console. After upload, my cloudmersive and project bundles, both were in Active state, but was facing the issue which I posted few days back(

      NoClassDefFoundError for javax.net.ssl.HostnameVerifier).

       

      To solve it, I added javax.net.ssl entry in Import-package of the cloudmersive bundle manifest file and the error got resolved.

       

      But, now getting new errors related to other dependencies which are not even exported by aem like - com.squareup.okhttp and other external classes referenced by cloudmersive bundle internally. Not sure how to proceed.

      B
      babusankars
      November 17, 2024

      Hello Vikas & Others,

      Did you got this resolved between AEM and Cloundinary issue?

      I am having the same error of HostnameVerifier!

       

      =======

      Caused by: java.lang.ClassNotFoundException: javax.net.ssl.HostnameVerifier not found by my-project.cloudinary-custom [653]

      at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1597)

      at org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)

      at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)

      at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)

      ... 154 common frames omitted

      ==========

       

      Thanks,

      Babu.

       

      Terms & ConditionsAccessibility statement

      Loading footer...