Announcement Announcement Module
Collapse

Spring Dynamic Modules forum decommissioned in favor of Eclipse Gemini Blueprint

With the official first release of Eclipse Gemini Blueprint shipped, the migration of the Spring Dynamic Modules code base to the Eclipse Foundation, as part of the Gemini project, has been completed.

As such, this forum has been decommissioned in favour of the Eclipse Gemini forums.
See more
See less
Class loading Issue with boot classloader in OSGi Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Class loading Issue with boot classloader in OSGi

    I've been using javamail-1.4ea APIs to send mails using SMTP in an OSGi environment.

    Recently while setting the property "ssl.SocketFactory.provider".
    I've created a custom ssl socket factory by extending the class "SSLSocketFactory". This Class is responsible for creating sockets for communication with the SMTP Server & also acts a "Trust Manager" which verifies the SSL certificates. The class resides in one of my bundles.

    The issue here is this custom factory needs to be set as java.security.Security.setProperty("ssl.SocketFact ory.provider",
    "mypackage.CustomSSLSocketFactory") before creating the connection.
    Upon exceution, I get a ClassNotFoundException for the class "mypackage.CustomSSLSocketFactory".

    I believe this is because the boot class loader in the JRE package looks for the class doesn't find it.

    But when I bundle the class in a jar and place it in <JRE>\lib\ext, the class is picked up by the boot classloader.

    Is it possible to place the class in the boot class path programatically or is it possible to extend the boot class path from OSGi to include the bundle?

    Regards
    Mirza

  • #2
    Mirza, I'm not familiar with the SSL provider but it sounds like these classes need to be installed in the ext (extended) folder. Technically speaking the boot class loader cannot be access - it is the primordial class loader and it's normally returned as null - what you're looking for is the ExtClassLoader.
    Anyway, since SSL is a critical piece of infrastructure, for security purposes the infrastructure might not allow dynamic installs/uninstalls. However, you should double check the configuration to see what you can find.
    If you can't find an API to talk to, you could try to provide some sort of dynamic SSL factory that just gets created and to which you could connect from your application. It might work or not depending on when the JRE accesses the ext classes and whether it caches the information from them or not. Basically, if at startup the SSL engine is initialized then it's likely any later updates made to your custom factory will just be ignored.

    Comment


    • #3
      Hi Costin,

      Thanks for the info. You are right; I wasn't able to access the boot class loader but was able to access the boot class path.

      What I did was:
      1. Create the custom SSLSocketFactory.
      2. Wrap it in a jar file.
      3. place the jar file on the bootclass path by using the option:
      -Xbootclasspath/a:<path to the jar>.
      4. This would make the class visible to the ExtClassLoader.

      There is one more approach which I wish to try out i.e. use the concept of Osgi Extension Bundles where I wrap my class in a fragment attached to the " system.bundle" with extension:=bootclasspath.
      But I'm not sure which version of Equinox supports "bootclasspath" as I've tried both 3.3 & 3.4, but none seem to work Though "framework" extensions are supported.

      If you have any info. about this feature in Equinox, please let me know.
      Last edited by mirzafasi; Mar 9th, 2009, 11:52 AM.

      Comment


      • #4
        Right, the bootclasspath extension is not supported on any OSGi platforms that I know of. As for system fragments, this blog entry by yours truly might be helpful: http://blog.springsource.com/2009/01...spath-in-osgi/

        Comment

        Working...
        X