Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Not A Problem
-
Affects Version/s: 1.12.1
-
Fix Version/s: 1.13.0
-
Component/s: Archetype: SimpleApp
-
Labels:None
-
Environment:Windows 10, Windows 7
Tomcat version: Apache Tomcat/8.0.33
JVM: 1.8.0_77-b03
Description
Steps to reproduce:
- Created simpleapp from archetype (Version 1.12.0)
- Execute mvn clean package
- Take the file \webapp\target\simpleapp.war and deploy to tomcat thru e.g. manager UI (http://localhost:8080/manager/html)
Attached the catalina.log
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Hi Jörg, thanks for the hint. I commented out the part in pom.xml in simpleapp-webapp module, but still have same issue.
Is this the way how to remove the jetty from war?
Thanks,Vladimir
<build>
<plugins>
<!--
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
</plugin>
-->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>maven-version</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Hi Vladimir,
this is from my webapp/pom.xml:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<warName>ife-webapp</warName>
<archive>
<manifest>
<addClasspath>false</addClasspath>
</manifest>
<manifestEntries>
<Build-Time>${maven.build.timestamp}</Build-Time>
<Build-Host>${agent.name}</Build-Host>
<Build-User>${user.name}</Build-User>
<Build-Maven>Maven ${maven.version}</Build-Maven>
<Build-Java>${java.version}</Build-Java>
<Build-OS>${os.name}</Build-OS>
<Build-Label>${project.version}</Build-Label>
</manifestEntries>
</archive>
<packagingExcludes>WEB-INF/lib/isis-core-webserver*.jar,
WEB-INF/lib/javax.servlet-api-*.jar,
WEB-INF/lib/javax.websocket-api-*.jar,
WEB-INF/lib/jetty-all-*.jar</packagingExcludes>
</configuration>
</plugin>
Try to exclude more JARs from the WAR.
HTH -j
Hi Jörg, I tried out your proposal but stil without success. After googling I've found next issue with similar problem https://issues.apache.org/jira/browse/AMQ-6154
Then I've changed the web.xml to newer Servlet Deployment Descriptor - version 3.1 and added absolute-ordering element. After that, I've redeployed war to Tomcat 8.0.33 and simpleapp works now fine!
@Dan Haywood: maybe this should be adapted in simpleapp archetype as well?
<web-app id="WebApp_ID" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" version="3.1"> <absolute-ordering/>
The correct fix would be to not include Jetty jars in the .war file at all.
How do you created the app from the archetype ?
I've just tried " mvn archetype:generate -DgroupId=org.apache.isis.archetype -DartifactId=simpleapp-archetype -Dversion=1.13.0-SNAPSHOT" but it seems this is not the correct way.
I've found it!
mvn archetype:generate \
-D archetypeGroupId=org.apache.isis.archetype \
-D archetypeArtifactId=simpleapp-archetype \
-D archetypeVersion=1.12.1 \
-D groupId=com.mycompany \
-D artifactId=myapp \
-D version=1.0-SNAPSHOT \
-B
There is no Jetty in the produced .war file after 'mvn package'-ing the generated application.
Please provide steps to reproduce the problem.
Hi Martin, I've started "mvn clean install", from IntelliJ..
Meanwhile I've adapted pom.xml in webapp module, as advised by Jörg, with next configuration
<packagingExcludes>
WEB-INF/lib/isis-core-webserver*.jar,
WEB-INF/lib/javax.servlet-api-*.jar,
WEB-INF/lib/javax.websocket-api-*.jar,
WEB-INF/lib/javax-websocket-server-impl-*.jar,
WEB-INF/lib/jetty-*.jar
</packagingExcludes>
I think I had to exclude additional websocket-server-impl, since there are more jetty JAR's then jetty-all, I've also adapted the exclude to jetty-*.jar
The webapp launches now fine, but I have now a swagger issue, I don't see any restful service, see attached screenshots.
It seems that the service org.apache.isis.core.metamodel.services.swagger.SwaggerServiceDefault is not recongnized.
When I launch the webapp with IntelliJ launcher, with Jetty, everything works fine.
The Swagger issue should be reported to in a new ticket, with description how to reproduce or at least a demo application.
This ticket should be closed as "Cannot reproduce" if you can't reproduce it too.
Hi Martin, I will create new ticket with Swagger issue. In this issue I still believe that default generated war is not deployable on Tomcat.
Here the steps to reproduce:
1. Create archetype as described in guide
mvn archetype:generate \ -D archetypeGroupId=org.apache.isis.archetype \ -D archetypeArtifactId=simpleapp-archetype \ -D archetypeVersion=1.12.1 \ -D groupId=com.mycompany \ -D artifactId=myapp \ -D version=1.0-SNAPSHOT \ -B
2. execute "mvn clean install"
3. deploy simpleapp.war to external tomcat, eg. thru tomcat manager webapp
4. ERROR: starting of simpleapp.war will fail, in Tomcat (my Tomcat version 8.0.33) log will appear
13-May-2016 06:42:30.922 SEVERE [http-apr-8080-exec-31] org.apache.catalina.core.ContainerBase.addChildInternal ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/simpleapp]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:153)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:940)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:467)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1612)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:300)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source)
at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1451)
at org.apache.catalina.manager.HTMLManagerServlet.upload(HTMLManagerServlet.java:285)
at org.apache.catalina.manager.HTMLManagerServlet.doPost(HTMLManagerServlet.java:206)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
at org.apache.catalina.filters.CsrfPreventionFilter.doFilter(CsrfPreventionFilter.java:136)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:614)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:522)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1095)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:672)
at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2500)
at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2489)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException
at org.eclipse.jetty.websocket.jsr356.server.deploy.WebSocketServerContainerInitializer.isEnabled(WebSocketServerContainerInitializer.java:133)
at org.eclipse.jetty.websocket.jsr356.server.deploy.WebSocketServerContainerInitializer.onStartup(WebSocketServerContainerInitializer.java:148)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5240)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147)
... 45 more
Fix would be, as advised by Jörg and slightly adapted by my experience, to adapt the webapp/pom.xml.
<plugin>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<warName>simpleapp</warName>
<archive>
<manifest>
<addClasspath>false</addClasspath>
</manifest>
<manifestEntries>
<Build-Time>${maven.build.timestamp}</Build-Time>
<Build-Host>${agent.name}</Build-Host>
<Build-User>${user.name}</Build-User>
<Build-Maven>Maven ${maven.version}</Build-Maven>
<Build-Java>${java.version}</Build-Java>
<Build-OS>${os.name}</Build-OS>
<Build-Label>${project.version}</Build-Label>
</manifestEntries>
</archive>
<packagingExcludes>
WEB-INF/lib/isis-core-webserver*.jar,
WEB-INF/lib/javax.servlet-api-*.jar,
WEB-INF/lib/javax.websocket-api-*.jar,
WEB-INF/lib/javax-websocket-server-impl-*.jar,
WEB-INF/lib/jetty-*.jar
</packagingExcludes>
</configuration>
</plugin>
Question to you: Do you think this fix should be part of default generated simpleapp, otherwise the war is not deploayble.
You must be doing something else there.
I've re-run "mvn archetype:generate" you pasted above and it works just fine in Tomcat 8.x.
Also there are no Jetty jars in webapp/target/simpleapp.war#WEB-INF/lib/, so there is no need to exclude anything.
Martin, you're right. I was actually using maven thru IntelliJ. Running maven from command line gives me a war file without jetty-jars, but when I start the maven task from IntelliJ, then I get the war with jetty jars!
fyi, this used to be the way to remove these, but the pom.xml as of 1.12.0 has been improved... there is no longer any dependency on the isis-core-webserver module (which is what was bringing these dependencies in transitively).
I just did a build and deploy to Tomcat; the set of JARs in WEB-INF/lib is:
activation-1.1.1.jar animate.css-3.2.5.jar annotations-2.0.1.jar aopalliance-1.0.jar axon-core-2.4.jar bootstrap-3.3.6.jar cglib-nodep-2.2.2.jar commons-beanutils-1.8.3.jar commons-cli-1.3.1.jar commons-codec-1.10.jar commons-collections-3.2.1.jar commons-email-1.4.jar commons-io-2.4.jar commons-lang3-3.3.2.jar commons-logging-1.2.jar datanucleus-api-jdo-4.1.1.jar datanucleus-core-4.1.7.jar datanucleus-jdo-query-4.0.5.jar datanucleus-jodatime-4.1.0-release.jar datanucleus-rdbms-4.1.9.jar disruptor-3.2.0.jar dom4j-1.6.1.jar Eonasdan-bootstrap-datetimepicker-4.15.35.jar FastInfoset-1.2.12.jar font-awesome-4.4.0.jar geronimo-activation_1.1_spec-1.1.jar geronimo-annotation_1.0_spec-1.1.1.jar geronimo-atinject_1.0_spec-1.0.jar geronimo-jcdi_1.0_spec-1.0.jar geronimo-servlet_3.0_spec-1.0.jar gson-2.5.jar guava-19.0.jar guice-4.0.jar hamcrest-core-1.3.jar hamcrest-library-1.3.jar hsqldb-2.3.1.jar httpclient-4.3.6.jar httpcore-4.3.3.jar isis-core-applib-1.12.1.jar isis-core-log4j-1.12.1.jar isis-core-metamodel-1.12.1.jar isis-core-runtime-1.12.1.jar isis-core-schema-1.12.1.jar isis-core-security-1.12.1.jar isis-core-security-shiro-1.12.1.jar isis-core-viewer-restfulobjects-applib-1.12.1.jar isis-core-viewer-restfulobjects-rendering-1.12.1.jar isis-core-viewer-restfulobjects-server-1.12.1.jar isis-core-wrapper-1.12.1.jar isis-viewer-wicket-applib-1.12.1.jar isis-viewer-wicket-impl-1.12.1.jar isis-viewer-wicket-model-1.12.1.jar isis-viewer-wicket-ui-1.12.1.jar istack-commons-runtime-2.16.jar jackson-annotations-2.6.4.jar jackson-core-2.6.4.jar jackson-core-asl-1.9.12.jar jackson-databind-2.6.4.jar jackson-dataformat-yaml-2.4.5.jar jackson-datatype-joda-2.4.5.jar jackson-jaxrs-1.9.12.jar jackson-mapper-asl-1.9.12.jar jackson-xc-1.9.12.jar javassist-3.20.0-GA.jar javax.inject-1.jar javax.mail-1.5.2.jar jaxb-api-2.2.7.jar jaxb-core-2.2.7.jar jaxb-impl-2.2.7.jar jboss-annotations-api_1.2_spec-1.0.0.Final.jar jboss-jaxrs-api_2.0_spec-1.0.0.Final.jar jboss-logging-3.1.4.GA.jar jcip-annotations-1.0.jar jdo-api-3.1.jar jdom-2.0.2.jar joda-time-2.9.1.jar jquery-1.11.1.jar jquery-selectors-0.1.6.jar jquery-ui-1.11.4.jar jsr173_api-1.0.jar junit-4.12.jar log4j-1.2.17.jar log4jdbc-remix-0.2.7.jar maven-parent-config-0.3.5.jar modernizr-2.8.3.jar momentjs-2.10.3.jar myapp-app-1.0-SNAPSHOT.jar myapp-dom-1.0-SNAPSHOT.jar myapp-fixture-1.0-SNAPSHOT.jar objenesis-2.2.jar reflections-0.9.10.jar resteasy-jackson-provider-3.0.14.Final.jar resteasy-jaxb-provider-3.0.14.Final.jar resteasy-jaxrs-3.0.14.Final.jar select2-3.5.2.jar shiro-core-1.2.3.jar shiro-web-1.2.3.jar slf4j-api-1.7.13.jar slf4j-log4j12-1.7.13.jar snakeyaml-1.12.jar summernote-0.7.0.jar swagger-annotations-1.5.5.jar swagger-core-1.5.5.jar swagger-models-1.5.5.jar swagger-ui-2.1.3.jar transaction-api-1.1.jar validation-api-1.1.0.Final.jar webjars-servlet-2.x-1.4.jar wicket-auth-roles-6.20.0.jar wicket-bootstrap-core-0.9.15.jar wicket-bootstrap-extensions-0.9.15.jar wicket-bootstrap-themes-0.9.15.jar wicket-core-6.20.0.jar wicket-extensions-6.20.0.jar wicket-guice-6.20.0.jar wicket-ioc-6.20.0.jar wicket-request-6.20.0.jar wicket-source-6.0.0.8.jar wicketstuff-select2-6.20.0.jar wicket-util-6.20.0.jar wicket-webjars-0.4.8.jar xml-apis-1.0.b2.jar xmlpull-1.1.3.1.jar xpp3_min-1.1.4c.jar xstream-1.4.8.jar
I've raised a ticket for this suggestion, ISIS-1403.
They aren't, as of the 1.12.0 archetype. However, many users will have apps from earlier versions of the archetype that did include those JARs. The easiest fix is to run the new archetype and port over files; isn't that difficult to do.
That's because there's a <profile> to do that...
<profile>
<id>intellij</id>
<activation>
<property>
<name>idea.version</name>
</property>
</activation>
<dependencies>
<dependency>
<groupId>org.apache.isis.core</groupId>
<artifactId>isis-core-webserver</artifactId>
</dependency>
</dependencies>
</profile>
It's there because the org.apache.isis.WebServer class requires them, and that idea.version variable is a convenient way to distinguish cmd line vs IDE usage.
The 1.12.0 version of the archetype correctly excludes the jetty jar files. It also has a profile which adds them onto the classpath so that the org.apache.isis.WebServer utility class can be used.
Hi,
if I recall correctly, I had to exclude jetty from the war, since it doesn't make sense to embed a sevletcontainer when deploying to another one.
HTH -j