2

I have a XPage application where I use JavaMail in one of my managed beans. Currently I have added the jar-file C:\Programme\IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jarto the build-path of the manged bean. This works well. But now I want to use a newer version of JavaMail as the Domino server uses version 1.3 but I need version 1.4.x.

I have downloaded the new JavaMail jar-files from Oracle. In Domino Designer (version 9) I add this jar-file to the new design element "Code / Jars" and remove the old jar-files from the build path.
My managed bean is still compiling and running as desired, but if I check the version the bean is using it reports still version 1.3. To check the version number I use the debug property of JavaMail and it's reporting version 1.3 to the domino server console.

Is there a way to tell the domino server to use the jar-files in the application (i.e. the nsf) and not his own? Is there another approach to update the JavaMail version?

The reason I want to use a newer version of JavaMail is as follows: I want to read mails from an imap server with ssl. To avoid the problem of importing ssl-certificates I simply want to trust all hosts. This can be be done via MailSSLSocketFactory, but this is only available since version 1.4.2. Therefore I want to use a newer version of JavaMail.

Another reason I want to use a newer version is as follows: the method "getSortedMessages" of "IMAPFolder" is only available since version 1.4.4. (and so are some other features of JavaMail).

Detlef Birkholz
  • 441
  • 2
  • 11
  • Have you checked if the Jar was properly added to the build path in the NSF? (Besides you could write your MIME directly into the mail.box potentially eliminate the 1.4 need) – stwissel Aug 07 '13 at 14:46
  • Yes, the Jar is in the build path of the NSF. It shows up under the tab Library and the path is /WebContent/WEB-INF/lib – Detlef Birkholz Aug 08 '13 at 06:24
  • It wont work. When XPages engine starts, Java classloader kicks off and the system version of mail.jar is loaded. You can play around with the classloader (see http://stackoverflow.com/questions/6105124/java-classpath-classloading-multiple-versions-of-the-same-jar-project), but I really see no reason to do it. I think it will be more helpful if you can expand your problem a bit, since it's not quite clear why are you trying to use Java Mail instead of Domino buil-in functionality (e.g. http://openntf.org/XSnippets.nsf/snippet.xsp?id=create-html-mails-in-ssjs-using-mime) – Egor Margineanu Aug 08 '13 at 13:10
  • Update my original question to make clear why I want to use a newer version – Detlef Birkholz Aug 08 '13 at 14:26
  • Try to see if solution from http://www.oracle.com/technetwork/java/javamail145sslnotes-1562622.html works for you. – Egor Margineanu Aug 08 '13 at 19:36
  • 1
    So you want to use a function to lower security since [insert-reason-here]. This opens your code to currently popular man-in-the-middle attacks #prism Depending on your industry that could be a breach of compliance – stwissel Aug 11 '13 at 07:49
  • @stwissel: Your right, that might be a problem that I must take into account. But apart from my example "MailSSLSocketFactory", I have another reason to use a newer version of JavaMail (see my udpated post - "getSortedMessages") – Detlef Birkholz Aug 13 '13 at 09:07

3 Answers3

1

This may be a little too late for you... I think the right approach may be to include the jar file as an OSGi plugin.

I have spent some time to figure out how to do that - and recently succeeded :-) I have described the steps to perform to make this work in two articles. The first is about wrapping a JAR into a plug-in: http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/ - the second is about deployment (and there is a link in the first one).

/John

John Dalsgaard
  • 2,797
  • 1
  • 14
  • 26
  • I can confirm this method is fully working. For me the most important part is to check "Unpack the plug-in archive after the installation"-box in your feature project. Without this it will not work for Javamail. – Ferry Kranenburg Sep 07 '15 at 08:34
  • Yep, I found out... and my guide has been updated some time ago to make sure to "unpack the plugin..." as you specify. I was originally cheated by an open plugin project :-) – John Dalsgaard Sep 07 '15 at 19:36
  • @FerryKranenburg How did You manage to ovecome problems with class loaders? I tried this and after adding javamail plugin to domino/designer xpgaes still loads version 1.3 (designer recognized libraries from plugin so I think it was correctly builded ) – W_K Feb 15 '16 at 15:57
0

I've got the same problem here, but found a solution. Be warned, this is not the best answer but it will work. Simply download the latest javamail jar here and rename the jar file to 'mail.jar'. Just replace the current file in IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jar with this file. Quit the http task and restart it. The code will now work with the latest version.

Ferry Kranenburg
  • 2,625
  • 1
  • 17
  • 23
0

You can solve the problem by creating an OSGi plug-in that supersedes the one that sports the JavaMail library: com.ibm.designer.lib.javamail. In order to do that do the following:

  1. Create an OSGi plugin whose id is com.ibm.designer.lib.javamail (Dalsgaard's tutorial on how to do it)
  2. Set its version to a higher number than the one the Domino server is shipped with (to know the version type tell http osgi ss com.ibm.designer.lib.javamail). As of now using 9.0.1.qualifier should be fine
  3. Deploy the plugin either through an update site or by directly copying it under the domino\workspace\applications\eclipse\plugins folder.
  4. Restart the HTTP service. The higher version - the one you created - will now be used
shillem
  • 1,260
  • 7
  • 12