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 ;)
Related
My team currently has an old JSF 1.1 / Spring2 / Weblogic Monolith Application. As we start towards modernizing our application they want us to take our current architecture, as is, and basically shoe horn it into Spring Boot.
We aren't talking about breaking it down into micro-services at this point, but basically a lift from our current setup, taking Weblogic out of the picture, and running it in Spring Boot with Hikari Data Sources.
Can this be easily done? I haven't found a way to do it without extensive code changes and I don't mind suggesting a "Lets break it down into a micro-services in the next Product Increment" approach.
Outside of re-architecting our application (as we plan in the future) or doing quite a lot of code change, are there any other options?
If you do not use JavaEE for Weblogic, you can migrate your application to the Spring Boot easy enough. The main thing is the correct import of configuration, components, resources and properties. See: example.
If you used in your legacy project JPA or even JDBC to rewrite backend to Spring Data is not very difficult.
From my point of view the main difficulty is the JSF version you are using. I would refuse it, because: 1) it is not fully compatible with Spring boot and 2) it is already out of date today. It takes a lot of effort to put it into the Spring Boot and still it will not work completely. If there is no time and resources to change this view technology to another, you will have to finish it to Spring Boot.
I don't see other real alternatives
Is it possible to integrate activiti explorer maven plugin with activiti Spring boot app?, so that we can make use of activit-explorer to view deployed process in activit-spring boot engine.
I know we can use rest-api over spring boot to query process engine, but I want to know if it is possible to run the explorer over spring boot by adding it as a maven plugin during deployment?Or can we tweak the activit-explorer.war somehow to point to spring-boot activiti engine?
activiti-explorer.war is standalone webapp by itself. I've write some guideline on how to manually to embed activiti-explorer to you own app. http://blog.canang.com.my/2016/05/12/embedding-activiti-explorer-to-your-application/
Most probably step 5 in my blog is your solution.
btw, there's reason why the name is 'default'. I can't recall it atm
I thought of answering my own question so that it will be useful for other developers with similar requirement. If you want to make an eco-system where activiti-rest, explorer and your custom end points co-exist, please refer this thread from activit forum. I have tried this and is working fine. link to thread
I would like to give my observation here. In order to avoid getting into pulling source and trying to build myself, I achieved partial success, by installing the activit-explorer as part of the usual standalone installation.Started the standalone activiti-explorer using Apache-Tomcat but I configured the database for Activiti as same as (MYSQL in my case) I used in my spring-boot application to hit the common ground.
But apparently the activiti version in my spring boot app was 5.19.0.0 and that for activiti-explorer was 5.22.0.0, which created some misalignment for spring boot application startup to fail. I am hopeful that with matching versions it might succeed. When I get some more time on me I will try and update. Since then may be someone can use this route.
We have an application that is currently running spring 2.5.6 and mule 2.2.1. We have decided to go ahead and upgrade the app to use spring 3.2 we also upgraded spring security to 3.1. I understand that Mule 2.2.1 uses spring 2.5.6 for configuration and so forth. We were to re-factor our code and build the entire project. However after deploying the application and starting the server, my server started in about 6 seconds instead of the normal 30 seconds and then I noticed that none of my services were not loaded. Unfortunately after days of investigating I cannot find where everything fails, as there are no errors in any of the logs including spring and mule logs. My question is it possible to get these to play together or should I just forget about getting this to work.
I read this post http://lifeinide.blogspot.com/2012/07/spring-3-and-mule-2-initialized-by.html and followed these instruction and still was not able to get it work. Mule says it started up just fine without any errors but I can hit any of my services. Any help? Thanks
Thanks #genjosanzo for the pointer. It helped met dig into this issue better and eventually make it work.
#mtanzania,
We had a similar need like yours - need to make Mule 2.2.1 work with Spring 3.2.x releases. Upgrade to Mule 3 involved rewrite of Mule extensions such as exception handling strategies, a RabbitMQ Mule transport etc. Upgrade to Mule 3 was therefore ruled out.
In order to make this work, you need to rewrite/update 3 java files from your module:
groupId:org.mule.modules
artifactId:mule-module-spring-config
version:2.2.1
with implementations from :
groupId:org.mule.modules
artifactId:mule-module-spring-config
version:3.4.0
To be more specific, you need these classes to be updated/upgraded: MuleBeanDefinitionDocumentReader.java, MuleApplicationContext.java and SpringXmlConfigurationBuilder.java
With these updated versions, you can continue to create the MuleContext like:
SpringXmlConfigurationBuilder springConfigBuilder = new SpringXmlConfigurationBuilder(muleConfigPaths);
MuleContext context = new DefaultMuleContextFactory().createMuleContext(springConfigBuilder)
The modified implementations are here : Mule in Trooper and sample class that uses this is here : Trooper Mule container
Mule uses some internal spring API to parse the mule configuration and creates the correspondent beans.
For this reason the upgrade might work with spring 3.0.x but I'm pretty sure that something got broken with spring 3.1.x (i.e. this code has been introduced to maintain backward compatibility).
How about upgrading mule as well? Most of the 2.2.x syntax is still supported and many new feature has been introduced in newer mule versions.
FWIW, the above answer from #regunathb is right on. Patching in those three classes works. However, it is important to note that the 3.4 version of those classes from mule-module-spring-config will not work as-is. You must get the modified versions of the classes that #regunathb posted on GitHub, otherwise you'll end up with various incompatibilities between 3.4 and 2.2.1.
I am thinking about a platform for study application (it is team work). I mean standard Java EE 5 (or maybe try raw Java EE 6) and Spring. What is your choose? (I don't mean Spring MVC but Spring Beans and EJB 3.0)
Also I would like to know what app server you use? (now I use GlassFish v2)
I would recommend Spring without EJBs.
My favorite choice of Java EE app server is WebLogic, but I don't know if Oracle is as generous as BEA was about making it available to developers.
I'd recommend using Tomcat as your app server. If you need JMS, add ActiveMQ.
As duffymo says, look at Spring without EJBs. Spring is very powerful, regardless of how much/little you use. I don't know of anyone using EJBs now. Having said that, EJBs have changed dramatically over the years, and now resemble ORMs such as Hibernate (which is worth checking out in itself).
For app servers, check out JBoss. It's free/open-source, and you can choose the web component between Tomcat and Jetty. It's JMX backbone allows you to easily monitor its state and to integrate your own JMX beans into that backbone (if you're using Spring, you can JMX-enable any bean with a simple configuration).
If you want Java EE 6 then the choice appears to be either Glassfish 3 or the beta of JBoss 6. As some of the others have said, I also prefer Spring to Java EE's EJBs.
I don't see much point in looking at Java EE 5, unless you think you will be working with it in the future (possible as some companies are conservative in using newer versions of technology).
first of all: that might be a newbie question. However after few searches I cannot find anything that would bring me further.
Basically what would be the reasons to choose an app server over a Spring framework to develop a medium complex web application? I am fairly new to Spring, did some hard core WebSphere for few years. While reading about Spring I see that it comes with a good bunch of features (transactions, persistence, messaging, connectors etc). Is Spring hard to scale or manage in a clustered environment?
Any comments welcome.
Thanks
Spring is awesome.
Your terminology is way off though. Spring is a Framework. It's a library that you use to write a web application.
An app Server is what your application runs in. You need both. For example, use the Spring Framework to create an app that runs in the Tomcat app server.
EAR files aren't a requirement for doing Java EE development.
It's not either/or: if you deploy a Java EE application you need a container of some kind.
I've deployed Spring apps on Tomcat and WebLogic. I think WebLogic is the best Java EE app server on the market. My decision about whether to deploy to it or not would be based strictly on availability.
You've seen that Spring has their own Java EE container now. It forks Tomcat and marries it with OSGi and Spring. I haven't tried it yet, but if the quality is similar to their framework it will be very promising indeed.
Are you really asking "When would I write an application using Spring? When should I choose EJB3?"
My preference these days is Spring. I can do persistence, transactions, messaging, web services, and everything else I need.
Bpapa,
you got me there, yes the terminology is wrong. I meant Spring + web container vs. App Servers. Surely the web app has to be deployed somewhere. I guess that shifts the question to the server side features as per my first post.
Topology example: Spring + Tomcat vs. WebSphere.
As a side note: people argue if Tomcat is an app server, many consider it rather a web container. You could not deploy an EAR file to Tomcat, can you? All it takes is a WAR, am I right? But that gets too academic.
Thanks a lot
Rod Johnson's "Expert 1:1 Java EE Development Without EJBs" is the basis for Spring. It's an excellent book, but I'd say it's a bit out of date now. The book was written with EJB2 in mind. It was published before Spring became an open source project. The framework is up to version 3.0 now, so I'd say that the book is of historical interest only. I'd recommend a more modern take on the question that takes Spring 3.0 and EJB3 into account.
%