So I updated the spring version to 2.6.3, which upgraded all the starters and spring data versions which brought a curious problem, the projections used for spring data stopped working and spring is throwing a NPE unless I explicitly provide #Value("#{target.id}") above the projection field. Problem is that you can't catch everything, and there is a good chance I miss something, so does anyone have an idea if there is a global solution to this or I should go for the downgrade?
Related
I've come to the conclusion that the Spring Web MVC is not compatible with Payara 5 and 6. I have an application that uses Glassfish 3, Spring Web MVC, and EclipseLink JPA. I intend to upgrade the code to Java 17 and Jakarta EE. In the sake of kindness, it hasn't gone well. In all my efforts, it's been Spring's Web MVC that is causing the problems. Spring charges for support and that's not a viable option for me. Before I scrap it's use, let's pick your brain.
If anyone has implemented Spring Web MVC successfully with Payara 5 and/or 6, please share how you made it work.
My first step was to try Payara 6 for Jakarta EE. After creating a VERY small Hello World web app, I included Spring Web MVC jar and did the minimum to activate it's Dispatcher Servlet. I was never able to overcome the error CDI is not available.
Secondly, I backed off to Payara 5. In that attempt, it tries to instantiate a JPA EAO Bean that the app will use in all it's controllers to access the app's DB. The error here appears to be when it attempts to use FasterXML to read the persistence.xml file. That part of the app works fine when I create the EAO object with JUnit.
Rather than providing all the gory details, reviewing the artifacts from a successfully implemented app with help me tremendously.
Thank you for your help!
So after weeks of beating my head against a wall trying all kinds of things to get it working, I wrote to one of the SpringFramework developers, Juergen Hoeller. Here's his response....
Sorry to hear that there is so much trouble on Payara still. We also
have corresponding reports on GitHub:
https://github.com/spring-projects/spring-framework/issues/29718
https://github.com/spring-projects/spring-framework/issues/29743
Unfortunately neither of the two is an actual problem to be solved on
Spring's own side, as far as I can see.
With the CDI issue, it's Payara's CDI implementation not being able to
parse Java 17's new record types. Also, I wonder why Payara needs to
parse every single deployed class file if you are not actually using
CDI. It might be possible to turn that off, but at the very least,
Payara should defensively handle "unknown" types.
With the Hibernate issue, it's a problem with Hibernate 6 initializing
its Jackson configuration on Payara. There does not seem to be a StAX
provider available, and Hibernate insists on one being present for
Jackson.
Overall, this needs to be taken to Payara and Hibernate, we are not
aware of anything Spring can do better. Feel free to add further
comments to the GitHub issues in case there is anything we can do from
our side! Even if our focus is on Tomcat/Jetty these days, we of
course want Spring 6 to work fine on Payara as well.
Thanks for your efforts to try to make this work,
Juergen
So now, how do we get the attention of Oracle's Glassfish developers and Payara's developers to get this resolved???? In the meantime, I think I'll have to install Tomcat or some other free webserver. Thanks, Oracle.
This was reported against Hibernate before, but Glassfish/Payara simply have a broken classpath config. Also see https://hibernate.atlassian.net/browse/HHH-15556
Maybe try using Wildfly, which is also free ;)
I read somewhere that Spring Sleuth has performance impact. Whatever I read over internet are old posts.
Does anyone know whether with new version of Spring Boot this issue is resolved or it is still there.
I am developing a Jersey RESTful service using the Spring framework integration with Hibernate. I get a NoSuchMethodException on a org.jboss.logging.logger.debugf call. As I noticed, the class is indeed loaded from the bean-validator.jar included alongside the jersey-spring3 library, eventhough I have specifically referenced the jboss logging artifact.
Has anyone encountered this issue? And if so, how should I solve it?
Update
I have found a workaround, but it is far from being a solution. In order for the required classes to have the same signature, I have downgraded the hibernate-entitymanager to version 4.2.8.Final. However, this leads the way to other compatibility issues.
Update 2
In the end, I have chosen to implement the REST service functionality using the Spring Framework instead of using the aforementioned integration.
Check out the answers in the following post, your issue might be similar:
Error "java.lang.NoSuchMethodError: org.jboss.logging.Logger.getMessageLogger"
Newbie here...
I'm working on a Spring MVC app and their JDBC api for data access. How would I go about saving data to multiple tables? The insertion needs to be such that if there's an error or something goes wrong, nothing gets inserted and rolled-back. Would this be Spring's transaction support? If so, the official documentation for transaction support is very confusing to me. Does anyone have a good source for learning how to do that?
I'm using Spring 3.1, Oracle 11g, and Tomcat 6.0
Yes, spring supports transaction. You can use DataSourceTransactionManager to configure your bean.IF you find xml mapping confusing you can use annotation #Transactional. Spring's annotation support for transactions are really simple. Spring in Action book has examples for transaction management.
Right now, I have been facing so much issue running some parts of the Spring Framework, like I have no problems running my Appengine web app with Spring MVC however have so many issues running Spring Data on top of Appengine.
I wan't to know which part of the framework have been tested to work with Appengine (AE)?
Does Spring Security work with AE?
Does Spring Data work with AE?
I'm guessing that there is no planned support for these frameworks at all for AE. However, hopefully I'm wrong.
I would suggest looking here: https://code.google.com/p/googleappengine/wiki/WillItPlayInJava
Spring Security is listed as SEMI-COMPATIBLE.
As for Spring Security, it works great. You'll just have to enable sessions. And if you want to apply the SPring filter on static files, make sure to exclude them from the static resources in appengine-web.xml.
As for Spring Data, I've never tried it but you might be able to use the JPA and REST sub-projects at least.