search

eclipse-ee4j / angus-mail

Angus Mail
https://eclipse-ee4j.github.io/angus-mail
Other
58 stars 16 forks source link

email inline image regression #118

Closed davcmat closed 9 months ago

davcmat commented 10 months ago

I'm the maintainer of the jwma (java webmail) app [https://jwma.sourceforge.net/]

The next release will have fully working support for Content-id. By this I mean I can create an email with <img src="cid:image" tags and have these displayed in jwma itself and also at gmail. The app will also display email with inline images received from other client programs in a way similar to gmail's rendition of them.

If I upgrade from jakarta mail and jakarta activation 2.0.0 to version 2.1.2 with angus mail 2.0.2, inline images are no longer displayed. With very minimal changes other than swapping jar files in and out, a quick look suggests everything else works. It remains possible to send and receive email and remote images (with img src="https...") continue to work as before.

I'm using firefox on debian bookworm. I've never noticed any appreciable difference in display if I test on other browsers, so this will not be a firefox issue

I can't offer a way to reproduce this other than using my own code and compiling against the two versions of jakarta mail (ie 2.0.0 against 2.1.2 with angus mail)

I'm aware that support for Content-id is patchy; microsoft does not support it with outlook.com addresses; maybe this is a policy decision? I never send emails myself with images, except as attachments, but I've been asked to add support for inline image handling (nagged for Content-id support in fact!)

jmehrens commented 10 months ago

If I upgrade from jakarta mail and jakarta activation 2.0.0 to version 2.1.2 with angus mail 2.0.2, inline images are no longer displayed.

What dependencies have you declared when you switched to using Angus Mail?

There are 4 jars that have to be added: angus-activation-XXX.jar, angus-mail-XXX.jar jakarta.mail-api-XXX.jar jakarta.activation-api-XXX.jar

Beyond that, being the problem please include a minimal test case for me to try.

davcmat commented 10 months ago

If I upgrade from jakarta mail and jakarta activation 2.0.0 to version 2.1.2 with angus mail 2.0.2, inline images are no longer displayed.

What dependencies have you declared when you switched to using Angus Mail?

There are 4 jars that have to be added: angus-activation-XXX.jar, angus-mail-XXX.jar jakarta.mail-api-XXX.jar jakarta.activation-api-XXX.jar

Yes those are added, except I'm using angus core + imap and smtp jars as I don't need pop. As I said, everything else works; mail is sent and received and remote images are displayed as expected.

Beyond that, being the problem please include a minimal test case for me to try.

I don't see a quick way of doing that. However I think that the real issue is not Content-id, rather that base64 encoded image data is not displayed. I also find that if version 2.0.0 of jakarta mail is included in the runtime classpath (not present during compilation) the issue goes away.

I will narrow down what's needed from that jar - strongly suspect the util folder - and get back to you with a proposed fix

-- David Matthews @.***

davcmat commented 10 months ago

hi again

I don't think the investigation I was planning can work.

Broken inline images - recap, with a bit more detail. With the new jakarta jars (5 in all) replacing v2.0.0 of jakarta mail and jakarta activation only minimal changes are necessary for the code to compile and run. A quick look suggest everything works as expected except that inline images, base64 encoded, fail to display.

By accident I discovered that with the older jakarta mail jar added into the lib directory of the exploded war, that problem goes away. I don't understand what's happening in this situation - maybe we are effectively reverting to a 2.0.0 runtime?

I was hoping to create a new jar with a handful of classes from the older jakarta mail, but from what I've tried, either nothing happens or the app no longer runs. So that does not look like a fruitful route.

The only way I can think to demonstrate the issue is to give you a link where you can download the .war, built with the angus/jakarta2.1 jars. you'll need a setup with tomcat, dovecot and a mail exchanger to run tests. If you're prepared to do that, I'll jot some instructions for sending the mail with inline image. Not complicated ; the image is added to the email body by drag and drop.

I think I can guarantee two things:

  1. send the mail to @.*** with my app as sending and receiving client - you'll get an email with a broken image.
  2. stick jakarta mail 2.0.0 in the WEB-INF/lib, logout and restart tomcat - you will now see the same email displays the image - same as happens if the app is built with the older jakarta mail.

Maybe this is not much of a concern to you? Some of the major email providers behave in the same way after all (don't display inline images) - outlook.com for one. I'm not one for sending email with inline images myself, but I've been asked to add this and I just spent a lot of time coding it. So to me it's a regression!

If you have any thoughts about other tests that would be worth a try, but you don't fancy the above necessary setup, I would give them a spin.

-- David Matthews @.***

lukasj commented 10 months ago

can you check presence/absence of various (text) files under META-INF folder in activation/mail - api as well as impl - related jar files?

davcmat commented 10 months ago

can you check presence/absence of various (text) files under META-INF folder?

hi Lukas

@.***:/opt/tomcat/webapps/webmail/META-INF $ ls -l total 4 -rw-r----- 1 david david 110 Jan 18 18:01 MANIFEST.MF -rw-r----- 1 david david 0 Jan 18 18:01 war-tracker

-- David Matthews @.***

jmehrens commented 10 months ago

If you have any thoughts about other tests that would be worth a try, but you don't fancy the above necessary setup, I would give them a spin.

Let's try to see what is happening under the hood on your setup by enabling debugging:

  1. Turn on session debugging. This is mainly done by calling setDebug(true) on the session object which will display output to System.out. If you can't modify the code to do that then I might be able to craft some logger.properties to enable debugging.
  2. Turn on activation debugging by setting system property jakarta.activation.debug=true for JVM. This will display output to System.out.
  3. Run through your test case of generating an email using the lib configuration that works. Save raw email to file. Save your console logs.
  4. Run through your test case of generating an email using the lib configuration that fails. Save raw email to file. Save your console logs.
  5. View and compare the logs. This should point us to a failure.
  6. Compare the emails with a diff tool. This should help show an unexpected difference.

If that doesn't lead any where, then try:

  1. Instead of using the angus-core and the other provider jars try just using all in one angus-mail-XXX.jar for testing purposes.
  2. Try latest angus-mail-2.0.3-SNAPSHOT.jar for testing purposes.
davcmat commented 10 months ago

If you have any thoughts about other tests that would be worth a try, but you don't fancy the above necessary setup, I would give them a spin.

Let's try to see what is happening under the hood on your setup by enabling debugging:

hi

I'm away from home at the moment, but I should be able to do the testing as asked for over the weekend

I can say now though - I'm testing on a maildir system although I use mbox in production; so it's very easy for me to see that it's the interpretation of email that is varying, not what gets assembled and sent.

No matter whether I send with a version compiled with jakarta.mail 2.0.0 or with the new version with the angus jars, the base64 image code is there in the message. Just that with the later version (a la outlook.com) it is not displayed when the message is read.

So I can send mail with the angus version and no image when I receive it, but if I then switch to the older version and read the same message, the image is displayed.

-- David Matthews @.***

davcmat commented 10 months ago

hi again

So now I have two versions of my app - one with jakarta.mail 2.0.0 and one with the angus libs. In this email I call them "old" and "angus"; image means a base64 encoded image that I hope to have displayed at a tag. Points 1 - 6 etc refer to the numbering in your email.

  1. my code has this line:

mailSession = Session.getInstance(System.getProperties());

I inserted a line calling setDebug(true) on the mailSession object. Tthe app's logs look no different:-

2024-01-19 15:54:49,751 INFO DisplayMessage - processing MULTIPART 2 2024-01-19 15:54:49,759 INFO DisplayMessage - removing header Content-ID: from image data

That is expected, both old and angus report this. That says to me that angus sees the image and is trying to load it, but failing quietly as far as my apps logs record.

I try to avoid looking at catalina logs, so what they generally look like I cannot say. However catalina.out has this after the angus version opens an email with an image

DEBUG: setDebug: Jakarta Mail version 2.1.2 DEBUG: getProvider() returning jakarta.mail.Provider[STORE,imap,org.eclipse.angus.mail.imap.IMAPStore,Oracle] DEBUG IMAP: mail.imap.fetchsize: 16384 DEBUG IMAP: mail.imap.ignorebodystructuresize: false DEBUG IMAP: mail.imap.statuscachetimeout: 1000 DEBUG IMAP: mail.imap.appendbuffersize: -1 DEBUG IMAP: mail.imap.minidletime: 10 DEBUG IMAP: closeFoldersOnStoreFailure

There is nothing comparable when the old version reads the same email

  1. I'm not sure i know how to do that? I put that line in conf/logging.properties of the jdk. I've attached a screenshot of the firefox console when I open email, but it's the same for both versions.

  2. Both versions of the app produce identical content when image and text are deliberately the same. The structures of the identical emails are exactly as I expect - a plain text part, html part with the cid image tag and a third part with the base64 data. The angus version cannot display the image in either the email it sent or that sent by the old version. The old version displays the image of both the email it produced and that of the angus version

  3. firefox console logs attached. They are the same when both versions read email and the warning message doesn't seem to refer to the height of the email image as the same warning appears elsewhere in the app where there are no email images. I have no clue what the error message means, there is no favicon.ico in my code.

  4. Maybe the catalina.out (above in point 1) tells you something?

  5. In this case a diff tool would probably confuse - different time/subject headers being of no interest. I deliberately kept the test emails simple and a visual check tells me they are identical where it matters. I've been working on email images for a couple of weeks now and I even have a feeling about what the base64 code should look like :-)

  6. I've already tried the single angus jar rather than the core version with the two protocol jars. Identical result with this.

  7. I don't see that snapshot; send me a link and I'll give it a whirl.

best wishes

  1. Turn on session debugging. This is mainly done by calling setDebug(true) on the session object which will display output to System.out. If you can't modify the code to do that then I might be able to craft some logger.properties to enable debugging.
  2. Turn on activation debugging by setting system property jakarta.activation.debug=true for JVM. This will display output to System.out.
  3. Run through your test case of generating an email using the lib configuration that works. Save raw email to file. Save your console logs.
  4. Run through your test case of generating an email using the lib configuration that fails. Save raw email to file. Save your console logs.
  5. View and compare the logs. This should point us to a failure.
  6. Compare the emails with a diff tool. This should help show an unexpected difference.

If that doesn't lead any where, then try:

  1. Instead of using the angus-core and the other provider jars try just using all in one angus-mail-XXX.jar for testing purposes.
  2. Try latest angus-mail-2.0.3-SNAPSHOT.jar for testing purposes.

-- Reply to this email directly or view it on GitHub: https://github.com/eclipse-ee4j/angus-mail/issues/118#issuecomment-1899314758 You are receiving this because you authored the thread.

Message ID: >@.***>

-- David Matthews @.***

davcmat commented 10 months ago

hi Lucas

Hoping to move forward with the issue, a possibly helpful idea occurs.

Please see the attachments.

The first (admin) is an mbox format folder with a single message. This message was created using the "old" version of my app, running under java21.

The second is a maildir format message. It will be close to, if not identical to the message in the mbox folder, in the details that concern us at the moment. This message was created by the "angus" version of my app, running under java17.

Incidentally my app is behaving identically under the two java versions, so that difference should not be an issue.

So my thought is you can look at the message body in a text editor and actually try reading one of them under whatever system you have, either using mbox or maildir. It remains the case that for me the maildir messages will display a photo in the middle of some text, using my "old" version and fail to display the photo running the "angus" version. So I'm pretty sure you would see the same if you can swap out the angus jars and revert to jakarta2.0.0 in your setup.

Since the mbox folder is from a production system, I don't want to repeat the experiment there, but I've no doubt the result would be the same. I'm pretty sure the issue is in the displaying of messages rather than the construction of them and storage format and java version are not relevant here.

Best wishes

-- David Matthews @.***

jmehrens commented 10 months ago

@davcmat

  1. Since you are using the system properties you can add -Djakarta.activation.debug=true -Dmail.debug=true on the command line. Java -Dproperty=value and Tomcat
  2. Included in my answer for 1. Activation debugging is must useful here anyway because it deals with the content types in the mime message.
  3. I noticed that the FAQ lists 2 ways to display inline images. Might be of help. My concern on this is that they are not identical but rather the method for checking if they are identical is flawed. I might be way off here but, one example is using a text editor to view the two emails and noting they look the same. Where as they need to be compared in a hex editor so you can see non-printable characters. Or do something like:
Message msg = someGeneratedMessage(); 
msg.saveChanges();
try(FileOutputStream fos = new FileOutputStream("some sequenced filename");
OutputStream hex = org.apache.commons.codec.binary.Base16OutputStream(fos)) {
msg.writeTo(hex);
}

on each message and then diff the two messages. Filtering the noise can be an issue though.

  1. On Tomcat the System.out should go in the catalina logs. Full logs are needed but since this is a production system that may not be possible.
  2. It shows that it located the IMAP store but I thought you were using mbox? Ugh... when I check the source code for mbox there is no logger that actually prints debug information.
  3. Let me see how I can get you a snapshot.
  4. That might take me a bit to get an mbox test case setup.
davcmat commented 10 months ago

hi

A quick reply, since it may save you some grief!

I use mbox on my production system, but I deliberately setup a maildir system for development as I want this app of mine to work equally well on both of these. Any testing you want me to do is actually easiest done on the maildir system.

Having said that apart from necessary differences in display, I do have things working equally well (I hope, if not badly!) on either storage backend. I'm 100% sure that the problem I see with images has nothing to do with the mbox/maildir thing and close to certain that it is a problem of display rather than correct assembling of the email.

I say that not only because of the better result with the older version of jakarta.mail, but also since a gmail account will also display the images. I was going to check this is true with the angus version, but that reveals an authentication problem on the production machine that does not occur in testing! I will sort this one out and confirm whether gmail continues to display images as it does with the previous jakarta mail based version

Can I check - I assume this :

  1. Since you are using the system properties you can add -Djakarta.activation.debug=true -Dmail.debug=true on the command line.

can that be put in the setenv.sh file?

I look at that and your other points and get back to you with results.

-- David Matthews @.***

jmehrens commented 10 months ago

Ok snapshots are posted here:

https://jakarta.oss.sonatype.org/content/repositories/staging/org/eclipse/angus/angus-mail/2.0.3-SNAPSHOT/

FYI: with debug logs on you might notice this: https://github.com/eclipse-ee4j/angus-mail/issues/109#issuecomment-1712294111

It shouldn't be an issue just be aware.

According to that SO article, setenv.sh should work.

davcmat commented 10 months ago

Ok snapshots are posted here:

Thanks for that. I can confirm that the 2.0.3 snapshot behaves no differently with regards to the discussed issue, so the problem is not solved with this upgrade.

I've worked around the authentication problem I mentioned on my production machine, by dropping to imap access; I think (^_~) I see a better solution to that though. This enables me to send an inline image email to my "test" gmail account. This pretty much confirms my suspicions of where the problem is.

Just as with my "old" version (with jakarta.mail 2.0), gmail displays the image it's been sent, whereas my app, with the angus snapshot, does not. When I switch back to the "old" version, I can view the image (the test email was cc'd to myself) in the email that the angus version sent.

I'll get on with the other things you asked me to try and get back to you, but pretty categorically the regression, if I may call it that, from v2.0.0 is in the display of an inline image, not the construction of the mime email.

-- David Matthews @.***

davcmat commented 10 months ago

hello again

Hopefully I have some info that will allow things to be pinned down. I stopped tomcat, deleted it's logs and restarted. You can see below that the debug setting you asked for has been accepted? I've downloaded and then attached my setenv.sh so you can check that and also the catalina.out, after viewing the email with the non-displaying inline image.

The version of my app used here has the 2.0.3 angus snapshot and I've kept for now the mailSession.setDebug(true); line.

Rather depressingly I did not resolve the failure to log in via imaps (I added props.setProperty("mail.smtp.ssl.checkserveridentity","false");), but one issue at a time. :-)

Using CATALINA_OPTS: -Xms64m -Xmx512m -XX:+UseParallelGC -XX:MaxGCPauseMillis=1500 -server -XX:+DisableExplicitGC Using JAVA_OPTS: -Djavax.net.ssl.trustStore='/opt/jre-21.0.1/lib/security/cacerts' -Djakarta.activation.debug=true Using CATALINA_BASE: /opt/tomcat Using CATALINA_HOME: /opt/tomcat Using CATALINA_TMPDIR: /opt/tomcat/temp Using JRE_HOME: /opt/jre-21.0.1 Using CLASSPATH: /opt/tomcat/bin/bootstrap.jar:/opt/tomcat/bin/tomcat-juli.jar Using CATALINA_OPTS: -Xms64m -Xmx512m -XX:+UseParallelGC -XX:MaxGCPauseMillis=1500 -server -XX:+DisableExplicitGC Tomcat started.

-- David Matthews @.***

jmehrens commented 10 months ago

That property looks correct. It appears that Jaf-api doesn't print a config/info message that debugging is on. However you should see information about data handling.

davcmat commented 10 months ago

That property looks correct. It appears that Jaf-api doesn't print a config/info message that debugging is on. However you should see information about data handling.

hi

I also sent the catalina.out, did you not look at that?

If I may summarize from my end, I can send email with an inline image from two versions of my app, one with jakarta.mail 2.0 and one with angus mail. In both cases, the older version of my app and a gmail test account show the image and the newer version will not display the image sent by either the older version or by itself.

Maybe you do not see this as important for angus mail? I know that other major providers such as outlook.com do not show such images. I've been working on the assumption you wished to match the features in earlier versions of jakarta.mail, but if not, I'll continue to use the earlier version and warn potential developers about problems with an upgrade from that.

-- David Matthews @.***

jmehrens commented 10 months ago

I also sent the catalina.out, did you not look at that?

I don't see it attached in https://github.com/eclipse-ee4j/angus-mail/issues/118. Maybe I'm just not seeing it? Thoughts?

Maybe you do not see this as important for angus mail?

Angus-mail issues are important. My current understanding from this thread so far is that both old and new produce same bytes for the same email (minus fields that are expected to change). The key to moving this forward is providing evidence of what the runtime sees (full logs, raw email, exact class path version) as opposed to what was configured. Sound like you did that but maybe it got scrubbed. I can see github scrubbed your email address.

davcmat commented 10 months ago

I also sent the catalina.out, did you not look at that?

I don't see it attached in https://github.com/eclipse-ee4j/angus-mail/issues/118. Maybe I'm just not seeing it? Thoughts?

Maybe it got scrubbed on route, I've attached it again here.

I should mention some additional information. I keep a sample of emails I receive that are of interest for development testing. One is a property bill from a South African government authority; it has a banner image inserted by Content-id. I also have another from a protonmail address, where an image has simply been attached as base64 data (ie <img src="data:image/jpeg;base64, ...) into a separate mime part - no cid image tag in other words. My pre-angus version displays both these images, the version with angus will not display either of them. I have forwarded the first of these to my gmail test account, just to make sure my app shows the image in the intended place. Gmail does display it similarly, so I take this as good evidence that my app is behaving correctly if it uses jakarta.mail-2.0.

I'd summarize the evidence as I see it - this is an issue of display, not construction of an email message. I am not solely relying on email generated by the two versions of my own app when I say this, although they both support this contention.

If the angus project is not interested in feature for feature compatibility with jakarta.mail 2.0, well fair enough, inline image seems to be a contentious area anyway, with some major providers not supporting it at all. TBH, I don't care for it myself, but people ask for it. There's no point to me in continuing this conversation if you are treating this as problem in my code. I'm not claiming it's faultless just that evidence seems to strongly point elsewhere in this case.

I am prepared to help with further testing if the goal is to get angus matching the older jakarta.mail in this area, but otherwise I'll just stick with v2.0.

-- David Matthews @.***

jmehrens commented 10 months ago

Maybe it got scrubbed on route, I've attached it again here.

I think you'll have to log in to github and attach the log to the issue using the web UI for me to be able to see it. Or we'll have to come up with another way for me to see it. No rush.

If the angus project is not interested in feature for feature compatibility with jakarta.mail 2.0, well fair enough, inline image seems to be a contentious area anyway, with some major providers not supporting it at all. TBH, I don't care for it myself, but people ask for it.

I'm not exactly sure how to take this. Let me start with first off, thank you for your engagement on this issue. For sure you have put a lot of effort into narrowing down the behavior but we yet to figure out why you are observing what you describe. I do think that you have found an issue that is worthy of perusing regardless of the topic of inline images being contentious. If I thought otherwise I would have closed this issue with a stated reason.

There's no point to me in continuing this conversation if you are treating this as problem in my code. I'm not claiming it's faultless just that evidence seems to strongly point elsewhere in this case.

I think it is best for all parties if we continue to move forward on this issue. Understand that this issue is in a troubleshooting phase of the workflow. If I knew this was problem a with your code I would provide you a minimal reproducible example. I can't do that so it is not. If I ask questions about your code it is for me to gain understanding about what your code does so I can apply that knowledge to examine Angus Mail codebase to spot an issue.

Observation is pointing to a possible regression in JakartaMail, Jakarta Activation, Angus Mail, or Angus Activation. I'm going to try to get Jakarta Activation erroneously assumes that classes can be loaded from Thread#getContextClassLoader reviewed and merged. This will create a new snapshot release that can be tested. Since you are on Tomcat it is possible that this issue is a problem but you would have seen exceptions occurring in your application logs. However, this just a guess because I'm going by observation not evidence (code, logs, and data)

I'd summarize the evidence as I see it - this is an issue of display, not construction of an email message. I am not solely relying on email generated by the two versions of my own app when I say this, although they both support this contention.

This is where my brain breaks because there is no display component in Angus Mail. Display components are jwma, gmail, outlook, etc. Angus Mail only constructs or parses mime messages. You've ruled out construction so that leaves parsing. What am I not understanding?

If this is an Angus Mail problem, which it seems like it is based off your A-B testing, then your application logs should contain evidence of some java.lang.Throwable subclass in it's logs related to one of the 4 projects above or your application should see evidence of a difference in data returned by the MimeMessage that could be tracked in your application. However, you might just want to avoid that work and just test with the new JAF-API snapshot when it is ready.

I am prepared to help with further testing if the goal is to get angus matching the older jakarta.mail in this area, but otherwise I'll just stick with v2.0.

Awesome! I'll continue to work on this issue and update you with a plan to move this forward as time permits. Let me know if there are any other concerns of yours that I have not addressed.

davcmat commented 10 months ago

Maybe it got scrubbed on route, I've attached it again here.

hello

well it's relatively short as I deleted it before logging in and running the tests, so simply copied below here ^_~ I think I spot a load of base64!

OPTIONS: --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED 29-Jan-2024 11:07:34.715 WARNING [main] org.apache.tomcat.util.digester.Digester.endElement No rules found matching [Server/Connector] 29-Jan-2024 11:07:34.754 WARNING [main] org.apache.tomcat.util.digester.Digester.endElement No rules found matching [Server/Connector] 29-Jan-2024 11:07:35.110 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version name: Apache Tomcat/10.0.13 29-Jan-2024 11:07:35.112 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built: Nov 9 2021 22:12:58 UTC 29-Jan-2024 11:07:35.112 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version number: 10.0.13.0 29-Jan-2024 11:07:35.112 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: Linux 29-Jan-2024 11:07:35.112 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version: 6.1.0-17-amd64 29-Jan-2024 11:07:35.113 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture: amd64 29-Jan-2024 11:07:35.114 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home: /opt/jre-21.0.1 29-Jan-2024 11:07:35.114 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: 21.0.1+12-LTS-29 29-Jan-2024 11:07:35.114 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: Oracle Corporation 29-Jan-2024 11:07:35.115 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: /opt/tomcat 29-Jan-2024 11:07:35.115 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: /opt/tomcat 29-Jan-2024 11:07:35.116 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.lang=ALL-UNNAMED 29-Jan-2024 11:07:35.122 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.io=ALL-UNNAMED 29-Jan-2024 11:07:35.123 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.util=ALL-UNNAMED 29-Jan-2024 11:07:35.123 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.util.concurrent=ALL-UNNAMED 29-Jan-2024 11:07:35.124 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED 29-Jan-2024 11:07:35.125 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.config.file=/opt/tomcat/conf/logging.properties 29-Jan-2024 11:07:35.126 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 29-Jan-2024 11:07:35.126 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djavax.net.ssl.trustStore=/opt/jre-21.0.1/lib/security/cacerts 29-Jan-2024 11:07:35.126 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djakarta.activation.debug=true 29-Jan-2024 11:07:35.127 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djdk.tls.ephemeralDHKeySize=2048 29-Jan-2024 11:07:35.127 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources 29-Jan-2024 11:07:35.128 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 29-Jan-2024 11:07:35.128 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Xms64m 29-Jan-2024 11:07:35.128 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Xmx512m 29-Jan-2024 11:07:35.128 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -XX:+UseParallelGC 29-Jan-2024 11:07:35.129 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -XX:MaxGCPauseMillis=1500 29-Jan-2024 11:07:35.129 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -XX:+DisableExplicitGC 29-Jan-2024 11:07:35.129 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dignore.endorsed.dirs= 29-Jan-2024 11:07:35.130 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.base=/opt/tomcat 29-Jan-2024 11:07:35.130 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.home=/opt/tomcat 29-Jan-2024 11:07:35.130 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=/opt/tomcat/temp 29-Jan-2024 11:07:35.133 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The Apache Tomcat Native library which allows using OpenSSL was not found on the java.library.path: [/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib] 29-Jan-2024 11:07:36.304 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-8080"] 29-Jan-2024 11:07:36.391 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["https-jsse-nio-8443"] 29-Jan-2024 11:07:36.932 SEVERE [main] org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to initialize component [Connector[org.apache.coyote.http11.Http11NioProtocol-8443]] org.apache.catalina.LifecycleException: Protocol handler initialization failed at org.apache.catalina.connector.Connector.initInternal(Connector.java:1055) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:556) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1042) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.startup.Catalina.load(Catalina.java:747) at org.apache.catalina.startup.Catalina.load(Catalina.java:769) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source) at java.base/java.lang.reflect.Method.invoke(Unknown Source) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:305) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:475) Caused by: java.lang.IllegalArgumentException: /opt/tomcat/conf/localhost-rsa.jks (No such file or directory) at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:99) at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:71) at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:202) at org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1184) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1197) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:580) at org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:82) at org.apache.catalina.connector.Connector.initInternal(Connector.java:1052) ... 11 more Caused by: java.io.FileNotFoundException: /opt/tomcat/conf/localhost-rsa.jks (No such file or directory) at java.base/java.io.FileInputStream.open0(Native Method) at java.base/java.io.FileInputStream.open(Unknown Source) at java.base/java.io.FileInputStream.(Unknown Source) at java.base/java.io.FileInputStream.(Unknown Source) at java.base/sun.net.www.protocol.file.FileURLConnection.connect(Unknown Source) at java.base/sun.net.www.protocol.file.FileURLConnection.getInputStream(Unknown Source) at org.apache.catalina.startup.CatalinaBaseConfigurationSource.getResource(CatalinaBaseConfigurationSource.java:118) at org.apache.tomcat.util.net.SSLUtilBase.getStore(SSLUtilBase.java:197) at org.apache.tomcat.util.net.SSLHostConfigCertificate.getCertificateKeystore(SSLHostConfigCertificate.java:207) at org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:281) at org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:245) at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:97) ... 18 more 29-Jan-2024 11:07:36.936 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["ajp-nio-0.0.0.0-8009"] 29-Jan-2024 11:07:36.940 INFO [main] org.apache.catalina.startup.Catalina.load Server initialization in [2509] milliseconds 29-Jan-2024 11:07:37.004 INFO [main] java.util.ArrayList.forEach Name = jwmaDB Ignoring unknown property: value of "Derby database for jwma" for "description" property 29-Jan-2024 11:07:37.216 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service [Catalina] 29-Jan-2024 11:07:37.219 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet engine: [Apache Tomcat/10.0.13] 29-Jan-2024 11:07:37.247 INFO [main] org.apache.catalina.startup.HostConfig.deployDescriptor Deploying deployment descriptor [/opt/tomcat/conf/Catalina/localhost/manager.xml] 29-Jan-2024 11:07:37.297 WARNING [main] org.apache.catalina.startup.HostConfig.deployDescriptor The path attribute with value [/manager] in deployment descriptor [/opt/tomcat/conf/Catalina/localhost/manager.xml] has been ignored 29-Jan-2024 11:07:37.957 INFO [main] org.apache.catalina.startup.HostConfig.deployDescriptor Deployment of deployment descriptor [/opt/tomcat/conf/Catalina/localhost/manager.xml] has finished in [709] ms 29-Jan-2024 11:07:37.966 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/opt/tomcat/webapps/butler.war] 29-Jan-2024 11:07:37.977 WARNING [main] org.apache.tomcat.util.digester.SetPropertiesRule.begin Match [Context] failed to set property [antiJARLocking] to [true] 29-Jan-2024 11:07:40.102 INFO [main] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time. 29-Jan-2024 11:07:41.634 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/opt/tomcat/webapps/butler.war] has finished in [3,668] ms 29-Jan-2024 11:07:41.636 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/opt/tomcat/webapps/webmail.war] 29-Jan-2024 11:07:41.703 WARNING [main] org.apache.tomcat.util.descriptor.web.WebXml.setVersion Unknown version string [6.0]. Default version will be used. 29-Jan-2024 11:07:42.869 INFO [main] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time. 29-Jan-2024 11:07:43.351 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/opt/tomcat/webapps/webmail.war] has finished in [1,715] ms 29-Jan-2024 11:07:43.359 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/opt/tomcat/webapps/post.war] 29-Jan-2024 11:07:44.393 INFO [main] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time. 29-Jan-2024 11:07:44.403 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/opt/tomcat/webapps/post.war] has finished in [1,043] ms 29-Jan-2024 11:07:44.407 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/opt/tomcat/webapps/host-manager] 29-Jan-2024 11:07:44.479 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/opt/tomcat/webapps/host-manager] has finished in [71] ms 29-Jan-2024 11:07:44.479 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/opt/tomcat/webapps/ROOT] 29-Jan-2024 11:07:45.781 INFO [main] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time. 29-Jan-2024 11:07:45.792 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/opt/tomcat/webapps/ROOT] has finished in [1,312] ms 29-Jan-2024 11:07:45.801 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8080"] 29-Jan-2024 11:07:45.828 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-0.0.0.0-8009"] 29-Jan-2024 11:07:45.835 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [8883] milliseconds DEBUG: setDebug: Jakarta Mail version 2.1.2 DEBUG: getProvider() returning jakarta.mail.Provider[STORE,imap,org.eclipse.angus.mail.imap.IMAPStore,Oracle] DEBUG IMAP: mail.imap.fetchsize: 16384 DEBUG IMAP: mail.imap.ignorebodystructuresize: false DEBUG IMAP: mail.imap.statuscachetimeout: 1000 DEBUG IMAP: mail.imap.appendbuffersize: -1 DEBUG IMAP: mail.imap.minidletime: 10 DEBUG IMAP: closeFoldersOnStoreFailure DEBUG IMAP: trying to connect to host "localhost", port 143, isSSL false

) A52 OK Fetch completed (0.001 + 0.000 secs). A53 FETCH 1 (ENVELOPE INTERNALDATE RFC822.SIZE)

) A56 OK Fetch completed (0.001 + 0.000 secs). A57 FETCH 2 (ENVELOPE INTERNALDATE RFC822.SIZE)

) A60 OK Fetch completed (0.001 + 0.000 secs). A61 FETCH 3 (ENVELOPE INTERNALDATE RFC822.SIZE)

) A87 OK Fetch completed (0.001 + 0.000 secs). A88 FETCH 1 (ENVELOPE INTERNALDATE RFC822.SIZE)

) A91 OK Fetch completed (0.001 + 0.000 secs). A92 FETCH 2 (ENVELOPE INTERNALDATE RFC822.SIZE)

) A95 OK Fetch completed (0.001 + 0.000 secs). A96 FETCH 3 (ENVELOPE INTERNALDATE RFC822.SIZE)

) A105 OK Fetch completed (0.001 + 0.000 secs). A106 FETCH 1 (BODY.PEEK[HEADER.FIELDS (To)])

) A106 OK Fetch completed (0.001 + 0.000 secs). A107 FETCH 1 (BODYSTRUCTURE)

-- David Matthews @.***

) A108 OK Fetch completed (0.001 + 0.000 secs). A109 FETCH 1 (FLAGS)

) A112 OK Fetch completed (0.001 + 0.000 secs). A113 FETCH 1 (BODY[3]<0.16384>)

davcmat commented 10 months ago

Maybe it got scrubbed on route, I've attached it again here.

hello

well it's relatively short as I deleted it before logging in and running the tests, so simply copied below here ^_~ I think I spot a load of base64!

but not short enough. I had to split it in two, here's part2

A115 FETCH 1 (BODY[3]<32768.16384>)

) A118 OK Fetch completed (0.001 + 0.000 secs). A119 STORE 1 +FLAGS (\Seen) A119 OK Store completed (0.001 + 0.000 secs). DEBUG IMAP: pool is full, not adding an Authenticated connection A120 LOGOUT

) B20 OK Fetch completed (0.001 + 0.000 secs). B21 FETCH 1 (ENVELOPE INTERNALDATE RFC822.SIZE)

) B24 OK Fetch completed (0.001 + 0.000 secs). B25 FETCH 2 (ENVELOPE INTERNALDATE RFC822.SIZE)

) B28 OK Fetch completed (0.001 + 0.000 secs). B29 FETCH 3 (ENVELOPE INTERNALDATE RFC822.SIZE)

) B32 OK Fetch completed (0.001 + 0.000 secs). B33 FETCH 4 (ENVELOPE INTERNALDATE RFC822.SIZE)

) B36 OK Fetch completed (0.001 + 0.000 secs). B37 FETCH 5 (ENVELOPE INTERNALDATE RFC822.SIZE)

) B40 OK Fetch completed (0.001 + 0.000 secs). B41 FETCH 6 (ENVELOPE INTERNALDATE RFC822.SIZE)

) B44 OK Fetch completed (0.001 + 0.000 secs). B45 FETCH 7 (ENVELOPE INTERNALDATE RFC822.SIZE)

) B54 OK Fetch completed (0.001 + 0.000 secs). B55 FETCH 7 (BODY.PEEK[HEADER.FIELDS (To)])

) B55 OK Fetch completed (0.001 + 0.000 secs). B56 FETCH 7 (BODYSTRUCTURE)

https://jakarta.oss.sonatype.org/content/repositories/staging/org/eclipse/angus/angus-mail/2.0.3-SNAPSHOT/

FYI: with debug logs on you might notice this: https://github.com/eclipse-ee4j/angus-mail/issues/109#issuecomment-1712294111

It shouldn't be an issue just be aware.

-- Reply to this email directly or view it on GitHub: https://github.com/eclipse-ee4j/angus-mail/issues/118#issuecomment-1913824969 You are receiving this because you were mentioned.

Message ID: @.***>) B57 OK Fetch completed (0.001 + 0.000 secs). B58 FETCH 7 (FLAGS)

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&m= dash;
Reply to this email directly, <a href=3D"https://github.com/ec= lipse-ee4j/angus-mail/issues/118#issuecomment-1913824969">view it on GitH= ub, or <a href=3D"https://github.com/notifications/unsubscribe-auth/B= FMSA2NDH6HUF4CSDIJKBATYQ35QVAVCNFSM6AAAAABB5HHPLGVHI2DSMVQWIX3LMV43OSLTON= 2WKQ3PNVWWK3TUHMYTSMJTHAZDIOJWHE">unsubscribe.
You are receiving= this because you were mentioned.<img src=3D"https://github.com/notificat= ions/beacon/BFMSA2KPYEB4WNHZK3PKQSDYQ35QVA5CNFSM6AAAAABB5HHPLGWGG33NNVSW4= 5C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTSCKTMS.gif" height=3D"1= " width=3D"1" alt=3D"" /><span style=3D"color: transparent; font-size: 0;= display: none; visibility: hidden; overflow: hidden; opacity: 0; width: = 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message ID: eclipse-ee4j/angus-mail/issues/118/1913824969</span><span>@</span= github.com>

<script type=3D"application/ld+json">[ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/eclipse-ee4j/angus-mail/issues/118#issuecom= ment-1913824969", "url": "https://github.com/eclipse-ee4j/angus-mail/issues/118#issuecommen= t-1913824969", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.": "Organization", "name": "GitHub", "url": "https://github.com" } } ]= ) B59 OK Fetch completed (0.001 + 0.000 secs). B60 FETCH 7 (BODY[2]<0.2534>)

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&m= dash;
Reply to this email directly, <a href=3D"https://github.com/ec= lipse-ee4j/angus-mail/issues/118#issuecomment-1913824969">view it on GitH= ub, or <a href=3D"https://github.com/notifications/unsubscribe-auth/B= FMSA2NDH6HUF4CSDIJKBATYQ35QVAVCNFSM6AAAAABB5HHPLGVHI2DSMVQWIX3LMV43OSLTON= 2WKQ3PNVWWK3TUHMYTSMJTHAZDIOJWHE">unsubscribe.
You are receiving= this because you were mentioned.<img src=3D"https://github.com/notificat= ions/beacon/BFMSA2KPYEB4WNHZK3PKQSDYQ35QVA5CNFSM6AAAAABB5HHPLGWGG33NNVSW4= 5C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTSCKTMS.gif" height=3D"1= " width=3D"1" alt=3D"" /><span style=3D"color: transparent; font-size: 0;= display: none; visibility: hidden; overflow: hidden; opacity: 0; width: = 0; height

davcmat commented 9 months ago

hello

I have to confess egg on face here. I've just realized that my report of regression with inline images is wrong and that my app, with the angus implementation behaves exactly as with jakarta.mail.2.0, and all is good. Including images added with a Content-ID and just base64 data in a separate mime part.

I think, I must have failed to add the activation-api or angus.activation jar when I was testing before. But whatever the reason, I was wrong and I apologize for any wasted time.

-- David Matthews @.***

jmehrens commented 9 months ago

Dave, Were you able to see an exception related to the missing activation-api or angus.activation? You should have seen that show up in the logs as some sort of LinkageError (activation-api missing) or ServiceConfigurationError/IllegalStateException (angus missing).

I ask because there might a minor enhancement I can look at to aid debugging this type of failure.

davcmat commented 9 months ago

Dave, Were you able to see an exception related to the missing activation-api or angus.activation? You should have seen that show up in the logs as some sort of LinkageError (activation-api missing) or ServiceConfigurationError/IllegalStateException (angus missing).

Hi

Did you not see the catalina.out I sent? TBH, I never look at tomcat logs and rely on the log output of my own app, but there the failure was silent, you just saw the broken image graphic that java supplies.

I should emphasize that I'm guessing. I was doing some final testing as I intended to release two versions and was going to say choose between the most up to date version and one that supports displaying inline images. Then I saw that one version covers both! That an activation, or some other jar was missing is just a guess. Against that is the thought that how would everything compile and run perfectly except for displaying inline images if there is an absent dependency?

I have made some pretty minimal changes to my own code (which is still admittedly not very beautiful), but how it worked on jakarta.mail 2.0, but not on angus, until now ... I can't see what changes I've made recently that could make that difference.

I can stick the catalina.out on a server and send you the link if you haven't seen it yet?

Anyway I may release version 5.0 of JWMA as early as tomorrow, if you want to look

https://jwma.sourceforge.net/

It's been in development for 24 years (I took it over about 10 years ago) and I'm pretty pleased with this latest version which I think is a decent example of what can be done with jakarta.mail.

Best wishes

-- David Matthews @.***

jmehrens commented 9 months ago

Did you not see the catalina.out I sent?

No need to re-send. I read it when you attached it inline. No interesting failures as it shows it was able to load Jaf-api.

TBH, I never look at tomcat logs and rely on the log output of my own app, but there the failure was silent, you just saw the broken image graphic that java supplies.

My concern was that the error was in that custom app log. I don't need to see that log because obviously nothing of interest was found there.

That an activation, or some other jar was missing is just a guess. Against that is the thought that how would everything compile and run perfectly except for displaying inline images if there is an absent dependency?

Sounds a lot like my initial response. :) The simple answer is transitive dependencies. JWMA is programmed correctly to only access the API spec (JakartaMail and possibly Jakarta Activation) which gets linked against at compile time. However, both of those rely on matching angus dependencies which are runtime only dependencies of the API spec. The Angus implementations don't participate in compile time linkage in JWMA it is only at runtime when they are class loaded.

I used the AngusMail demos to create a reproducer with -Djakarta.activation.debug=true as you tried on your server.

Here is the normal case with everything working correctly:

java -cp ./demos/logging/target/logging-2.0.3-SNAPSHOT.jar:./../mail/api/target/jakarta.mail-api-2.1.3-SNAPSHOT.jar:./../angus-mail/providers/angus-mail/target/angus-mail-2.0.3-SNAPSHOT.jar:./../jaf-api/api/target/jakarta.activation-api-2.2.0-SNAPSHOT.jar:./../angus-activation/activation-registry/target/angus-activation-2.1.0-SNAPSHOT.jar:./demos/demo/target/demo-2.0.3-SNAPSHOT.jar -Djakarta.activation.debug=true -Djava.util.logging.config.file=../logging.properties example.app.internal.MailHandlerDemo -debug
MimetypesFileTypeMap: load HOME
MimeTypeRegistry: can't load from file - /home/jmehrens/.mime.types; Exception: java.io.FileNotFoundException: /home/jmehrens/.mime.types (No such file or directory)
MimetypesFileTypeMap: load SYS
MimeTypeRegistry: can't load from file - /usr/lib/jvm/jdk-21-oracle-x64/conf/mime.types; Exception: java.io.FileNotFoundException: /usr/lib/jvm/jdk-21-oracle-x64/conf/mime.types (No such file or directory)
MimetypesFileTypeMap: load JAR
MimetypesFileTypeMap: !anyLoaded
MimetypesFileTypeMap: not loading mime types file: /META-INF/mime.types
MimetypesFileTypeMap: load DEF
MimetypesFileTypeMap: successfully loaded mime types file: /META-INF/mimetypes.default
example.app.internal.MailHandlerDemo: java.version=21.0.1
[snip]

The key here is: MimetypesFileTypeMap: successfully loaded mime types file: /META-INF/mimetypes.default Means the application know how to handle image files.

Now if I put a typo in the angus-activation.jar so it is not found on the classpath and re-run this:

java -cp ./demos/logging/target/logging-2.0.3-SNAPSHOT.jar:./../mail/api/target/jakarta.mail-api-2.1.3-SNAPSHOT.jar:./../angus-mail/providers/angus-mail/target/angus-mail-2.0.3-SNAPSHOT.jar:./../jaf-api/api/target/jakarta.activation-api-2.2.0-SNAPSHOT.jar:./../angus-activation/activation-registry/target/angus-activation-2.1.0-SNAPSHOT5.jar:./demos/demo/target/demo-2.0.3-SNAPSHOT.jar -Djakarta.activation.debug=true -Djava.util.logging.config.file=../logging.properties example.app.internal.MailHandlerDemo -debug
MimetypesFileTypeMap: load HOME
Cannot find or load an implementation for MimeTypeRegistryProvider.MimeTypeRegistry: can't load /home/jmehrens/.mime.types; Exception: java.lang.IllegalStateException: Provider for jakarta.activation.spi.MimeTypeRegistryProvider cannot be found
MimetypesFileTypeMap: load SYS
Cannot find or load an implementation for MimeTypeRegistryProvider.MimeTypeRegistry: can't load /usr/lib/jvm/jdk-21-oracle-x64/conf/mime.types; Exception: java.lang.IllegalStateException: Provider for jakarta.activation.spi.MimeTypeRegistryProvider cannot be found
MimetypesFileTypeMap: load JAR
MimetypesFileTypeMap: !anyLoaded
MimetypesFileTypeMap: not loading mime types file: /META-INF/mime.types
MimetypesFileTypeMap: load DEF
Cannot find or load an implementation for MimeTypeRegistryProvider.MimeTypeRegistry: can't load /META-INF/mimetypes.default; Exception: java.lang.IllegalStateException: Provider for jakarta.activation.spi.MimeTypeRegistryProvider cannot be found
example.app.internal.MailHandlerDemo: java.version=21.0.1
[snip]

The Provider for jakarta.activation.spi.MimeTypeRegistryProvider cannot be found is the error that we should have seen when your system was running with -Djakarta.activation.debug=true I'm using the newest snapshot so older errors would look like: https://github.com/jakartaee/mail-api/issues/624. Difference of RuntimeException vs. IllegalStateException in the message. If JakartaActivation doesn't have a mapping for the image format it can't encode/decode that format. From the logs we didn't load any entries in the MimetypesFileTypeMap.

So the outcome of this thread is I'll look at creating an enhancement to make empty MimetypesFileTypeMap easier to debug or fail faster. More work and research to do there.

Anyway I may release version 5.0 of JWMA as early as tomorrow, if you want to look

https://jwma.sourceforge.net/ It's been in development for 24 years (I took it over about 10 years ago) and I'm pretty pleased with this latest version which I think is a decent example of what can be done with jakarta.mail.

That is good news! Not sure if you are aware but JWMA is listed in Angus Third-Party Products. It is great you are able to showcase JakartaMail.

jmehrens commented 9 months ago

Duplicate of https://github.com/jakartaee/mail-api/issues/624 Will create a new tickets to help with missing implementations.

davcmat commented 9 months ago

hi

However, both of those rely on matching angus dependencies which are runtime only dependencies of the API spec. The Angus implementations don't participate in compile time linkage in JWMA it is only at runtime when they are class loaded.

That's mystery solved then. I was to-ing and throw-ing my build environment between the older jakarta.mail (just 2 jars) and angus. Very easy to leave out one jar that's only needed at runtime, do some very thorough testing and come to the wrong conclusion :-)

The real bitch for me was that I'd (finally) got around to implementing handling of inline images, which I have no interest in myself for day to day use, rather just as a programming challenge.

Case closed I say.

-- David Matthews @.***