Tomcat 8 - No Spring WebApplicationInitializer types detected on classpath - spring-mvc

I use maven plugin for eclipse and tomcat plugin for maven. When I use it to "clean tomcat7:deploy" my hello.war to the Tomcat 8 server on localhost it works fine. I can go to localhost:8080/hello/hello and see "Hello!" page.
But when I deploy to Ubuntu server 15.10 in my local network and go to 192.168.1.2:8080/hello/hello I get Apache Tomcat 404 error. Though tomcat manager shows that deployment went fine and my app is working.
My thoughts were that something wrong with tomcat server on ubuntu, but when I deploy other apps to the same tomcat server on ubuntu, they work as they should. Then I thought the problem is inside my "hello" app. But if it was so, I wouldn't be able to successfully run it on my localhost tomcat server!
When I read logs on Tomcat on Ubuntu server they say:
06-Mar-2016 10:00:00.369 INFO [http-nio-8080-exec-5] org.apache.catalina.core.ApplicationContext.log Manager: deploy: Deploying web application '/hello'
06-Mar-2016 10:00:00.370 INFO [http-nio-8080-exec-5] org.apache.catalina.core.ApplicationContext.log Manager: Uploading WAR file to /var/lib/tomcat8/webapps/hello.war.tmp
06-Mar-2016 10:00:18.022 INFO [localhost-startStop-3] org.apache.catalina.core.ApplicationContext.log No Spring WebApplicationInitializer types detected on classpath
So it seems like it can't find my Bootstrap.class class that implements Spring WebApplicationInitializer interface. Though when I check folder /var/lib/tomcat8/webapps/hello/WEB-INF/classes it contains all classes it should.
I checked logs on localhost, and they do not complain about this.
So at the end it seems that Tomcat 8 on Ubuntu server can not find mentioned WebApplicationInitializer.
I've read answers to similar questions here on stackoverflow and tried, but most of them are dealing with eclipse server settings, my problem here is different I think.
What to do and where to look?
EDIT:
When I manually deploy hello.war via /manager on localhost, everything is ok. Inside localhost.2016-03-06.log I have:
06-Mar-2016 11:34:33.081 INFO [http-nio-8080-exec-51] org.apache.catalina.core.ApplicationContext.log Spring WebApplicationInitializers detected on classpath: [by.hello.configuration.Bootstrap#19087f1e]
06-Mar-2016 11:34:33.544 INFO [http-nio-8080-exec-51] org.apache.catalina.core.ApplicationContext.log Initializing Spring root WebApplicationContext
06-Mar-2016 11:34:34.026 INFO [http-nio-8080-exec-51] org.apache.catalina.core.ApplicationContext.log Initializing Spring FrameworkServlet 'springDispatcher'
I can go to localhost:8080/hello/hello and see "Hello!" greeting.
When I do the same with Ubuntu server's tomcat /manager inside logs I have:
06-Mar-2016 11:36:06.555 INFO [http-nio-8080-exec-14] org.apache.catalina.core.ApplicationContext.log No Spring WebApplicationInitializer types detected on classpath
06-Mar-2016 11:36:06.559 INFO [http-nio-8080-exec-14] org.apache.catalina.core.ApplicationContext.log HTMLManager: list: Listing contexts for virtual host 'localhost'

I used to compile project using JDK1.8 environment.
Now I recompiled project using JDK1.7, my Ubuntu server's Tomcat8 started to recognize Bootstrap.class which implements WebApplicationInitializer interface.
So, the answer for me was:
Check your tomcat's JVM version at the bottom of Tomcat /manager/html page.
Recompile your project using appropriate JDK version.

Related

How to configure Spring Cloud Configuration Server without the git profile?

I'm attempting to run Spring Cloud Configuration Server, working through the examples in a book (Manning's Spring Microservices in Action), but updating to the latest versions: Java 17, spring-boot-starter-parent 2.6.1, with Spring Cloud 2021.0.0-RC1.
Each time I try to start the server, I get this error:
***************************
APPLICATION FAILED TO START
***************************
Description:
Invalid config server configuration.
Action:
If you are using the git profile, you need to set a Git URI in your configuration. If you have set spring.cloud.config.server.bootstrap=true, you need to use a composite configuration.
I am not using the git profile. I have tried two different profiles: native (with config files on the classpath) and vault (with a Hashicorp Vault server running locally). My latest /src/resources/bootstrap.yml contains the following:
spring:
application:
name: config-server
profiles:
active: vault
cloud:
config:
server:
vault:
port: 8200
host: 127.0.0.1
kvVersion: 2
server:
port: 8071
My best guess is that the bootstrap.yml file isn't getting picked up at server startup, and perhaps the git profile is a default. How can I remedy this?
OK, it looks like the problem here is that newer versions of Spring Cloud Configuration Server don't look for the bootstrap.yml file by default. There are a few different ways to solve it. The easiest is just to move all the properties to an application.yml/application.properties instead.
Another alternative is (found at NEWBEDEV here) is to include a dependency that implements the "legacy" bootstrap behavior:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>
add the following into application.properties file.
spring.application.name=techefx-spring-cloud-config-server
spring.cloud.config.server.git.uri=https://github.com/techefx/environment-variable-repo.git
server.port= ${port:8888}
Please go through the link below:
Spring Cloud Config File System Backend Issue (not reading properties from the file)

Mvn Connection Timeout Error because of proxy Setting in Redhat 7 while connecting via Bamboo

My Bamboo agent is trying to get a Mvn pom file from the repo on a virtual machine and I am getting Connection Timeout. The OS I am using is RedHat7.
I have my proxy settings as follows
~/.bashrc - both for user and root
export proxy=http://username:password#proxy.XXX.com:8080/
export http_proxy=$proxy
export https_proxy=$proxy
export HTTP_PROXY=$proxy
export HTTPS_PROXY=$proxy
The Maven settings file settings.xml:
<proxy>
<id>optional</id>
<active>true</active>
<protocol>http</protocol>
<username>username</username>
<password>passsword</password>
<host>proxy.XXX.com</host>
<port>8080</port>
<nonProxyHosts>local.net|some.host.com</nonProxyHosts>
</proxy>
In my yum.conf I have also added the proxy settings, although it is not reuired
proxy=http://proxy.XXX.com
proxy_usename=username
proxy_password=password
Also my in my /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
IPV6_AUTOCONF=no
HOSTNAME="XXXXXX.co.XXXX.com"
NOZEROCONF=yes
GATEWAY=XX.XX.XX.X
I can do wget and but when the bamboo tries to download a pom.xml it gives the following error:
https\://repo.maven.apache.org/maven2/.error=Could not transfer artifact io.spring.platform\:platform-bom\:pom\:1.0.2.RELEASE from/to central (https\://repo.maven.apache.org/maven2)\: Connect to repo.maven.apache.org\:443 [repo.maven.apache.org/23.235.40.215] failed\: Connection timed out
What am I missing? Is there another configuration that needs to be set ?
So the issue was with the repository. It required to be pointed to the Nexus repository

How to deploy to Glassfish v3.1.2 das using Jenkins Deploy Plugin?

I'm I using the plugin correctly?
I have a war which deploys fine to tomcat but when I try to deploy it to glassfish it throws the exceptions below. Its probably important to note that I'm running Jenkins on the same glassfish instance as I'm trying to deploy to locally.
I'm using the deploy plugin with the following settings:
war/ear file: **/daf-1.0.0-BUILD-SNAPSHOT.war
context: daf
container: Glassfish 3.x
GlassFish admin port: 4848
GlassFish hostname: 127.0.0.1
I have added a comment to JIRA here: https://issues.jenkins-ci.org/browse/JENKINS-11030?focusedCommentId=179452#comment-179452
[#|2013-05-31T11:46:32.180-0400|WARNING|glassfish3.1.2|hudson.model.AbstractBuild|_ThreadID=105;_ThreadName=Executor #1 for master : executing daf-deploy-master #3;|Publisher hudson.plugins.deploy.DeployPublisher aborted due to exception
org.codehaus.cargo.util.CargoException: Cannot communicate with the server
at org.codehaus.cargo.container.spi.deployer.AbstractJsr88Deployer.redeploy(AbstractJsr88Deployer.java:126)
at hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:64)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:90)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:77)
at hudson.FilePath.act(FilePath.java:904)
at hudson.FilePath.act(FilePath.java:877)
at hudson.plugins.deploy.CargoContainerAdapter.redeploy(CargoContainerAdapter.java:77)
at hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:47)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:802)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:774)
at hudson.model.Build$BuildExecution.post2(Build.java:183)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:724)
at hudson.model.Run.execute(Run.java:1600)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:237)
Caused by: javax.enterprise.deploy.spi.exceptions.TargetException: Error getting required modules
at org.glassfish.deployapi.SunDeploymentManager.getModules(SunDeploymentManager.java:313)
at org.glassfish.deployapi.SunDeploymentManager.getRunningModules(SunDeploymentManager.java:200)
at org.codehaus.cargo.container.spi.deployer.AbstractJsr88Deployer.findTargetModule(AbstractJsr88Deployer.java:350)
at org.codehaus.cargo.container.spi.deployer.AbstractJsr88Deployer.redeploy(AbstractJsr88Deployer.java:122)
... 16 more
Caused by: java.lang.ClassCastException: org.glassfish.deployapi.TargetImpl cannot be cast to org.glassfish.deployapi.TargetImpl
at org.glassfish.deployapi.SunDeploymentManager.getModules(SunDeploymentManager.java:300)
... 19 more
javax.enterprise.deploy.spi.exceptions.TargetException: Error getting required modules
at org.glassfish.deployapi.SunDeploymentManager.getModules(SunDeploymentManager.java:313)
at org.glassfish.deployapi.SunDeploymentManager.getRunningModules(SunDeploymentManager.java:200)
at org.codehaus.cargo.container.spi.deployer.AbstractJsr88Deployer.findTargetModule(AbstractJsr88Deployer.java:350)
at org.codehaus.cargo.container.spi.deployer.AbstractJsr88Deployer.redeploy(AbstractJsr88Deployer.java:122)
at hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:64)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:90)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:77)
at hudson.FilePath.act(FilePath.java:904)
at hudson.FilePath.act(FilePath.java:877)
at hudson.plugins.deploy.CargoContainerAdapter.redeploy(CargoContainerAdapter.java:77)
at hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:47)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:802)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:774)
at hudson.model.Build$BuildExecution.post2(Build.java:183)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:724)
at hudson.model.Run.execute(Run.java:1600)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:237)
Caused by: java.lang.ClassCastException: org.glassfish.deployapi.TargetImpl cannot be cast to org.glassfish.deployapi.TargetImpl
at org.glassfish.deployapi.SunDeploymentManager.getModules(SunDeploymentManager.java:300)
... 19 more

java.lang.NoClassDefFoundError: org/apache/commons/codec/DecoderException in JBoss AS 7

I am testing JBoss AS 7 prior to deployment with a .war file of an app running in a different server.
I get this error when I try to log onto the database via the app:
SEVERE [] (http--0.0.0.0-8080-4) java.lang.NoClassDefFoundError: org/apache/commons/codec/DecoderException
java.lang.ClassNotFoundException: org.apache.commons.codec.DecoderException from [Module "deployment.app.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
at org.apache.commons.httpclient.HttpMethodBase.<init>(HttpMethodBase.java:220)
In some forums, they suggest adding the commons-codec jar, but I already have it in JBoss, right? (in here: jboss-as-7.1.1.Final/modules/org/apache/commons/codec/main/commons-codec-1.4.jar)
OSGi is not activated, frankly I have no idea to what purpose it serves, but when I try to activate it it messes with my war as it fails to deploy...
I have JDK, but no JRE if that's any help.
JBoss AS 7 does not use OSGi by default for modular class loading. It uses JBoss Modules so this has nothing to do with OSGi.
What you need to do if you want to use the commons-codec provided with JBoss AS 7 is add a dependency to your deployment.
Modules are not visible by your artefact classes automatically. You have three possibilities:
Define a global module in your standalone.xml
http://javahowto.blogspot.de/2012/09/how-to-create-global-modules-in-jboss.html
This module will be used by all artefacts you are deploying on Jboss.
Put it into your war artefact, into the lib folder. You can do that with Maven.
Define an explicit dependency within your Manifest. https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7
Section Dependencies: Manifest Entries

Liferay 6 on Glassfish 3.1 - issue using liferay-ui tags in portlet jsp files

We are seeing this issue on our current Glassfish 3.1 cluster setup. Below are details of issue
- We are running Glassfish version 3.1
We are running liferay 6.0.6
The liferay war is deployed on the Glassfish cluster and working fine on both the nodes.
The same liferay war works fine one Tomcat server as well.
When we deploy our custom portlets on Glassfish cluster it starts working immediately after deployment. (before doing a restart of glassfish cluster)
Once we do a restart of the cluster nodes the same portlet application stops working and Complains and give attached error.
My research till now shows that the java.lang.NoClassDefFoundError: com/liferay/portal/util/PropsValues is part of portal-impl.jar file which is part of liferay portal and should be made available to our portlet. Somehow after the restart the jar files are loaded in a different manner and the same jar file is not available to portlet.
We have also tried the Glassfish 3.1 Bundled liferay 6.1 setup and see the same issue on it as well.
As suggested by liferay forums we have placed the portal-service.jar and portlet.jar in [glassfish home]/lib directory.
when we do a lsof -p pid on the glassfish node instance process it shows the required jar file is open by this process. Not sure why is this not available to our application.
I would appreciate any help or pointers to resolve/investigate this issue.
java.lang.NoClassDefFoundError: com/liferay/portal/util/PropsValues
at org.apache.jsp.html.taglib.ui.search_005fiterator.page_jsp._jspService(page_jsp.java from :500)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:492)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:378)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:72) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:113)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilter.doFilter(InvokerFilter.java:68)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:785)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:649)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:604)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:534) at com.liferay.taglib.util.IncludeTag.include(IncludeTag.java:323)
at com.liferay.taglib.util.IncludeTag._doInclude(IncludeTag.java:418)
at com.liferay.taglib.util.IncludeTag.doEndTag(IncludeTag.java:92)
This is a related thread on liferay forum by me but I have not really got any response on it from anyone. [Same issue posted on liferay Forum]
i have also tried placing portal-impl.jar in my portlet/WEB-INF/lib dir (which is not recommended way) and I failed since it requires me to bring all other dependent jars in it too.
I am now running out of options and thinking about implementing the pagination feature using some other third party library instead of using liferay tags.
Here is the specific tag which is giving us error
<liferay-ui:search-iterator />
List of jars in my portlet WEB-INF/lib folder
SiebelClientWS-0.0.1-SNAPSHOT.jar
spring-asm-3.0.5.RELEASE.jar
XmlSchema-1.4.7.jar
spring-aspects-3.0.5.RELEASE.jar
aspectjrt-1.6.11.jar
spring-beans-3.0.5.RELEASE.jar
aspectjweaver-1.6.11.jar
spring-context-3.0.5.RELEASE.jar
axiom-api-1.2.11.jar
spring-context-support-3.0.5.RELEASE.jar
axiom-impl-1.2.11.jar
spring-core-3.0.5.RELEASE.jar
axis2-1.5.4.jar
spring-expression-3.0.5.RELEASE.jar
axis2-kernel-1.5.4.jar
spring-jdbc-3.0.5.RELEASE.jar
axis2-transport-http-1.5.4.jar
spring-tx-3.0.5.RELEASE.jar
axis2-transport-local-1.5.4.jar
spring-web-3.0.5.RELEASE.jar
c3p0-0.9.1.2.jar
spring-webmvc-3.0.5.RELEASE.jar
commons-codec-1.4.jar
spring-webmvc-portlet-3.0.5.RELEASE.jar
commons-httpclient-3.1.jar
util-bridges.jar
commons-logging.jar
util-java.jar
flexjson-2.1.jar
util-taglib.jar
httpcore-4.0.jar
woden-api-1.0M9.jar
httpcore-nio-4.0-beta1.jar
woden-impl-commons-1.0M9.jar
log4j.jar
woden-impl-dom-1.0M9.jar
neethi-2.0.2.jar
wsdl4j-1.6.2.jar
spring-aop-3.0.5.RELEASE.jar
wss4j-1.6.2.jar
I changed
/html/taglib/ui/search_paginator/page.jsp
/html/taglib/ui/search_iterator/page.jsp
/html/taglib/ui/page_iterator/start.jsp
and removed the calls to PropsValues and replaced them with calls to the com.liferay.portal.kernel.util.PropsUtil and PropsKeys instead and that go the rid of the error for me.
I made an improvement request
http://issues.liferay.com/browse/LPS-30660
com/liferay/portal/util/PropsValues is part of portal-impl.jar file which is part of liferay portal and should be made available to our portlet.
That is not true, portal-impl.jar is not available to your portlets and it is not meant to. You MUST NOT put it in your WEB-INF/lib. That jar is only available, and should be that way, to Liferay (liferay application).
Can you show contents (list of jars) of your (deployed) portlets WEB-INF/lib?

Resources