I'd like to have Jetty running on a production server and when I have a new code package to deploy I'd like to be able to do an "sbt package" to package up my code into a war file, then copy it over to the production machine's webapp folder.
Is that reasonable? If so, what is the best way to start Jetty as a daemon? Will it see the new file and automatically reload my app or do I need to restart it somehow?
The main problem with what you are suggesting is that the configuration required to have the server listen or monitor the webapps folder is that there will be a production hit.
While this type of configuration is great for development, it isn't recommended for production applications.
With that said, what you're looking for is a ContextDeployer, which can be configured in jetty.xml. See the Jetty documentation for your specific version of Jetty for the exact details:
<!-- =========================================================== -->
<!-- Configure the context deployer -->
<!-- A context deployer will deploy contexts described in -->
<!-- configuration files discovered in a directory. -->
<!-- The configuration directory can be scanned for hot -->
<!-- deployments at the configured scanInterval. -->
<!-- -->
<!-- This deployer is configured to deploy contexts configured -->
<!-- in the $JETTY_HOME/contexts directory -->
<!-- -->
<!-- =========================================================== -->
<Call name="addLifeCycle">
<Arg>
<New class="org.mortbay.jetty.deployer.ContextDeployer">
<Set name="contexts"><Ref id="Contexts"/></Set>
<Set name="configurationDir"><SystemProperty name="jetty.home" default="."/>/contexts</Set>
<Set name="scanInterval">5</Set>
</New>
</Arg>
</Call>
The "scanInterval" is what tells the server to monitor the contexts folder. Every 5 seconds, it checks to see if the files changed.
Finally, to start Jetty as a daemon, just use the scripts they provide you in the /bin folder:
./jetty.sh start
To stop Jetty, run:
./jetty.sh stop
And to restart Jetty, run:
./jetty.sh restart
Again, see The Jetty Documentation or The Webtide Website for the exact documentation for whatever version of Jetty you're running. Different versions can differ drastically in terms of how the server is configured.
Related
I have a jax-rs service deployed in Karaf container v4.2.3 with jetty v9.4.12 and the service is deployed under /services context-path as shown in the picture.
I have managed to enable ssl client auth in Karaf Jetty but the problem is that it enables it globally which causes system console to become inaccessible.
Here is the config I used in org.ops4j.pax.web.cfg
org.osgi.service.http.enabled=false
org.osgi.service.http.secure.enabled=true
org.osgi.service.http.secure.enabled=true
org.osgi.service.http.port.secure=8443
org.ops4j.pax.web.ssl.keystore=./etc/keystores/server-keystore.p12
org.ops4j.pax.web.ssl.truststore=etc/keystores/server-truststore.p12
org.ops4j.pax.web.ssl.truststore.password=secret
org.ops4j.pax.web.ssl.key.password=secret
org.ops4j.pax.web.ssl.keystore.password=secret
org.ops4j.pax.web.ssl.clientauthneeded=true
Is it possible to have SSL client auth only for the /services path and leave system console on non-ssl (http) ?
Thanks a lot
You will need 2 ports or connectors configured. (one with SSL/TLS one without)
Then set the /services/* url-pattern to have a CONFIDENTIAL (servlet) constraint.
As an alternative to the default connectors, it is possible to configure additional connectors in the etc/jetty.xml configuration file.
The etc/jetty.xml is a standard Eclipse Jetty configuration file. The default Apache Karaf WebContainer etc/jetty.xml contains:
<!-- Use this connector for many frequently idle connections and for
threadless continuations. -->
<Call name="addConnector">
<Arg>
<New class="org.eclipse.jetty.server.nio.SelectChannelConnector">
<Set name="host">
<Property name="jetty.host" />
</Set>
<Set name="port">
<Property name="jetty.port" default="8181" />
</Set>
<Set name="maxIdleTime">300000</Set>
<Set name="Acceptors">2</Set>
<Set name="statsOn">false</Set>
<Set name="confidentialPort">8443</Set>
<Set name="lowResourcesConnections">20000</Set>
<Set name="lowResourcesMaxIdleTime">5000</Set>
</New>
</Arg>
</Call>
<!-- =========================================================== -->
<!-- Configure Authentication Realms -->
<!-- Realms may be configured for the entire server here, or -->
<!-- they can be configured for a specific web app in a context -->
<!-- =========================================================== -->
The SelectChannelConnector defines the default connector of the WebContainer.
This connector defines the 8181 port number for the HTTP protocol (port property), and the 8443 port number for the HTTPS protocol (confidentialPort property).
The following resources give you details about advanced etc/jetty.xml configurations:
http://wiki.eclipse.org/Jetty/Howto/Configure_SSL
I have a JBoss EAP 6 instance, which has a couple of deployments (An EAR and a few WARs):
The thing is that on shutdown, I need myWar1.war to be undeployed after myEar.ear, but the actual result is that myEar.ear is being undeployed last, causing errors in the logs on shutdown due to the dependency.
I've already tried declaring dependencies of that war to the ear through jboss-deployment-structure.xml, and myWar1.war/WEB-INF/jboss-all.xml. Here are the examples:
myWar1.war/WEB-INF/jboss-deployment-structure.xml
<dependencies>
<module name="deployment.myEar.ear">
<imports>
<exclude path="***" />
</imports>
</module>
<module name="javax.annotation.api" />
</dependencies>
myWar1.war/WEB-INF/jboss-all.xml
<?xml version="1.0" encoding="UTF-8"?>
<jboss umlns="urn:jboss:1.0">
<jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0">
<dependency name="myEar.ear" />
</jboss-deployment-dependencies>
</jboss>
None of these solutions seem to work. Although, it looks like jboss-all.xml is being read and parsed by JBoss, but it makes no effect on the order of undeployment of the dependant WAR on the EAR. (I guess it's not the expected behaviour, as states HERE.)
All the WARs are being deployed through JBoss CLI (then the server is restarted), but the myEar.ear is being exploded inside the server /deployments, and it's also added as a deployment through the CLI. Here are the entries for that in standalone-full.xml.
Also, the WAR is a SpringBoot application, built and packaged by Maven.
standalone-full.xml
<subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1">
<deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-enabled="false" scan-interval="5000"/>
</subsystem>
<deployments>
. . .
<deployment name="myWar1.war" runtime-name="myWar1.war">
<content sha1="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"/>
</deployment>
<deployment name="myEar" runtime-name="myEar.ear">
<fs-exploded path="$JBOSS_HOME/standalone/deployments/myEar.ear"/>
</deployment>
. . .
</deployments>
Is there another way I can alter the undeployment sequence when shutting down JBoss? Is there a way to make jboss-all.xml be recognized properly by JBoss, or I am missing some configuration?
The deployment dependencies tag in jboss-all.xml is usually referenced only for ensuring applications deploy after dependencies are established (As in your example myear has to be deployed before mywar1 deploys) but not for shutdown.
Commonly JBoss' command line commands (look up JBoss CLI) are used to handle startup, deployments and shutdowns, but the CLI is not meant to be invoked from within your program's code. There is a parallel api called the Management API, for the management interface, which has shutdown/startup functionality, and which is meant to be called from within your code.
The AS7 Management API is applicable to the JBoss EAP 6.x, as should the newest Wildfly version of the API. Only the wildfly api is supposed to be the most updated page for the API and it lists the startup/shutdown procedures though YMMV. Here is the wildfly API and the 6.x/AS7 api in case you run into issues using the wildfly reference. Here is how to use the Management Interface API programmatically.
I deploy a application to tomcat with context xml. I want the tomcat work at debug mode, I means if I change something inside a function, like change
String a="123";
to
String a="456";
tomcat should get the change without reload the application.
The web01.xml under %CATALINA_HOME%/conf/Catalina/localhost
<?xml version='1.0' encoding='utf-8'?>
<Context docBase="d:/document/workspace3.6/web01/WebContent" path="/web01" reloadable="false" debug="1" ></Context>
but now tomcat didn't worked as I expected, if I replace the old class file with new version, I must restart tomcat to get the change.
Why tomcat didn't reload the class,How should I do to let it work as debug mode?
I am not use Eclipse now. and I don't want to set reloadable="true", this will reload the entire application if class changed.
I used tomcat5.5.23
You're actually confusing the notions of "debugging" and hot deploy. You can configure Tomcat for debug mode, and then remotely debug your application running inside tomcat such that when you add a break point in your code, the debugger will jump to that breakpoint and halt execution.
What you actually need there is having the possibility to hotdeploy an application. With tomcat, if you modify the .java files and then copy them to the working directory of tomcat, you'll get exactly what you want, namely the ability to change something in a class and have the running tomcat-deployed application take it into account without redeploying the whole application. You can automatize this by configuring your tomcat application context (either in the tomcat server.xml file or in a project specific context.xml file) for your application to have as working directory the directory where your project code gets compiled.
here's an actual example:
Let's say you have a maven project in the directory c:\myProject. You'd have source files in the c:\myProject\src, and then when compiling it you'd get the war file and an exploded directory of the war file content in the c:\myProject\target\myProject.war and respectively c:\myProject\target\myProject. Now, if you configure your tomcat such that for the myProject tomcat context, youd have the working directory configured as c:\myProject\target\myProject, then each time you modify a .java file, the .class corresponding file will be updated in the target (and now also working) dir, and tomcat will take it into account.
I've actually used such a setup to develop with tomcat, but it's not the best. First off tomcat will hotdeploy only certain modifications, such as when you modify something in the body of an existing method. Other modifications will not be taken into account, such as adding a new method - for this you have to do a full redeploy to have it taken into account.
A far better solution is to use maven with the maven jetty plugin. This thing really works as you want: any modification you do to a class of jsp file will me immediately taken into account, and visible in the running app inside jetty.
Ok, here's an actual example:
I have the cnas-war maven project. Once I build it with Maven, I get the following directory:
c:/_andrei/work/cnas/cnas-war/target\cnas-war-0.0.1-SNAPSHOT
In here I have all the stuff that normally would get packaged in the .war file, like .class files, .jsp files, .jar files etc. Effectively it's the .war file exploded.
I also have a Tomcat 5.5 specifically tailored for the deployment of this war, cleverly placed in the tomcat_cnas folder. In the Tomcat config file (conf\server.xml) I have the following:
<?xml version="1.0" encoding="utf-8"?>
<!-- Example Server Configuration File -->
<!-- Note that component elements are nested corresponding to their
parent-child relationships with each other -->
<!-- A "Server" is a singleton element that represents the entire JVM,
which may contain one or more "Service" instances. The Server
listens for a shutdown command on the indicated port.
Note: A "Server" is not itself a "Container", so you may not
define subcomponents such as "Valves" or "Loggers" at this level.
-->
<Server port="8125" shutdown="SHUTDOWN">
<!-- Comment these entries out to disable JMX MBeans support used for the
administration web application
<Listener className="org.apache.catalina.core.AprLifecycleListener" />
<Listener className="org.apache.catalina.storeconfig.StoreConfigLifecycleListener"/> -->
<Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<!-- Global JNDI resources -->
<GlobalNamingResources>
<!-- Test entry for demonstration purposes -->
<Environment name="simpleValue" type="java.lang.Integer"
value="30" />
<Resource auth="Container"
configurationDirectory="c:/cnas-content"
factory="com.genia.toolbox.web.jndi_config.StringContainerFactory"
name="string/activitymanagerConfigurationContainer"
type="com.genia.toolbox.web.jndi_config.StringContainer" />
<Resource name="string/activitymanagerConfigurationContainer"
auth="Container"
type="com.genia.toolbox.web.jndi_config.StringContainer"
factory="com.genia.toolbox.web.jndi_config.StringContainerFactory"
configurationDirectory="c:/cnas-content" />
</GlobalNamingResources>
<!-- Define the Tomcat Stand-Alone Service -->
<Service name="Catalina">
<!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->
<Connector acceptCount="100" connectionTimeout="20000"
disableUploadTimeout="true" enableLookups="false"
maxHttpHeaderSize="8192" maxSpareThreads="75" maxThreads="150"
minSpareThreads="25" port="8081" redirectPort="8443" />
<!-- Define the top level container in our container hierarchy -->
<Engine defaultHost="localhost" name="Catalina">
<!-- for activitymanager -->
<Host name="localhost" appBase="webapps" unpackWARs="true"
autoDeploy="true" xmlValidation="false"
xmlNamespaceAware="false">
<Context path="/cnas"
docBase="c:/_andrei/work/cnas/cnas-war/target/cnas-war-0.0.1-SNAPSHOT/"
workDir="c:/_andrei/work/cnas/cnas-war/target/work-cnas/">
<ResourceLink name="string/configurationContainer"
global="string/activitymanagerConfigurationContainer"
type="com.genia.toolbox.web.jndi_config.StringContainer" />
<Resource name="bean/cnasConfig" auth="Container"
type="com.genia.toolbox.projects.cnas.war.config.CnasConfig"
factory="org.apache.naming.factory.BeanFactory"
classpath="false" fileSystem="true"
applicationFileLocation="c:/cnas-content/application.properties" />
<Resource name="bean/cnasApplicationData"
auth="Container"
type="com.genia.toolbox.projects.cnas.war.config.CnasConfig"
factory="org.apache.naming.factory.BeanFactory"
classpath="false" fileSystem="true"
applicationFileLocation="c:/cnas-content/cnas_application_data.xml" />
</Context>
<!--Context docBase="C:/travail/workspace/cnas/cnas-ws-proxy/target/webapp" path="/proxy">
<Resource name="bean/params"
auth="Container"
type="fr.genia.cnas.config.Parameters"
factory="org.apache.naming.factory.BeanFactory"
log4jFile=""
serviceUrl=""
debugMode="true" >
</Resource>
</Context-->
</Host>
</Engine>
</Service>
</Server>
As you can see, in the "context" tag I have a docBase property pointing to the snapshot directory (the one where the war is exploded after maven builds it). Now, with this setup, and having this project imported into Eclipse, if I do a maven build, and then start this Tomcat, the war will be deployed and running. At this point, if I modify the content of a method in a .java file inside Eclipse (and save), then that code will be automatically taken into account by Tomcat and the application will behave differently, without any extra re-deployment. Hope this helps
How to configure Tomcat 5.5 for debug mode?
To do what you are trying to do, You would need some thing like java rebel or some thing similar I know there are some open source alternatives to do the same.
I have a web app which in production I run on Tomcat. It uses the MySQL connector, however it is not bundled up with the war, rather it is included under Tomcat's common lib directory, so that I can access the data source through JNDI.
I would like to do something similar with Jetty (while developing), and more precisely Jetty + Maven. Is there a way for me to include the mysql-connector jar in the classpath when running Jetty through Maven (i.e. not have it bundled in the war file)?
Also I should note that I am using Maven for my build process and have the mysql-connector specified as "provided" scope.
Additinally to previous answer:
you have to add to your jetty plugin in maven config dependency:
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>${jetty.version}</version>
<configuration>
<stopKey>blah-blah-blah</stopKey>
<stopPort>9966</stopPort>
<webAppConfig>
<contextPath>/</contextPath>
</webAppConfig>
<jettyEnvXml>${basedir}/src/jetty-env.xml</jettyEnvXml>
</configuration>
<dependencies>
<dependency>
<groupId>postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>8.4-701.jdbc4</version>
</dependency>
</dependencies>
</plugin>
And then you can use provided scope at main project dependencies. I did it right now, and it works. Thank you for your question (and Nishant too)
Does not directly answer your question but since I love portability in webapps my war will contain the connector jar and a connection pool (e.g the super duper c3p0). That means that the container will not manage the database connection for me anymore nor will I use JNDI to describe the connection properties. But the webapp is now 100% portable and predictable on tomcat, jetty, resin, jboss etc.
<Configure class="org.mortbay.jetty.webapp.WebAppContext">
<New class="org.mortbay.jetty.plus.naming.Resource">
<Arg>hd-props</Arg>
<Arg>
<New class="java.util.Properties">
<Call name="load">
<Arg>
<New class="java.io.FileReader">
<Arg>cfg/dev-local.properties</Arg>
</New>
</Arg>
</Call>
</New>
</Arg>
</New>
It is a jetty-env.xml, which points to .properties file, which contains all the connect params to DB.
<bean id="jndi" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="java:comp/env/hd-props"/>
</bean>
<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="properties" ref="jndi"/>
</bean>
It is a spring config (i'm using spring too)
And then, I call mvn jetty:run, and it works fine...
Perhaps you could try using Maven .war overlays for this purpose, though I don't know if they work with other dependencies.
So basically your project would be
parent
|---- original-war
|---- new-war
Where your original-war project has the mysql dependency as <scope>provided</scope> but the the new-war module is just a pom that has a <packaging>war</packaging>, depends on the original war (for the overlay) has the mysql dependency with the compile scope, and runs the jetty plugin (leave the jetty plugin out of the original-war module). If this works, then you'll have to deal with the minor inconvenience of doing your development in one module but whatever testing you are doing in maven within another module.
Is there a way to deploy a given war file on Tomcat server? I want to do this without using the web interface.
There are several ways to deploy a Tomcat webapp:
Dropping into $CATALINA_HOME/webapps, as was already mentioned.
Using your build scripts to deploy automatically via the manager interface (that comes with Tomcat). Here are the two ways
for Maven: use the tomcat plugin. You don't need to include it in pom.xml, just issue the goal mvn tomcat:deploy, the plugin is included in Maven 2. This assumes several defaults explained in the documentation, you can configure the behaviour in the pom.xml. There are other goals that let you deploy as an exploded archive etc.
for Ant: something like this:
<property name="manager.url" value="http://localhost:8080/manager"/>
<property name="manager.username" value="manager"/>
<property name="manager.password" value="foobar"/>
<!-- Task definitions -->
<taskdef name="deploy" classname="org.apache.catalina.ant.DeployTask"/>
<taskdef name="list" classname="org.apache.catalina.ant.ListTask"/>
<taskdef name="reload" classname="org.apache.catalina.ant.ReloadTask"/>
<taskdef name="undeploy" classname="org.apache.catalina.ant.UndeployTask"/>
<!-- goals -->
<target name="install" depends="compile" description="Install application to servlet container">
<deploy url="${manager.url}"
username="${manager.username}"
password="${manager.password}"
path="${app.path}"
localWar="file://${build.home}"/>
</target>
<target name="list" description="List installed applications on servlet container">
<list url="${manager.url}"
username="${manager.username}"
password="${manager.password}"/>
</target>
<target name="reload" depends="compile" description="Reload application on servlet container">
<reload url="${manager.url}"
username="${manager.username}"
password="${manager.password}"
path="${app.path}"/>
</target>
<target name="remove" description="Remove application on servlet container">
<undeploy url="${manager.url}"
username="${manager.username}"
password="${manager.password}"
path="${app.path}"/>
</target>
All of those will require you to have a Tomcat user configuration. It lives $CATALINA_BASE/conf/tomcat-users.xml, but since you know already how to use the web interface, I assume you know how to configure the users and passwords.
Just copy the war file into the $TOMCAT_HOME/webapps/ directory. Tomcat will deploy the war file by automatically exploding it. FYI - If you want you can make updates directly to the exploded directory, which is useful for development.
We never use the web interface, don't like it. The wars are dropped in the webapps and server.xml edited as necessary. You need to bounce it if you edit the server.xml, but the war file should be picked up automagically. We generally delete the directory expanded from the war first so there is no confusion from where the components came.
you can edit the conf/server.xml and add an entry like this pointing to your war directory
<Context path="/strutsDisplayTag"
reloadable="true"
docBase="C:\work\learn\jsp\strutsDisplayTag"
workDir="C:\work\learn\jsp\strutsDisplayTag\work" />
ELSE
you can copy your .WAR file to the webapps directory of tomcat.
The Tomcat Client Deployer Package looks to be what you need to deploy to a remote server from the command line. From the page:
This is a package which can be used to validate, compile, compress to .WAR, and deploy web applications to production or development Tomcat servers. It should be noted that this feature uses the Tomcat Manager and as such the target Tomcat server should be running.
You can also try this command-line script for managing tomcat called tomcat-manager. It requires Python, and talks to the manager application included with tomcat via HTTP. You can do stuff from a *nix shell like:
$ tomcat-manager --user=admin --password=newenglandclamchowder \
> http://localhost:8080/manager/ stop /myapp
and:
$ tomcat-manager --user=admin --password=newenglandclamchowder \
> http://localhost:8080/manager deploy /myapp ~/src/myapp/myapp.war