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.
Related
I am creating a library using spring-boot (v2.1.6.RELEASE) as a starter project that will facilitate as base extension jar responsible for configuring and starting up some of the components based on client project properties file.
The issue I am facing is that if the client project's SpringBoot Application class contains the same package path as library everything works like charm! but when client project contains different package path and includes ComponentScan, it is not able to load or start components from the library.
Did anyone encounter this issue? how to make client application to auto-configure some of the components from library jar?
Note: I am following the library creation example from here: https://www.baeldung.com/spring-boot-custom-starter
There are many things that can go wrong here, without seeing relevant parts of actual code its hard to tell something concrete. Out of my head, here are a couple of points for consideration that can hopefully lead to the solution:
Since we use starters in our applications (and sometimes people use explicit component scanning in there spring applications) and this obviously works, probably the issue is with the starter module itself. Don't think that the fact that the component scan is used alone prevents the starter from being loaded ;)
Make sure the starter is a: regular library and not packaged as a spring boot application (read you don't use spring boot plugin) and have <packaging>jar</packaging> in your pom.xml or whatever you use to build.
Make sure you have: src/main/resources/META-INF/spring.factories file
(case sensitive and everything)
Make sure that this spring.factories file indeed contains a valid reference on your configuration (java class annotated with #Configuration). If you use component scanning in the same package, it will find and load this configuration even without spring factories, in this case, its just kind of another portion of your code just packaged as a separate jar. So this looks especially "suspicious" to me.
Make sure that #Configuration doesn't have #Conditional-something - maybe this condition is not obeyed and the configuration doesn't start. For debugging purposes maybe you even should remove these #Conditional annotations just to ensure that the Configuration starts. You can also provide some logging inside the #Configuration class, like: "loading my cool library".
I can't find
http://www.springframework.org/schema/integration/aws/spring-integration-aws.xsd
under
http://www.springframework.org/schema/integration/
Any help?
You shouldn't care about that these days. The normal IDEs are able to resolve XSD against classpath, reading the content of the jars you provide for your project.
That schema is located here: https://github.com/spring-projects/spring-integration-aws/tree/master/src/main/resources/org/springframework/integration/aws/config
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'm hitting the same problem described in here, but I don't know my websphere version at the time
More questions
1) does Removing commons-logging-1.1.jar fix it?
2) what if I really need to put commons-logging-1.1.jar in my application? How can I fix this?
Theres a fix pack of ibm for this.
https://www-304.ibm.com/support/docview.wss?uid=swg21502693
This happens because the class org.apache.commons.logging.impl.Jdk14Logger is loaded by a different classloader than the one that loaded the Log interface.
According to IBM's documentation, whenever you use a third-party library that WebSphere itself uses for its own internal purposes, you must:
Set your EAR's classloader policy to PARENT_LAST; and
Ensure that your EAR is self-sufficient. That is, that your third-party libraries (and their dependencies) are bundled within the EAR.
In your case:
Set your EAR's classloader policy to PARENT_LAST
Include commons-logging-1.1.jar within your EAR (you can place it in the "EAR Library" directory, usually EAR/lib).
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.