[Java] mime types in linux vs Windows

[Standeman]

Ik heb een beetje een vaag probleem ik vermoed dat het ergens in de installatie van de JRE zit, maar ik kan er mijn vinger niet helemaal op leggen.

Ik heb een stukje code dat e-mails verstuurd met een pdf als attachement. Nu werkt het op zich prima en als ik de code run op mijn ontwikkelmachine (Windows Vista) krijg ik het goede resultaat, zoals het hoort.

------=_Part_0_31662978.1270555336632
Content-Type: application/pdf; name="foo.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="foo.pdf"

Echter, als ik code run op onze test-machine (RH Linux) wordt om de een of andere reden de content type niet goed neergezet

------=_Part_0_14358558.1270554217229
Content-Type: text/plain; name="foo.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="foo.pdf"

Het stukje code dat de attachement in elkaar zet is in beide gevallen identiek:

Java:

for (MessageData md : data)
{
    byte[] attachement = md.getData();
    if (attachement != null && attachement.length > 0)
    {
        MimeBodyPart mdp = new MimeBodyPart();
        // md.getMimeType() geeft ten alle tijden application/pdf terug.
        DataSource source = new ByteArrayDataSource(md.getData(), md.getMimeType());
        mdp.setDataHandler(new DataHandler(source));
        mdp.setFileName(md.getFileName());
        mdp.setDisposition(Part.ATTACHMENT);
        multipart.addBodyPart(mdp);
    }
}

Ik heb al gezocht op de keywords "java mail linux mime type", maar daar kan ik weinig vinden over mijn probleem.

In de javadoc kwam ik tegen dat je een mime.types bestandje in de META-INF dir kan zetten. Dat heb ik uiteraard gedaan:

code:

application/pdf pdf

Alleen blijkt dit uit te maken en verandert er niets in de gestuurde e-mail

Iemand enig idee hoe dit op te lossen?

[Hydra]

Heb je ook daadwerkelijk een MimetypesFileTypeMap gebruikt dan? Daar heb je het niet over nl. Alleen dat bestandje daar zetten doet niks.

Heb er zelf geen ervaring mee, maar probeer eens iets als:

Java:

FileTypeMap.getDefaultFileTypeMap().addMimeTypes("application/pdf pdf");

Als je daarna via een FileDataSource die file ophaalt zou 'ie als het goed is die mimetype moeten herkennen.

[Standeman]

Hydra schreef op dinsdag 06 april 2010 @ 15:22:
Heb je ook daadwerkelijk een MimetypesFileTypeMap gebruikt dan? Daar heb je het niet over nl. Alleen dat bestandje daar zetten doet niks.

Dat zou het juist wel moeten doen:

MIME types file search order:

The MimetypesFileTypeMap looks in various places in the user's system for MIME types file entries. When requests are made to search for MIME types in the MimetypesFileTypeMap, it searches MIME types files in the following order:

1. Programmatically added entries to the MimetypesFileTypeMap instance.
2. The file .mime.types in the user's home directory.
3. The file <java.home>/lib/mime.types.
4. The file or resource named META-INF/mime.types.
5. The file or resource named META-INF/mimetypes.default (usually found only in the activation.jar file).

Ik kan nog even kijken, aangezien ik twee META-INF dir's heb. Namelijk /WEB-INF/classes/META-INF en /META-INF. Op het moment staat het nu alleen in eerste.

Heb er zelf geen ervaring mee, maar probeer eens iets als:

Java:

FileTypeMap.getDefaultFileTypeMap().addMimeTypes("application/pdf pdf");

Als je daarna via een FileDataSource die file ophaalt zou 'ie als het goed is die mimetype moeten herkennen.

hmmm, maar dan moet ik 'm eerst op disk gaan weggschrijven vziw en dat is is jammer omdat disk-io vrij veel tijd kost. Ik zal het in iedergeval even uitproberen.

[ Voor 42% gewijzigd door Standeman op 06-04-2010 15:50 ]

[Hydra]

Standeman schreef op dinsdag 06 april 2010 @ 15:44:
hmmm, maar dan moet ik 'm eerst op disk gaan weggschrijven vziw. Ik zal het in iedergeval even uitproberen.

Als het goed is wordt DataSource.getContentType() aangeroepen om te bepalen welk contenttype het is, dus je kunt ook altijd je eigen DataSource implementatie maken en gewoon hard het juiste contenttype meegeven.

[Soultaker]

Als ik Standeman's post goed gelezen heb, dan geeft md.getMimeType() altijd het goede type terug, en dat type wordt weer meegegeven aan de constructor van de ByteArrayDataSource. Dan zou 'ie toch nergens kwijtgeraakt moeten zijn?

[Standeman]

Soultaker schreef op dinsdag 06 april 2010 @ 16:07:
Als ik Standeman's post goed gelezen heb, dan geeft md.getMimeType() altijd het goede type terug, en dat type wordt weer meegegeven aan de constructor van de ByteArrayDataSource. Dan zou 'ie toch nergens kwijtgeraakt moeten zijn?

Klopt idd. En ik zit me af te vragen waarom dit wel werkt op mijn windows machine en niet op mijn linux-servertje. Ik begin een bug te vermoeden.

[Hydra]

Standeman schreef op dinsdag 06 april 2010 @ 16:10:
Klopt idd. En ik zit me af te vragen waarom dit wel werkt op mijn windows machine en niet op mijn linux-servertje. Ik begin een bug te vermoeden.

Ik weet niet precies hoe het in Linux geregeld is maar ik vermoed dat de onderliggende implementatie onder windows in de registry kijkt, en de onderliggende implementatie onder Linux geen verwijzing kan vinden. Zelf een wrapper class om ByteArrayDataSource maken die altijd de juiste mime-type teruggeeft is de snelste oplossing vermoed ik

Edit: Ik moet leren lezen

Als je zeker weet dat die MessageData de juiste type teruggeeft (heb je dat echt gecontroleerd) dan lijkt het idd gewoon een bug.

[ Voor 11% gewijzigd door Hydra op 06-04-2010 16:17 ]

[Standeman]

Ik heb het nog niet geprobeerd omdat het nogal een heel proces is om de applicatie te bouwen en te deployen op de test-server. Even wat nieuwe classes neerzetten werkt hier niet echt.

Helaas kan ik ook geen sources vinden van Jaf 1.1 om even in te spieken

Zojuist dit gevonden. Komt redelijk overeen met mijn probleem.

[ Voor 55% gewijzigd door Standeman op 06-04-2010 16:35 ]

[Cobalt]

Het lijkt een beetje op deze bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4243731

[ Voor 67% gewijzigd door Cobalt op 06-04-2010 17:33 ]

[Standeman]

Cobalt schreef op dinsdag 06 april 2010 @ 17:28:
Het lijkt een beetje op deze bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4243731

Dat vond ik ook al

[Remus]

Welke JavaMail versie, en weet je zeker dat je RedHat variant niet per ongeluk de GNU JavaMail implementatie laadt?

[Standeman]

Alleen javamail1.4 staat in de classpath van Tomcat. (in de lib van de app)

Overigens, wanneer ik het volgende log:

Java:

  log.debug("mdp.getContentType() : " + mdp.getContentType());
  log.debug("source.getContentType() : " + source.getContentType());

geeft mdp terug: text/plain
geeft source terug: application/pdf

In beide omgevingen.

Even voor de goede orde, mijn hele message ziet er alsvolgt uit:

Java:

MimeMessage mimeMessage = new MimeMessage(session);
mimeMessage.setFrom(new InternetAddress(from));
mimeMessage.addRecipient(javax.mail.Message.RecipientType.TO, recipient);
mimeMessage.setSubject("Hier is uw pdf");

BodyPart messageBodyPart = new MimeBodyPart();
messageBodyPart.setText("Hier is uw pdf");

Multipart multipart = new MimeMultipart();
multipart.addBodyPart(messageBodyPart);
for (MessageData md : data)
{
    byte[] attachement = md.getData();
     if (attachement != null && attachement.length > 0)
    {
        MimeBodyPart mdp = new MimeBodyPart();
        DataSource source = new ByteArrayDataSource(md.getData(), md.getMimeType());
        mdp.setDataHandler(new DataHandler(source, md.getMimeType()));
        mdp.setFileName(md.getFileName());
        mdp.setDisposition(Part.ATTACHMENT);
        multipart.addBodyPart(mdp);
     }
 }
mimeMessage.setContent(multipart);
Transport.send(mimeMessage);

Update:
Ik heb net een kleine app gebouwd en in mijn home dir uitgevoerd (zonder tomcat e.d.). Blijkt dat het dan prima werkt. Waarschijnlijk wordt er toch ergens een andere jar geladen. Even kijken hoe ik er achter ga komen welke dat is.

Ik heb zo'n hekel aan dit soort dingen

Update2:
Eindelijk opgelost. Bleek er nog een aantal oude jar files te staan in de common/lib van tomcat

Had dus niets met windows vs linux te maken.

[ Voor 131% gewijzigd door Standeman op 07-04-2010 09:43 ]

[Remus]

Standeman schreef op woensdag 07 april 2010 @ 07:29:
Update2:
Eindelijk opgelost. Bleek er nog een aantal oude jar files te staan in de common/lib van tomcat

Gelukkig maar Altijd vervelend als dit soort bestanden op onverwachte plaatsen staan (of erger nog in de lib/ext folder van je JRE)