I need to understand how to deploy a spring boot webapp on SAP Cloud Platform.
I created a basic webapp using https://start.spring.io/.
I only added spring web as module.
I modified the generated pom excluding
spring-boot-starter-tomcat
jul-to-slf4j because I found a loop can be created by system
Then I added following dependencies as provided
slf4j-api
logback-classic
servlet-api
I added an empty web.xml, I deployed the compiled war on SCP and then I started.
After more or less 5 minutes of loading, the start fails and if I check the logs, I can't find any error.
Has anybody an idea of how I should proceed?
I even followed this tutorial, https://blogs.sap.com/2018/08/28/spring-boot-and-sap-cloud-platform-neo/, without any result.
Java version: 1.8
Tomcat version: 1.8
Spring boot version: 2.1.8.RELEASE
It looks that the problem was due to log level too low. It caused the generation of 15 mb log, apparently blocking the webapp start
Related
We have below configuration,
1. Multi module web app based on JSF/Primefaces and Spring 4.2 (separate maven modules for WAR, service JAR etc.)
2. Using Log4j2 as application logging framework
3. Using Ehcache 3 with Spring Cache Abstraction annotations
4. Configured Pom.xml of service module JAR file for Ehcache 3 and java cache-api dependencies
5. Created Ehcache.xml in service module JAR
6. Configured Pom.xml of service WAR with Log4j core and slf4j-log4j12 binding dependencies
7. Configured log4j.xml with for “org.ehcache”
Versions,
JDK 1.8
Spring 4.2
Ehcache 3.3.1
Log4j 1.2
Slf4j-log4j 1.7.7
Problem we are facing,
With all this configuration in place, when we do “run on server” to WAR file on JBoss EAP 7 configured in Eclipse Neon we can’t see Ehcache related log statements in our log file. We can see our application logs though. We tried with various logging levels starting from ALL,TRACE, DEBUG but no logs in log file. Any pointers will really be helpful, we are trying to get this resolved since last 2 days but no luck.
I believe you have a mismatch in your slf4j bindings. You indicate that you are using Log4j version 2 but have placed slf4j-log4j12on the classpath. However that's the binding for log4j version 1.2.
I believe you need instead the binding for log4j 2.
I am using Spring Boot version 1.2.4.RELEASE to generate a simple web project. The full Url for creating this project is:
http://start.spring.io/starter.zip?name=demo3&groupId=org.test&artifactId=demo3&version=0.0.1-SNAPSHOT&description=Demo+project+for+Spring+Boot&packageName=demo3&type=maven-project&packaging=jar&javaVersion=1.7&language=java&bootVersion=1.2.4.RELEASE&dependencies=web
The download starter project opened in the STS 3.6.4.RELEASE with tons of errors: Missing artifact, ArtifactDescriptorException from the pom.xml file.
However, if I use version 1.1.12.RELEASE of the Spring Boot, I have no problem to create the startup project.
Is this a bug in the 1.2.4.RELEASE of the Spring Boot? I doubt it.
The project is OK.
Please to check your local env, specially connexion, maven configuration (setting.xml), ...etc
Good luck
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.
I'm trying to deploy an existing app to tc-server. I have been using this app on tomcat for a couple of years and the production version already runs on tc-server. I have installed the version of tc-server that comes with spring insight. Everything goes well until I deploy a war file that has a dependency on spring integration. I'm getting a no class def found error and it is complaining about a class called
org/springframework/integration/transformer/AbstractMessageProcessingTransformer
I opened up the spring integration jar that is bundled with my war in the WEB-INF lib and did not see that class.
I poked around in the tomcat instance that I created with the bat files in tc-server and see a later version of spring-integration i.e.
.\insight\collection-plugins\insight-plugin-spring-integration-1.9.2.SR1.jar
Since my war is now getting a class not found exception (whereas it deploys fine on my normal tomcat 6.29 ) I'm assuming that this other version of spring-integration is being seen by my app somehow. My app is configured to use spring-integration-1.0.4.
Does anyone know how to get around this problem?
1.0.4 is an extremely old version (3+ years old) the current release is 2.2.4. That class was introduced in 2.0.0.
So you probably have a classpath issue - insight needs a more recent version of Spring Integration on the classpath.
The insight plugin version (1.9.2.x) is not related to the Spring Integration version (but it needs a much more recent version than 1.0.4).
I have a webapp running JAX-RS web services using the Jersey implementation. The target app server is a WebLogic 12c whose default JAXRS implementation is Jersey v1.9.
1) when run on Jetty (6.1.26) with jersey-server-1.9 dependency, everything is fine.
2) when run on WebLogic 12c with jersey-core.jar + jersey-server.jar (v1.9) jars both embedded in the WEB-INF/lib of my war, it is also working.
2) when run on WebLogic 12c with the same war amputed from these 2 jars (assuming there are not needed as already provided by the weblogic Java EE stack), it does NOT work anymore. I got the following error:
"weblogic.application.ModuleException: [HTTP:101216]Servlet: "jersey-servlet" failed to preload on startup in Web application: "cachede-newgen.war".
com.sun.jersey.api.container.ContainerException: The ResourceConfig instance does not contain any root resource classes.
at com.sun.jersey.server.impl.application.RootResourceUriRules.(RootResourceUriRules.java:99)"
Needless to say the Jersey version is exactly identical in all three cases:
"Apr 24, 2013 4:10:24 PM com.sun.jersey.server.impl.application.WebApplicationImpl _initiate
INFO: Initiating Jersey application, version 'Jersey: 1.9 09/02/2011 11:17 AM'"
It sounds again (sight!) like a classpath or classloader issue :-(
Any idea or workaround to solve this issue (taking accound that I do NOT want to repeat jersey jars in every deployed war) ?
Ok I found the reason :-) - and "better_use_mkstemp" put me on the right direction (many thx!).
The solution consists in adding a reference to the deployed Jersey version in the weblogic descriptor file:
<library-ref>
<library-name>jersey-bundle</library-name>
<specification-version>1.1.1</specification-version>
<implementation-version>1.1.5.1</implementation-version>
</library-ref>
The strange thing is that, without such ref, the error message (ie "The ResourceConfig instance does not contain any root resource classes") gives the feeling that Jersey is able to start and scan your annotated classes...
NB: Actually, you also need a reference to the JSR-311 api, as explained here:
http://theblasfrompas.blogspot.be/2011/03/time-to-deploy-restful-web-service-from.html
Have you "deployed" the jersey jar to your server? In the admin console go to Deployables (click Customize the table and uncheck exclude libraries). See if Jersey is listed there. If not, you will need to "deploy" it and target whatever servers you need it on. Then try to redeploy your war file.
Jersey should live in:
wlserver_10.3/common/deployable-libraries
Those shared libraries aren't automatically available to your server until they are targetted to it.
Just remove all Jersey jars and add one Jersey Bundle jar it will work. I have faced the same Issue and resolved after adding Jersey Bundle jar into to class path.