apache.commons.mail - Sending the email to the following server failed
Bertram Hurtig
nutze das apache.commons.mail Paket, Version 1.3.3.
Nun würde ich gerne testweise eine kleine Email über GMX versenden:
<code>
SimpleEmail email = new SimpleEmail();
email.addTo(TO_USER);
email.setHostName("smtp.gmx.de");
email.setFrom(FROM_USER);
email.setSubject(SUBJECT);
email.setMsg(MAIL_TEXT);
email.setAuthentication(USERNAME, PASSWORD);
email.send();
</code>
Das klappt aber leider nicht, Fehlermeldung ist:
--------------------------------------------------
SCHWERWIEGEND: Cannot send mail to B.Hu...@gmx.de
Sending the email to the following server failed : smtp.gmx.de:25
org.apache.commons.mail.EmailException: Sending the email to the
following server failed : smtp.gmx.de:25
at org.apache.commons.mail.Email.sendMimeMessage(Email.java:873)
at org.apache.commons.mail.Email.send(Email.java:898)
[...]
Caused by: javax.mail.NoSuchProviderException: smtp
at javax.mail.Session.getService(Session.java:764)
at javax.mail.Session.getTransport(Session.java:689)
at javax.mail.Session.getTransport(Session.java:632)
at javax.mail.Session.getTransport(Session.java:612)
at javax.mail.Session.getTransport(Session.java:667)
at javax.mail.Transport.send0(Transport.java:148)
at javax.mail.Transport.send(Transport.java:80)
at org.apache.commons.mail.Email.sendMimeMessage(Email.java:863)
... 3 more
--------------------------------------------------
Irgendeine Idee was da falsch läuft?
Zunächst habe ich gelesen, es könnte an den transitiven Dependencies
hängen - jetzt habe ich aber echt ALLES direkt in meinen Classpath
gehängt (aber trotzdem gehts nicht):
--------------------------------------------------
<classpathentry kind="var"
path="M2_REPO/commons-email/commons-email/1.0/commons-email-1.0.jar"/>
<classpathentry kind="var"
path="M2_REPO/javax/mail/mail/1.3.3/mail-1.3.3.jar"/>
<classpathentry kind="var"
path="M2_REPO/javax/activation/activation/1.0.2/activation-1.0.2.jar"/>
<classpathentry kind="var"
path="M2_REPO/dumbster/dumbster/1.6/dumbster-1.6.jar"/>
--------------------------------------------------
Auf der Apache Commonsseite habe ich gelesen:
If you need to authenticate to your SMTP server, you can call the
setAuthentication(userName,password) method before sending your email.
This will create an instance of DefaultAuthenticator which will be used
by the JavaMail API when the email is sent. Your server must support
RFC2554 in order for this to work.
--------------------------------------------------
Unterstüzt Gmx RFC2554 (was immer das bedeutet...)?
Auch mit meinen privaten Emailaccount meines Webserver Providers hab
ich's probiert, aber es will nicht... :-(
Wäre total lieb wenn ihr mir hier aushelfen könntet! :-)
Danke euch,
Bertram
Bernd Hohmann
> [...]
> Caused by: javax.mail.NoSuchProviderException: smtp
> at javax.mail.Session.getService(Session.java:764)
[...]
> path="M2_REPO/commons-email/commons-email/1.0/commons-email-1.0.jar"/>
> path="M2_REPO/javax/mail/mail/1.3.3/mail-1.3.3.jar"/>
Wenn ich mich recht entsinne, machen beide Pakete das Gleiche
(commons-email unterstützt allerdings keine Authentifizierung).
Lass mal nur mail-1.3.3 drin oder commons-email
> --------------------------------------------------
> Unterstüzt Gmx RFC2554 (was immer das bedeutet...)?
Ja. http://www.faqs.org/rfcs/rfc2554.html
Wenn man über die API irgendwo einstellen kann, welche Art der
Authentifizierung genutzt wird, stell das auf "CRAM-MD5" oder "PLAIN"
Bernd
--
Unsere Identität entnehmen Sie bitte dem beigefügten Auszug aus
den Personenstandsbüchern. Gegen die Assimilierung in unser
Kollektiv ist nach dem ABGB (§66.4) kein Rechtsmittel zulässig.
Ralf Isken
die Fehlermeldung sagts eigentlich schon. Den Server gibt es nicht!
Bertram Hurtig schrieb:
> <code>
> SimpleEmail email = new SimpleEmail();
> email.addTo(TO_USER);
> email.setHostName("smtp.gmx.de");
^^^^^^^^^^^
[...]
> Das klappt aber leider nicht, Fehlermeldung ist:
> --------------------------------------------------
> SCHWERWIEGEND: Cannot send mail to B.Hu...@gmx.de
> Sending the email to the following server failed : smtp.gmx.de:25
> org.apache.commons.mail.EmailException: Sending the email to the
> following server failed : smtp.gmx.de:25
> at org.apache.commons.mail.Email.sendMimeMessage(Email.java:873)
> at org.apache.commons.mail.Email.send(Email.java:898)
> [...]
> Caused by: javax.mail.NoSuchProviderException: smtp
^^^^^^^^^^^^^^^^^^^^^^^
Meines Wissens heißt der SMTP-Server bei GMX mail.gmx.net
Versuchs mal damit. vielleicht kommst Du ja damit weiter.
Ciao
Ralf
Vince
ich hatte vor einiger Zeit ähnliche Probleme mit dem Verschicken von
Mails und vorallem mit der Authentisierung. Habe es mit den 2 folgenden
Klassen gelöst, vielleicht hilft es Dir weiter:
Es muss dabei beachtet werden dass alle "ApplicationProperties.xxx"
statische Variablen sind die ich in einer eigenen Klasse habe... Bei den
variablen handelt es sich immer um Strings.
Das Objekt wird dann wie folgt angesprochen und ausgeführt:
new MailSender().sendMail(String strTo, String strCc, String strBody,
String strSubject)
******** MailSender.java *********
import java.util.Date;
import java.util.Properties;
import javax.mail.Authenticator;
import javax.mail.Message;
import javax.mail.MessagingException;
import javax.mail.Session;
import javax.mail.Transport;
import javax.mail.internet.AddressException;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeMessage;
import appl.constants.ApplicationProperties;
public class MailSender {
/**
* Constructor
*/
public MailSender() {
}
public static void sendMail(String strTo, String strCc, String strBody,
String strSubject) throws AddressException, MessagingException{
//Setting SMTP Host
Properties props = System.getProperties();
props.put("mail.transport.protocol", "smtp");
props.put("mail.host", ApplicationProperties.MAIL_SMTP_HOST);
props.put("mail.smtp.auth", "true");
//Setting AUTH
Authenticator auth = new SMTPAuthenticator();
//Attaching to default Session
Session session = Session.getDefaultInstance(props,auth);
//Create the Message
Message msg = new MimeMessage(session);
//Set the FROM
msg.setFrom(new InternetAddress(ApplicationProperties.MAIL_FROM));
//Set the TO
msg.setRecipients(Message.RecipientType.TO,
InternetAddress.parse(strTo, false));
//Set the CC
if (strCc != null){
msg.setRecipients(Message.RecipientType.CC
,InternetAddress.parse(strCc, false));
}
//Set the SUBJECT
msg.setSubject(strSubject);
//Set the BODY
msg.setContent(strBody, "text/html");
//Change HEADER
msg.setSentDate(new Date());
//Set the Transport
Transport trans = session.getTransport();
trans.connect();
//Send Message
trans.send(msg);
//Close Trasport
trans.close();
}
}
******** SMTPAuthenticator.java *********
import javax.mail.PasswordAuthentication;
import appl.constants.ApplicationProperties;
public class SMTPAuthenticator extends javax.mail.Authenticator {
public PasswordAuthentication getPasswordAuthentication() {
String username = ApplicationProperties.MAIL_USER;
String password = ApplicationProperties.MAIL_PWD;
return new PasswordAuthentication(username, password);
}
}
Viele Grüsse
Vince
--
Posted via a free Usenet account from http://www.teranews.com
Bertram Hurtig
> Lass mal nur mail-1.3.3 drin oder commons-email
commons-email braucht java mail. Ohne gings nicht.
> Wenn man über die API irgendwo einstellen kann, welche Art der
> Authentifizierung genutzt wird, stell das auf "CRAM-MD5" oder "PLAIN"
Ich denke nicht dass das geht - man kann zwar für die Authentifizierung
einen eigenen "Authenticator" bereitstellen, der kann aber nur eine
Methode überschreiben (z.B. um die Benutzerdaten über eine Maske
einzugeben), die die Zugangsdaten bereitstellt, alle anderen Methoden
sind final. Ich denke auch nicht dasss das Problem ist. Wenn du sagst
GMX unterstüzt RFC2554, dann sollte es doch unter normalen Umständen
gehen???
Gerade habe ich auch noch den Port kontrolliert. Port 25 wird von GMX
unterstützt - und wenn ich mit meinem Emailprogramm auf Port 25
empfangen kann, dann müßte doch folglich auch die Firewall den Port
durchlassen? Mit Port 587 funktioniert es auch nicht.
AAAAH Ich bin verzweifelt!!! :-(
Bertram
Michael Paap
> nutze das apache.commons.mail Paket, Version 1.3.3.
Offenbar nicht. Wenn ich deine Classpath-Entries unten richtig verstehe,
benutzt du das Paket Apache Commons Email 1.0, sowie javax.mail in der
Version 1.3.3.
> <code>
> SimpleEmail email = new SimpleEmail();
> email.addTo(TO_USER);
> email.setHostName("smtp.gmx.de");
> email.setFrom(FROM_USER);
> email.setSubject(SUBJECT);
> email.setMsg(MAIL_TEXT);
> email.setAuthentication(USERNAME, PASSWORD);
> email.send();
> </code>
Sieht erst mal ok aus.
> <classpathentry kind="var"
> path="M2_REPO/commons-email/commons-email/1.0/commons-email-1.0.jar"/>
> <classpathentry kind="var"
> path="M2_REPO/javax/mail/mail/1.3.3/mail-1.3.3.jar"/>
> <classpathentry kind="var"
> path="M2_REPO/javax/activation/activation/1.0.2/activation-1.0.2.jar"/>
> <classpathentry kind="var"
> path="M2_REPO/dumbster/dumbster/1.6/dumbster-1.6.jar"/>
Das passt zu den in der Doku angegebenen Abhängigkeiten.
> Irgendeine Idee was da falsch läuft?
Höchstwahrscheinlich hast du außer mail-1.3.3 noch weitere Versionen der
Sun Javamail Bibliothek im Classpath.
Liegt da vielleicht noch was im ext-Verzeichnis des JRE? Oder ist eine
globale CLASSPATH-Variable gesetzt?
Gruß,
Michael
Michael Paap
> Wenn ich mich recht entsinne, machen beide Pakete das Gleiche
> (commons-email unterstützt allerdings keine Authentifizierung).
>
> Lass mal nur mail-1.3.3 drin oder commons-email
Du entsinnst dich nicht recht. commons-email benötigt javax-mail.
Gruß,
Michael
Vince
>
> die Fehlermeldung sagts eigentlich schon. Den Server gibt es nicht!
>
Ein ping auf smtp.gmx.de antwortet positiv und wird korrekt (wie Du
sagtest) auf mail.gmx.de umgeleitet. Ob nun smtp oder mail verwendet
wird sollte keine Rolle spielen.
Mein Post von 17:42 könnte die Lösung bringen... hatte wie gesagt sehr
ähnliche Probleme und es lag am Format und der Authentizierung...
Gruss Vince
Michael Paap
> Meines Wissens heißt der SMTP-Server bei GMX mail.gmx.net
> Versuchs mal damit. vielleicht kommst Du ja damit weiter.
debian:~# telnet smtp.gmx.de 25
Trying 213.165.64.20...
Connected to mail.gmx.net.
Escape character is '^]'.
220 mail.gmx.net GMX Mailservices ESMTP {mp044}
Gruß,
Michael
Achim Peters
[Quote umgestellt]
> Bertram Hurtig schrieb:
>> <code>
>> SimpleEmail email = new SimpleEmail();
>> email.addTo(TO_USER);
>> email.setHostName("smtp.gmx.de");
> ^^^^^^^^^^^
> [...]
>> Das klappt aber leider nicht, Fehlermeldung ist:
>> --------------------------------------------------
>> SCHWERWIEGEND: Cannot send mail to B.Hu...@gmx.de
>> Sending the email to the following server failed : smtp.gmx.de:25
>> org.apache.commons.mail.EmailException: Sending the email to the
>> following server failed : smtp.gmx.de:25
>> at org.apache.commons.mail.Email.sendMimeMessage(Email.java:873)
>> at org.apache.commons.mail.Email.send(Email.java:898)
>> [...]
>> Caused by: javax.mail.NoSuchProviderException: smtp
> ^^^^^^^^^^^^^^^^^^^^^^^
> die Fehlermeldung sagts eigentlich schon. Den Server gibt es nicht!
Doch, wie man leicht feststellen kann.
| $ telnet smtp.gmx.de 25
| Trying 213.165.64.20...
| Connected to mail.gmx.net.
| Escape character is '^]'.
| 220 mail.gmx.net GMX Mailservices ESMTP {mp029}
Bye
Achim
Michael Konietzka
Gerade in ähnlicher Konfiguration ohne Probleme gemacht.
Die Meldung "Caused by: javax.mail.NoSuchProviderException: smtp" kommt
daher, daß er die Provider-Konfiguration für das smtp-Protokoll nicht
findet.
Diese befinden sich im "mail.jar" im META-INF und werden wohl als
Resource geladen.
zB über META-INF/javamail.default.providers:
# JavaMail IMAP provider Sun Microsystems, Inc
protocol=imap; type=store; class=com.sun.mail.imap.IMAPStore; vendor=Sun
Microsystems, Inc;
protocol=imaps; type=store; class=com.sun.mail.imap.IMAPSSLStore;
vendor=Sun Microsystems, Inc;
# JavaMail SMTP provider Sun Microsystems, Inc
protocol=smtp; type=transport; class=com.sun.mail.smtp.SMTPTransport;
vendor=Sun Microsystems, Inc;
protocol=smtps; type=transport;
class=com.sun.mail.smtp.SMTPSSLTransport; vendor=Sun Microsystems, Inc;
# JavaMail POP3 provider Sun Microsystems, Inc
protocol=pop3; type=store; class=com.sun.mail.pop3.POP3Store; vendor=Sun
Microsystems, Inc;
protocol=pop3s; type=store; class=com.sun.mail.pop3.POP3SSLStore;
vendor=Sun Microsystems, Inc;
Wird nun aber durch ungünstige ClassLoader/Classpath-Konfiguration die
javax.mail.Session an anderer Stelle geladen, so findet er die Ressource
womöglich nicht mehr.
Wenn du das Versenden aus einem EJB- oder Servletcontainer heraus
startest, kann es sein, daß dort schon ein mail-x.x.x.jar eingebunden
ist. Diese behaken sich dann.
Ich erinnere mich vage, solche Probleme beim Versenden aus einem EJB
heraus gehabt zu haben, da der EJB-Container schon entsprechend ein
mail.jar in einer bestimmten Version eingebunden hatte.
Als Lösung ist dann geeignetet das Classloading zu konfigurieren.
Schau doch mal nach, falls du aus einem Container oder ähnlichem heraus
ein mail-x.x.x.jar an anderer Stelle im System hast.
Grüße
Michael
Bernd Hohmann
>> Lass mal nur mail-1.3.3 drin oder commons-email
>
> commons-email braucht java mail. Ohne gings nicht.
Stimmt. Hat mir Michael gerade in einem anderen Posting geschrieben.
google "javax.mail.NoSuchProviderException: smtp" bringt so einiges, ich
tippe mittlereile auch auf mehrere eingebundene mail.jar wie das Michael
Konietzka beschrieben hat.
> Ich denke auch nicht dasss das Problem ist. Wenn du sagst
> GMX unterstüzt RFC2554, dann sollte es doch unter normalen Umständen
> gehen???
RFC 2554 beschreibt nur wie die Authentifizierung insgesamt läuft, aber
keine Details über die verwendete Methode. Normalerweise sendet der
Server zurück, welche Methoden er unterstützt und normalerweise muss der
Client sich darauf einstellen. GMX schickt 2 Zeilen mit
unterschiedlichen Versionen des Feature-Strings, das hat schon so manche
Implementation verwirrt.
Aber Dein Problem liegt nicht an der Authentifizierung sondern daran,
dass er den Transportlayer für SMTP nicht gefunden hat.
> AAAAH Ich bin verzweifelt!!! :-(
Ich hab gerade in die Sourcen geschaut, nun bin ich es auch.
Closed Source Software: binary only (mangels Quellcode nicht wartbar)
Open Source Software: binary only (wegen Quellcode nicht wartbar)
Ralf Ullrich
Ist das wieder mal traurig. Die Fehlerursache ist eindeutig aus Betrams
Posting zu entnehmen, womit völlig klar ist, wo man den Fehler zu suchen
hat, aber alle raten nur wieder wild rum in allen möglichen und
unmöglichen Richtungen, statt zielgerichtet das Problem anzugehen. Das ist
bestenfalls ein Rezept jede Menge Zeit zu verplempern aber doch keine Hilfe!
Also:
Bertram Hurtig wrote:
>Das klappt aber leider nicht, Fehlermeldung ist:
[...]
>Caused by: javax.mail.NoSuchProviderException: smtp
Ergo: Java Mail findet über den Java Activation Framework den SMTP
Transport Provider nicht.
Damit ist schonmal klar, es kann sich nur um ein Problem mit dem
Class-Path handeln, auch wenn noch nicht ganz klar ist, welches.
Bertram scheint dies im Gegensatz zu den hilfsbereiten Ahnungslosen, die
vor Michael Paap geantwortet haben, auch klar zu sein, denn er versucht
alles anzugeben, was bei der Fehlerfindung von Bedeutung sein könnte.
> <classpathentry kind="var" path="M2_REPO/javax/mail/mail/1.3.3/mail-1.3.3.jar"/>
Bei Java Mail gibt es mehrere "Verpackungen" der beteiligten APIs. Da du
offenbar ein Maven-Repository nimmmst, wäre ich mir nicht mehr sicher ob
die originale Namensgebung beibehalten wurde, "mail-1.3.3.jar" ist
jedenfalls kein offizieller Name für ein Java Mail JAR.
Java Mail befindet sich im Original in "mailapi.jar", und dazu gibt es
dann noch einige Provider JARs wie "smtp.jar", "pop3.jar", "imap.jar". Es
gibt aber auch eine JAR in der alles zusammengefasst ist, die heißt im
Original "mail.jar".
Ich würde nun raten, dass bei der Zusammenstellung des Maven Repositories
aus "mailapi.jar" das von dir verwendete "mail-1.3.3.jar" wurde. Wenn ja
müsste sich dein Problem lösen, wenn du das hier (Bezeichner geraten!)
aufnimmst:
> <classpathentry kind="var" path="M2_REPO/javax/mail/mail/1.3.3/smtp-1.3.3.jar"/>
Wenn es das nicht ist, dann musst du deinen ClassPath genauer untersuchen,
und da ist dann auch Michaels Idee mit den ext-Verzeichnissen ein guter
Platz.
Jedenfalls brauchst du den Fehler erstmal nirgends anders suchen als im
ClassPath, bis du wenigstens ein anderes Caused-By erhältst, stimmen
sowohl Code als auch alles weitere.
cu
PS: sehe gerade, während ich dies schrieb hat Michael Konietzka auch noch
eine kompetente Antwort geschrieben.
Bertram Hurtig
dein Quellcode kommt mir sehr bekannt vor, und zwar von:
http://www.tutorials.de/forum/java/255387-email-mit-javamail-versenden.html
Den Quellcode hatte ich auch schon probiert, und auch damit läuft es
nicht (auch nicht mit deiner angepassten Version) - obwohl beide laufen
sollten. Es muss wohl wirklich irgendwas anderes sein, wie falsch
definierte Abhängigkeiten...????
(Kann aber nichts finden, ich habe als libraries NUR NOCH javax.mail und
das dazu nötige activation jar...
Danke,
Bertram
Michael Konietzka
> Caused by: javax.mail.NoSuchProviderException: smtp
[..]
JavaMail
FAQ
"Q: My servlet can find the JavaMail classes, but JavaMail complains
that it can't find a service provider for "smtp" or "imap" or address
type "rfc822".
A: Usually this is because JavaMail can't access the configuration files
in mail.jar, possibly because of a security permission problem; see this
item for more details. Also, make sure that you haven't extracted the
mail.jar contents; you should include the unmodified mail.jar file in
the server's CLASSPATH."
"Q: I'm sure I've set my CLASSPATH correctly, but I'm still getting
complaints about classes that can't be found, such as com.sun.mail
classes. [new!]
A: The most common cause of problems like this is having more than one
copy of mail.jar in your CLASSPATH or available to your application. In
addition to checking your CLASSPATH setting, also look for copies in the
jre/lib/ext directory of your JDK installation. If you're running in a
web server or application server, it may be providing its own version of
mail.jar in one of its directories. You should only have one version of
mail.jar available to your application."
[http://java.sun.com/products/javamail/FAQ.html#servletSecurityManager]
etc.
...
;-)
Bernd Hohmann
> Mei O mei O mei!
>
> Ist das wieder mal traurig. Die Fehlerursache ist eindeutig aus Betrams
> Posting zu entnehmen, womit völlig klar ist, wo man den Fehler zu suchen
> hat, aber alle raten nur wieder wild rum in allen möglichen und
> unmöglichen Richtungen, statt zielgerichtet das Problem anzugehen.
Jawohl, Massa Bwana Sahib!
Vince
Hallo Bertram
ja ich fand nach langem hin und her den erwähnten Code im Internet,
jedoch auf einer Englischen Seite... Hatte es für meine Bedürfnisse
angepasst und ich denke etwas vereinfacht... Anyway, damit mein Code
funktioniert musste ich folgende Jar im Lib Verzeichnis kopieren:
imap.jar
mail.jar
mailapi.jar
pop3.jar
smtp.jar
ansonsten ist mein Chinesisch am Ende ;-(
Gruss Vince
Bertram Hurtig
Danke euch allen, auch den Unwissenden! ;-)
Ich habe nun mal Maven Maven sein lassen und habe wie du sagtest
mal die einzelnen 1.3.3er Jars manuell in Eclipse eingebunden -
damit gehts einwandfrei.
Was ich gemacht hatte - ich hatte alle Jars genommen, entpackt, und dann
wieder zu einem jar zusammengepackt - das habe ich gerade nochmal
gemacht, manche Manifest Dateien werden dabei glaub ich überschrieben?!
Aber die Manifestdateien sind doch eh nur so blupp für externe
Programme, dachte ich???
Wie soll ichs sonst machen? Jede jar einzeln einbinden find ich jetzt
ein bisserl häßlich, und ab Java 1.4 ist es dann auch endlich eine
einzelne jar. Ich wills ja irgendwie schön in Maven ablegen können.
Oder alternativ die POM vom apache-commons-mail auf javax.mail 1.4
ändern, aber das ist ja sicher auch nicht das gelbe vom Ei?!
Danke tausend Mal,
Bertram
Tor-Einar Jarnbjo
> Jawohl, Massa Bwana Sahib!
Ralf hat doch aber recht. Deine Antwort (auch ganz davon abgesehen, dass
es nur eine Aneinanderreihung falscher Aussagen war) hatte ja mit
Bertrams Frage überhaupt nichts zu tun. Antworten wie "ich verstehe zwar
nicht mal die Frage, aber habe irgendwann was annähernd Ähnliches
gemacht und muss deswegen was darüber schreiben" gibt es hier in der
Gruppe immer wieder, aber in so einem Ausmaß wie in diesem Thread ist es
recht selten.
Gruß, Tor
Bernd Hohmann
>> Jawohl, Massa Bwana Sahib!
>
> Ralf hat doch aber recht.
Natürlich, nichts anderes habe ich geschrieben.
Und ich werde den Teufel tun, hier nochmal was zu schreiben wenn ich
nicht entweder eine 100%tige Antwort oder ein 100% kompilierbares Sample
habe.
Amüsiert über das immer noch bestehenede Twiteinander,
Bernd
Ralf Ullrich
>Was ich gemacht hatte - ich hatte alle Jars genommen, entpackt, und dann
>wieder zu einem jar zusammengepackt - das habe ich gerade nochmal gemacht,
>manche Manifest Dateien werden dabei glaub ich überschrieben?!
>Aber die Manifestdateien sind doch eh nur so blupp für externe Programme,
>dachte ich???
>
>Wie soll ichs sonst machen?
Grundsätzlich spricht nichts gegen das Zusammenfassen mehrerer Jars in
einer. Aber man muss dabei folgendes beachten: Die Dateien innerhalb eines
Jars (oder Verzeichnisses) müssen eindeutig benannt sein, die Dateien
innerhalb eines ClassPaths (also ggf. mehrerer Jars und/oder
Verzeichnisse) dagegen nicht. Bei Klassen (also *.class-Dateien) werden
die dadurch auftretenden Konflikte i.d.R. dadurch gelöst, dass nur die in
der Reihenfolge des ClassPath erste zu findende verwendet wird. (Wobei
sealed-Packages das noch ein wenig komplizierter machen.) Bei allen
anderen Dateien muss man im Einzelfall entscheiden, wie man den Konflikt
löst, wobei es stark auf deren Verwendung ankommt. Oft werden solche
Konflikt-Dateien via ClassLoader#getResources angesprochen, denn darüber
werden alle gleich benannten Dateien innerhalb des ClassPath gefunden und
können dann alle ausgelesen werden, während ClassLoader#getResource nur
die erste gefundene zurückgibt, wie bei den Klassen. Löst man solche
Konflikte beim Zusammenfassen durch bloßes Überschreiben fehlen am Ende
dann natürlich Daten, da ja dann ClassLoader#getResources auch nur noch
eine Datei liefern kann, und zwar die letzte, die man eingepackt hat.
Daher wird man oft die gleichbenannten Dateien aus mehreren Jars einfach
aneinanderhängen müssen, so müsste es z.B. für die von Michael erwähnte
META-INF/javamail.default.providers sein. Manchmal ist es auch ein wenig
komplizierter, wie zum Beispiel beim Manifest, wo zwar die einzelnen
Einträge hinten anhängen könnte, aber die Header erstmal verbinden muss.
(Außer natürlich im Manifest steht gar nix drin, dann reicht es für die
zusammengefasste neue Jar einfach wieder ein leeres vom jar-Utility
generieren zu lassen.)
Die Manifest-Daten haben vielerlei Anwendungen und es ist ein wenig
schade, dass sie so ein Schattendasein führen. Hätte Sun hier z.B. ein
wenig mehr verbindlich gemacht, wäre es ganz leicht Versionskonflikte zu
entdecken und aufzulösen, die API via Package#getSpecification* und
Package#getImplementation* wäre jedenfalls vorhanden. Da die zugehörigen
Manifest-Angaben aber nicht verbindlich vorhanden sind, kann man sich
nicht allein darauf verlassen.
HTH
cu