I've been reading about using Spring Boot and Gradle to quickly build RESTful services: https://spring.io/guides/gs/rest-service/. I'd like to give it a try but I need to build a war that's compatible with servlet 2.4 (I know.. life in the 1970's).
The error I get when attempting to deploy the war generated by following the guide above to Sun App Server 8.1 is:
Unknown deployable object type specified: "Cannot determine the J2EE
component type"
The generated war has no web.xml and there may be other expected artifacts.
Configuring a spring-boot application using web.xml seems to suggest that a web.xml can be packaged with a Spring Boot application but doesn't explain how.
Is Spring Boot compatible with older servlet specs? How can Spring Boot and Gradle be used to generate a war that works on older web containers?
Thanks.
The answer to the question you linked to didn't actually go as far as saying that you could easily create a fully-leaded Boot application with Servlet 2.4. I consider that quite a hard, but probably achievable, target if you are prepared to do some legwork, and accept some compromises. You might find this stuff useful: https://github.com/scratches/spring-boot-legacy (I managed to use it to push an app to GAE). But there are some limits to what can be supported for such old technology, and we aren't officially supporting anything other than Servlet 3.0.1 right now.
Related
I've seen Spring Boot Rest project that generates WAR then deployed in a tomcat container. I wonder if this is best practice because I've also read that in Spring Boot, the new final executable JAR file contains embedded server solution like Tomcat too?
Now i've seen a related post that talks about Spring Boot supports both ways but none talked about the pros and cons of each.
Can someone point out the best practice for deploying a spring boot rest project?
I'm thinking of dockerizing the JAR containing embedded server but i'm wondering if there's any drawbacks vs deploying WAR to Tomcat?
A general best practice ( from 12 Factor App ) regarding the application environment and dependencies is "Explicitly declare and isolate dependencies".
A twelve-factor app never relies on implicit existence of system-wide
packages
With that in mind one should gravitate more towards using embedded container as part of explicit dependency instead of a requirement that needs to be fulfilled separately.There are multiple choices for embedded container in the jar artifact (like tomcat, jetty, undertow, netty) and their respective configuration is also extensive, so using these in production environment is recommended ( I have used them a lot). However there might be certain times when you would want to create a war instead, for e.g., a war file will be deployable in any full-fledged EE Application server ( Weblogic, Wildfly etc) which might be mandated by your environment. With a war, your number of options in terms of app server increases. Personally for me, spring boot jar with embedded tomcat has been quite effective. With embedded container option what you need is a virtual machine with OS and Java installed and you are good to go.
However there is a special limitation related to JSP as mentioned here in Spring Boot documentaion which explain a good reason why you might need to package as a war but still run as jar.
I currently have a project running on JRuby which is packaged in a WAR and deployed on TC Server / tomcat.
I was looking into spring boot and I am wondering if someone can explain how easy / hard it would be to convert that application to run on Spring Boot on JRuby.
.war is packed up as "standard" JavaEE project (see the generated web.xml) - nothing fancy really.
that means that you could add whatever libraries and additional files as you want as long as you understand the JRuby-Rack bootup process. your question is kind of vague as of how Spring should interact with JRuby or if it won't need to interact at all. if not simply add another context listener to boot spring, include the spring .jar files and map the URL handling accordingly.
I have a Spring boot war(ReESTful webservice with Spring) built using a gradle build. Initially I built an executable jar and then converted into war. But I am not able to deploy this on websphere 7.5 app server. It can be deployed on Websphere 8.0. I read that spring boot war built without having web.xml is only supported in WAS 8 or above. How can i convert this to a war file that can be deployed on WAS 7.5?
I read that I need to add a web.xml to the war, but what what should be the content of the web.xml so that it can load all the controllers?
Spring Boot doesn't support Servlet 2.5 officially, but it doesn't take a lot to make it work. You might find this useful: https://github.com/scratches/spring-boot-legacy.
You can get more information at the official documantation.
Pardon if this feels a bit of "necroposting". I looked and found only one similar question with no answers here (Spring-Boot Embedded Wars).
I have a service packaged into a spring boot (1.0) container. This service uses activiti (www.activiti.org) to manage some buisiness processes. I am trying to deploy inside the same spring boot container, the war for activiti-explorer. This war has its own web.inf, spring config, et cetera, so it may conflict with the existing spring config, but nonetheless, I'd like to try to deploy that war as it is.
I haven't found any way to do that, and suspect that spring boot doesn't support the deployment of pre-package wars into the embedded container, isn't it?
Just as a warning, I think I can't put the extracted war into the spring-boot jar as I feel it needs a fully functional web container. If spring-boot doesn't offer this functionality, no big deal, we're going to deploy that war on its own tomcat, but it would be handy if it could be.
Thanks
Update
Just to clear better, I have an already running Spring Application standalone server, with its own embedded Tomcat.
Inside the embedded Tomcat I plugged some #Controllers I developed.
Then I was also able to map a third-party servlet using a ServletRegistrationBean (mapped to /servlet-path).
Now I'd like to do something similar with another war that contains a full fledged web application (it's a vaadin/spring 3.2 application with its own libraries, jsps, static resources ...) and would like to map it to (say) /war-path.
I would like to drop the war in a well known location and deploy it into tomcar with a (say) WarRegistrationBean that would let Tomcat handle all the classloading hurdles (as I mentioned, the war is using spring 3.2 while I'm using 4.0 with spring boot, ...).
I suspect that this last feature is not supported by spring-boot or - possibly - even out of scope for the project itself.
You can manually enhance a war archive by adding the stuff that the boot plugin does (classes from the loader and some META-INF information). Easiest would be to simply enhance an "empty" war, and then merge it with the target one (by exploding them both and re-jarring). The only thing you'd need to add might be a main class.
It's still a gap in the Boot tooling. If you think it needs filling please raise an issue and/or send some code.
I have googled around and I have not found satisfying informations about how to start to setup spring in a glassfish container.
Starting point is:
Glassfish 2.1 (no discussions about the version please cause we are forced to use this)
Spring (preferrable version 3.0 but if not possible also lower version is allowed)
EJB 3.0 (therefore I want to make use of the interceptor mechanism to inject a spring bean on the the stateless bean see: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/ejb.html#ejb-implementation-ejb3 )
We don't have a web application in the ear file therefore I am lost at the moment how I could integrate spring into our ear file.
Therefore I have the following questions:
How do I have to configure glassfish/ear file to recognize the spring xml files?
Where should I place and how should I name the spring xml files so they are recognized correctly by the spring framework?
It would be great if anybody could help to find the approriate starting point.
Kind regards,
Walter