In the new Spring boot 3 Release notes, They tells that this version is going to use Jakarta EE 9 (libs named as jakarta) instead of JEE (libs named as javax).
They advise developers to replace imported javax with jakarta in this article.
If I have a spring boot app with both, javax and jakarta libs, will the app work and be able to be deployed in a Jakarta compatible server (e.g. Tomcat 10)?
Thanks a lot.
The answer will really depend on which specific libraries you're using and how they interact with each other, but generally speaking trying to mix Java EE and Jakarta EE them would be a bad idea.
As an example, if you're writing a Spring MVC application then you'll be using the DispatcherServlet. In Spring Framework 6 this will require the Jakarta Servlet API. There's not going to be a way to make it work with the javax.servlet For other APIs, if you're using them directly and you're not making use of Spring abstractions that build on them, you may get away with having them on your classpath. I still wouldn't recommend it.
You could try to put the web app instead of in webapps into webapps-javaee like described in https://tomcat.apache.org/migration-10.html#Specification_APIs
Then TC10 will create a new war in webapps and unpack it as usual in webapps. I tried it with some of our pure TC8/9 Apps and it was working.
Related
I am trying Java with Spring Framework for my own web project. I've asked some traditional JSP web hosting firms which supports Tomcat and they said they do not support Spring Framework. I am confused about this situation. What is the different requirements between JSP and Spring Framework? I was thinking both of them runs on JVM such as Tomcat and they do not need any difference things. Does Spring Framework need different jar files, or different software on server?
Building a Spring application results in a jar with an embedded webserver (most of the times tomcat, but you can change this in the pom.xml/build.gradle).
I used to host my Spring applications on a VPS or Amazon EC2 instance. Something like that. You can just install Java on it and run your jar. No extra installations of webservers needed.
Ok, let get it straight, just summarizing what have been said:
Use Spring MVC, without spring boot.
Use Spring Boot, and create a war file.
I would implement a Spring aspect in a j2ee application, can someone post some tutorials?
I've just used Spring in web application but I've not idea how to invoke a cross cutting concern in CDI container.
Thanks in advance
Is there a special need for combining Spring and CDI? If not, I'd suggest to stick to standard Java EE as long as you can solve your problem with it and only if not, look for external components (and even then, you should first check the "sort-of-standard" CDI extensionf from the Apache Deltaspike project.
Cross-cutting concerns can be solved via pure CDI - check our for example the Java EE 7 tutorial about the topic.
Small note: Don't use J2EE anymore if not maintaining an ancient application.
I want to use Spring in an application which loads several modules using OSGi. I want to be able to inject beans exposed by bundle A into targets exposed by bundle B.
I saw blueprint which seems to require Spring 3, and eclipse gemini which supports Spring 4 but seems pretty abandoned.
What's the latests on using OSGi with Spring 4?
Thanks
BLueprint is independent from spring. For example Aries Blueprint does not need any spring dependency. I am not sure about Gemini but I think it also does not require spring. Blueprint is optimized for OSGi and works well. It does not provide all spring features though.
Spring never worked well in OSGi. Spring 4 now even is not delivered as bundles. So I would not suggest to use spring in OSGi at all.
That said Apache Karaf offers spring 4 bundles but I am not sure how well they work. In any case I doubt you will get any OSGi support from spring source.
I'm working on a project that delivers web services using Jersey, which has a dependency on JAXB 2.1. I have to add a feature that fetches data from another web service. The way this has been implemented elsewhere uses a Spring JaxWsPortProxyFactoryBean.
When Spring tries to initialize this bean it fails with a : ClassCastException (com.sun.xml.bind.v2.runtime.JAXBContextImpl cannot be cast to com.sun.xml.bind.api.JAXBRIContext).
It appears that this is because JavaSE6 includes JAX-WS 2.0 API.
The only solution I have found suggests putting the 2.1 jars in the JRE endorsed directory. This isn't an option - I'm sharing a server with other application teams so I can't mess with the JRE.
Does anybody know of another way to make Spring use the 2.1 jars?
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).