I have a very large project with a ton of dependancies, and am getting the following exception when trying to send mail:
javax.mail.NoSuchProviderException: smtp
I know the code works because it is part of a library that is used in other projects. Does anyone know what would cause this exception to happen? I have looked through all of the jar's and the only one containing 'javax.mail' is 'mail-1.4.4-SNAPSHOT.jar'.
Is there some file/class that registeres the 'smtp' protocol, and it could be happening somewhere else in my classpath?
It's been a while since this question has been asked but it's still worth answering :
What's happening is that your mail service is using the SMTP (usually, it is even considered as the default protocol to use)protocol to send mail. No matter what concrete class you're using as mail service (might depend on whether you're working with Java EE, Spring or something else), it ends up using classes from the javamail API. In this API, in order to establish a connection to your mail server, an instance of javax.mail.Session will be created and this object will dynamically load classes that provide support for the protocol to use.
When loading the required class, in case it is not found, the ClassNotFoundException is caught and re-threw as javax.mail.NoSuchProviderException, with a message indicating the missing protocol support.
The solution in that case is to add the smtp.jar to your classpath.
With a Maven-based project, simply add the following dependency
<dependency>
<groupId>com.sun.mail</groupId>
<artifactId>smtp</artifactId>
<version>1.4.5</version>
</dependency>
I had this issue. Putting smtp.jar in classpath solved the issue.
The way I have fixed this was to remove the mail jar from the classpath. Somewhere in the classpath there exists another instance of mail.jar, and I have yet been able to find it. If anyone else runs into this problem, additional information on trouble shooting can be found here:
http://forum.springsource.org/showthread.php?t=90737
and
http://forums.sun.com/thread.jspa?threadID=5442371
I got same problem while we upgrade jboss from 4.x to 6.x.
Here Problem is setting classpath to the more number of mail.jar files(default server will take the mail.jar from its common/lib foler if it available there).
To confirm which jar file it is using, following statement is usefull.
System.out.println(getClass().getResource("/javax/mail/Address.class"));
if it is using the another jar file which you are not expecting.. set classpath to that instead which you are using. other wise remove that jar file from the above printed location.
This can also happen when you have an incorrect version of the "mailapi.jar" file in your classpath as well.
I'd recently upgraded a project to use PayPal's soap API, and PayPal's distribution contained a mailapi.jar file, which was different than the one I'd currently had in my project, and caused my app to fail when sending mail.
So for me, I just had to revert to my old mailapi.jar and I was fine.
I had this isssue right now. The problem was two javax.mail.jar in the same classpath.
Related
I'm using Apache Camel in a project and when I needed to use the camel-ftp component to send some files to an remote server, I've got this exception:
com.jcraft.jsch.JSchException: Session.connect: java.security.NoSuchAlgorithmException: DH KeyPairGenerator not available
I was wondering why it could be happening in my project. So, I've started a quick small project with camel-core and camel-ftp components only and I pasted the route there and it worked fine.
from("file:data/input?noop=true")
.log("Uploading file ${file:name}")
.to("sftp://www.mydestination.com:22/../opt/tmp?autoCreate=false&username=MyUser&password=MyPassword&passiveMode=true")
.log("Uploaded file ${file:name} complete.");
I'm using Apache Karaf to run OSGI Bundles (my application is one of them). I've checked in different environments but the result still beeing the exception.
I really don't know what it could be. Anyone has some ideas about what can be the possible cause of it?
DH KeyPair Generator is normally part of the JRE/JSE and should be included if your JDK (>BTW which exact JDK version are you using ?).
Given that, your error is probably due to a wrong classpath.
I suggest you to check the value of "-Djava.ext.dirs" property (and the contents of the corresponding folders), for instance:
Windows:
java -Djava.ext.dirs="C:\Program Files\Java\jdk1.6.0_07\jre\lib\ext;C:\dir2"
Unix:
java -Djava.ext.dirs=$JAVA_HOME/jre/lib/ext:/dir2
You also need to specify/modify the Karaf security provider, take a look at:
https://karaf.apache.org/manual/latest/security
Im building an application based on Spring Boot v1.2. While my application boots successfully and executes well (so far.. ), I'm unable to test using the spring boot framework because of an AbstractMethodError.
The last few lines of the trace are as below
Caused by: java.lang.AbstractMethodError: org.springframework.data.jpa.repository.support.LockModeRepositoryPostProcessor.postProcess(Lorg/springframework/aop/framework/ProxyFactory;Lorg/springframework/data/repository/core/RepositoryInformation;)V
at org.springframework.data.repository.core.support.RepositoryFactorySupport.getRepository(RepositoryFactorySupport.java:185)
at org.springframework.data.repository.core.support.RepositoryFactoryBeanSupport.initAndReturn(RepositoryFactoryBeanSupport.java:239)
at org.springframework.data.repository.core.support.RepositoryFactoryBeanSupport.afterPropertiesSet(RepositoryFactoryBeanSupport.java:225)
at org.springframework.data.jpa.repository.support.JpaRepositoryFactoryBean.afterPropertiesSet(JpaRepositoryFactoryBean.java:84)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1627)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1564)
... 55 more
To analyze the above error, I checked the jar files from classpath involving the above classes. So the info is available as below
jar:file:/C:/rearch/intellij-workspace/springbootproj/lib/spring-aop-4.1.2.RELEASE.jar!/org/springframework/aop/framework/ProxyFactory.class
jar:file:/C:/rearch/mavenrepo/org/springframework/data/spring-data-commons/1.9.1.RELEASE/spring-data-commons-1.9.1.RELEASE.jar!/org/springframework/data/repository/core/RepositoryInformation.class
jar:file:/C:/rearch/intellij-workspace/springbootproj/lib/spring-data-jpa-1.3.3.jar!/org/springframework/data/jpa/repository/support/LockModeRepositoryPostProcessor.class
jar:file:/C:/rearch/intellij-workspace/springbootproj/lib/spring-test-4.1.2.RELEASE.jar!/org/springframework/test/context/support/DependencyInjectionTestExecutionListener.class
I'm not exactly sure on why spring-data-commons is coming up from maven repostory folder, while the others are being served from the project library.
While I debug that, I meanwhile need your help in figuring out the version compatibility between the above libraries.
I wasnt able to exactly pin point on what exactly is causing the error. Please help!
Thanks
The issue was with the intellij configuration of libraries which conflicts with Spring boot application. I manually replaced the required libraries from Maven repository and that worked out for me.
Per request from Elron..
Open the project folder in explorer and verify if the third party library versions in your project matches the ones you actually expect it to be. If something doesnt match, just replace the file with the one you expect it to be. In my case, since I use Maven, I didnt see a need for explicitly saving those libraries in a new lib folder under the project. So, I just deleted all of the files inside the lib folder and things started working again.
For fix this error, change the spring-data-jpa version to 1.5.0.RELEASE
I have faced this issue .
Get rid of spring-data-commons and change spring-data-jpa version to 1.9.0.RELEASE.
For more details , please follow this link :-
Spring Data Rest PagingAndSortingRepository AbstractMethodError (RepositoryFactorySupport)
I am creating a SpringFramework websocket app and I am using examples from the SpringFramework website.
When I used the spring-integration websocket namespace my NetBeans IDE warned that it couldn't find the xml definition at:
http://www.springframework.org/schema/integration/websocket/spring-integration-websocket.xsd
I took a look at:
http://www.springframework.org/schema/integration/
and discovered that there is no "websocket" directory.
Has this definition been moved or replaced by something or is this by design for some reason?
If it has been moved where can I find it?
If it is just missing from the springframework.org website, where can I find a copy so my IDE will be able to resolve its autocomplete helpers for me?
We'll take a look why it isn't there. Because WebSockets support has been added since Spring Integration 4.1.
Anyway the IDE should determine XSD from the spring-integration-websocket dependency. The XSD is on location \org\springframework\integration\websocket\config\ within that jar.
The schemata are delivered with the jars and are listed in the META-INF/spring.schemas file in the jar. (they are not loaded from any website).
Therefore make sure that you have the spring-integration-websocket.jar in your classpath.
I am using Netbeans as my IDE, currently developing an Web app using:
Spring 3
Hibernate 3
MySQL
I'm relying on netbeans to build the project(in contrast to others using maven). On deployment, the console shows this error:
...noClassDefFoundError: com/mchange/v2/c3p0/DataSources
I've already added the jar file to the Hibernate library.
(And oh, this is my first time asking here. Needed 10 points to post the screenshot.)
So I'm confused why would it need THAT class. (whatever that class does.)
Ideas why did this happen?
I've finally manage to solve the problem. The c3p0 distribution has 3 .jar files on the lib directory. I initially added the "c3p0*.jar" only. Which in turn produces the error.
It needs the OTHER jar file, mchange-commons*.jar in the directory. Hope this helps to others stuck in here.
Download this jar mchange-commons-java-0.2.3.4.jar. This helps me to resolve the issue.
C3P0 is used to support connection pooling. See http://www.mchange.com/projects/c3p0/ for further information on C3P0 and https://community.jboss.org/wiki/HowToConfigureTheC3P0ConnectionPool for information on configuring C3P0 with Hibernate.
Add this jar file "c3p0-0.9.2.1.jar" to library
If you are still getting the error, you need to remove and add again Hibernate library because this "c3p0-0.9.2.1.jar" is conflict version with c3p0 in Hibernate library
I am currently working on a portlet that is using the commons-collections jar file and am getting a NoSuchMethodError. To resolve this issue I need to change the classloader of my WAR file from PARENT_FIRST to PARENT_LAST (in the application.xml file).
However, when I do this my portlet will not launch and when I log into the console it displays the message "The portlet is temporarily disabled". If I change the classloader back to PARENT_FIRST then it will launch again but then I get the NoSuchMethodError.
Does anybody have any suggestions on how to fix this issue ?
I am not sure how, but today I started getting error messages in the logs when I was getting "The portlet is temporarily disabled". I was getting a java.lang.LinkageError which was down to the fact that I had the servlet-api-2.5.jar and a jaxb jar which was conflicting with webshpere j2ee.jar. Once I removed these dependencies and set the classloader to PARENT_LAST, it seems to work properly. It seems that a lot of people face similar issues. The link below is also useful http://forum.springsource.org/showthread.php?33663-dispatcher-servlet-quot-not-a-servlet-class-quot-in-websphere
#MTH,
please try adding commons-collections as a shared library. See here for an example on how others have used shared library support [1]. That will give you the steps, just do it for the jars that you need to override/replace from WAS's classloader
[1] http://portals.apache.org/jetspeed-2/deployguide/deploying-jetspeed-to-websphere.html#section_4_2
thanks,
dims
You haven't provided any logs... but still, one of the most important things to look out for when setting your application to run PARENT_LAST is that your application isn't bundled with any system-level classes that may conflict with the ones provided by WebSphere Portal. For example, classes that pertain to the Portlet specification or the JavaEE specification.