Jetty Bash Script Works Only with Root User

libblkid only works with root and after running as root

From the BLKID(8) man page:

The libblkid library is used to identify block devices (disks) as to their content (e.g. filesystem type) as well as extracting additional information such as filesystem labels/volume names, unique identifiers/serial num‐
bers. A common use is to allow use of LABEL= and UUID= tags instead of hard-coding specific block device names into configuration files.

...

Note that blkid reads information directly from devices and for non-root users it returns cached unverified information.

From the LIBBLKID(3) man page:

The high-level part of the library keeps information about block
devices in a cache file and is verified to still be valid before being
returned to the user (if the user has read permission on the raw block
device, otherwise
not). The cache file also allows unprivileged users (normally anyone other than root, or those not in the "disk" group) to locate
devices by label/id. The standard location of the cache file can be
overridden by the envi‐
ronment variable BLKID_FILE.

So after you've run it as root, the information is cached. Afterwards that information is retrieved when you run again as non-root.

Unable to install Jetty9 as a service in Ubuntu

I finally got this working, the jetty user should have permissions to the following folders and /usr/sbin/nologin as shell as described here.

JETTY_HOME
JETTY_BASE
/var/run/jetty   <-- couldn't find a reference to this folder in the docs

And add the following to your /etc/default/jetty:

JETTY_SHELL=/bin/sh
JETTY_LOGS=/usr/share/jetty9/logs
JETTY_START_LOG=/usr/share/jetty9/logs/jetty-start-log.log

Also you should double check that there are no remaining log files owned by other user than jetty in your folders.

Bash shell script get core dump error

And finally I find out the reason for core dump. It's because the kill part. kill will not kill the process right away , there is some time delay,that's why I always get core dump error. I add a for loop to check whether this process is completely killed , and then try to start the process, which successfully fix this problem and no core dump any more. As for what really causes core dump , I still don't understand it. Any information will be appreciated. –

Restart jetty remotely using SSH without it being stopped

Working Solution:

1. On EC2 instance, edit the sudoers file with what you want.
2. Then, restart Jetty remotely with this command: ssh -i key.pem ec2-user@instance.domain.com 'sudo service jetty restart', notice that -t was removed.
3. If command prompt doesn't come back after restart finishes, add a >/dev/null at the end.

Cleanest Jetty Configuration for Development?

Jetty has migrated to Eclipse. There is very subtle info on this. This also led in change in package name, which is another level of nuance. They did publish a util to convert Jetty6 setting to Jetty 7 setting, but again -- not very popular. I am dissapointed from Eclipse Jetty forum. Here is where you should look for documentation on Jetty 7 onwards http://wiki.eclipse.org/Jetty/Starting

I think this is the minimal jetty.xml taken from http://wiki.eclipse.org/Jetty/Reference/jetty.xml

<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">\ 
<Configure id="Server" class="org.eclipse.jetty.server.Server">
</Configure>

But, I would rather like to start from a copy of $JETTY_HOME/etc/jetty.xml and would modify from there.

If you are Okay with $JETTY_HOME/webapps directory, you can set up the port by modifying this part

<Configure id="Server" class="org.eclipse.jetty.server.Server">
    ...
    <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="7777"/></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>

Else, I will modify context.xml the way explained here (for Jetty 7) How to serve webbapp A from portA and webapp B from portB

Also refer these pages:

• http://wiki.eclipse.org/Jetty/Reference/jetty.xml
• http://wiki.eclipse.org/Jetty/Reference/jetty.xml_syntax
• http://communitymapbuilder.org/display/JETTY/JNDI

....
Edit#1: sorry for wrong URL for webapp per connector. I have updated the link to How to serve webbapp A from portA and webapp B from portB to point to the doc that is meant for Jetty 7.

---

Update on 'how you deal with Jetty on various environments?'

Dev

We use Maven, so embeded Jetty works for us. We just run mvn clean install run:jetty and the port is configured in Maven's config file, namely pom.xml. This is not IDE dependent plus Jetty can easily be embedded using ANT, but I never tried.

Test

We have stand-alone Jetty running. I've configured port and tuned parameters, removed default apps (e.g. root.war etc) and created a context.xml with app specific ports and deployment directory. (Unfortunately, I have asked this question on Eclipse Jetty's mailing list and no one bothered to answer). This is one time setting.

For test builds/deployments, we have a build script that builds the WAR as per test env specs and then uploads it to test environment. After, that we invoke a shell script that (1)stops Jetty, (2) copies war file to myApp's webapp direactory and (3) restarts Jetty.

However, easier way to do this is by using Maven's Cargo plugin. The bad luck was that I was using Jetty 7.1.6 which was incompatible with Cargo. Later they fixed it, but I had got my job done by custom script.

Prod

Prod has almost same procedure as test, except. The tunings are done for higher security and load-balancing. But from deployment POV, there is nothing different from Test case to Prod.

Notice that I have not bothered about what XML files are and how many must be there. I have just used the ones that are my concerns -- jetty.xml and context.xml. Plus, I found it's much cleaner to use jetty.conf and jetty.sh for passing JVM params, custom XMLs and for starting and stopping.

Hope this helps.

---

On hot deployment:

Now, if you use Maven and use embedded Jetty. It just knows when the code is changed -- like "gunshot sniffer". In dev envt, you run Jetty, make changes, refresh page, and see your changes -- hot deployment. Find more here http://docs.codehaus.org/display/JETTY/Maven+Jetty+Plugin look for scanIntervalSeconds

System environment variables in Jetty application

Not supporting System.getenv() is not a Jetty thing, but a Java thing.

There are ton of restrictions around System.getenv() and your environment, making it nearly useless in all but the most naive and basic test case. (eg: multiline values are not supported. multiline entries can break parsing. keys without values are not supported. keys without values can often merge with next key during parsing. entries with non US-ASCII characters are not supported. entries with control characters are not supported.)

The common technique when using System Environment variables with Java programs is to use the shell specific techniques to obtain the values and inject them either on the command line, or into a ini file format for Jetty to then use.

Depending on your technique, these values would either show up as Jetty properties, or as Java System Properties.

Just created a project to demonstrate 4 ways to accomplish this at

https://github.com/jetty-project/jetty-external-config

External Configuration Properties with Jetty

Demonstration of how to configure simple properties that can be accessed
by Servlets within Jetty.

This demonstration shows 4 different ways to configure a property
at runtime, that can then be read by the Servlet running within
Jetty.

The props.war

This is a simple war file with a single HttpServlet and a WEB-INF/web.xml

[jetty-external-config]$ jar -tvf target/props.war 
     0 Mon Feb 23 09:02:14 MST 2015 META-INF/
   131 Mon Feb 23 09:02:14 MST 2015 META-INF/MANIFEST.MF
     0 Mon Feb 23 09:02:14 MST 2015 WEB-INF/
     0 Mon Feb 23 09:02:14 MST 2015 WEB-INF/classes/
     0 Mon Feb 23 09:02:14 MST 2015 WEB-INF/classes/org/
     0 Mon Feb 23 09:02:14 MST 2015 WEB-INF/classes/org/eclipse/
     0 Mon Feb 23 09:02:14 MST 2015 WEB-INF/classes/org/eclipse/demo/
  2188 Mon Feb 23 09:02:12 MST 2015 WEB-INF/classes/org/eclipse/demo/PropsServlet.class
   572 Mon Feb 23 08:45:22 MST 2015 WEB-INF/web.xml

See PropsServlet.java for details of behavior.

Just compile the top level and the war file will be built and placed in all of the demo jetty.base locations for this project.

Example #1: Basic Command Line

The /base-command-line project contains a simple start.ini which starts jetty on port 9090, and deploys the webapp. no extra configuration is done by the on-disk configuration.

If you start it up like so ...

[base-command-line]$ java -jar /path/to/jetty-distribution-9.2.7.v20150116/start.jar
2015-02-23 09:15:46.088:INFO::main: Logging initialized @290ms
2015-02-23 09:15:46.222:INFO:oejs.Server:main: jetty-9.2.7.v20150116
2015-02-23 09:15:46.235:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/home/joakim/code/stackoverflow/jetty-external-config/base-command-line/webapps/] at interval 1
2015-02-23 09:15:46.325:INFO:oejw.StandardDescriptorProcessor:main: NO JSP Support for /props, did not find org.eclipse.jetty.jsp.JettyJspServlet
2015-02-23 09:15:46.343:INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppContext@6e7f61a3{/props,file:/tmp/jetty-0.0.0.0-9090-props.war-_props-any-27537844855769703.dir/webapp/,AVAILABLE}{/props.war}
2015-02-23 09:15:46.353:INFO:oejs.ServerConnector:main: Started ServerConnector@67cd35c5{HTTP/1.1}{0.0.0.0:9090}
2015-02-23 09:15:46.353:INFO:oejs.Server:main: Started @555ms

you'll see that it has started up and deployed to the /props context path.

From here you can test for properties in the servlet via tooling like wget or curl.

Example:

$ curl http://localhost:9090/props/props

[java.runtime.name] = Java(TM) SE Runtime Environment
[sun.boot.library.path] = /home/joakim/java/jvm/jdk-7u75-x64/jre/lib/amd64
[java.vm.version] = 24.75-b04
[java.vm.vendor] = Oracle Corporation
[java.vendor.url] = http://java.oracle.com/
...
[file.separator] = /
[java.vendor.url.bug] = http://bugreport.sun.com/bugreport/
[sun.io.unicode.encoding] = UnicodeLittle
[sun.cpu.endian] = little
[sun.desktop] = gnome
[sun.cpu.isalist] = 

You can even request a specific property ..

$ curl http://localhost:9090/props/props/user.timezone
[user.timezone] = America/Phoenix

Lets stop the server and run it with a system property of our choice.

Notice the -Dfoo=bar ?

[base-command-line]$ java -Dfoo=bar -jar /path/to/jetty-distribution-9.2.7.v20150116/start.jar
2015-02-23 09:15:46.088:INFO::main: Logging initialized @290ms
2015-02-23 09:15:46.222:INFO:oejs.Server:main: jetty-9.2.7.v20150116
2015-02-23 09:15:46.235:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/home/joakim/code/stackoverflow/jetty-external-config/base-command-line/webapps/] at interval 1
2015-02-23 09:15:46.325:INFO:oejw.StandardDescriptorProcessor:main: NO JSP Support for /props, did not find org.eclipse.jetty.jsp.JettyJspServlet
2015-02-23 09:15:46.343:INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppContext@6e7f61a3{/props,file:/tmp/jetty-0.0.0.0-9090-props.war-_props-any-27537844855769703.dir/webapp/,AVAILABLE}{/props.war}
2015-02-23 09:15:46.353:INFO:oejs.ServerConnector:main: Started ServerConnector@67cd35c5{HTTP/1.1}{0.0.0.0:9090}
2015-02-23 09:15:46.353:INFO:oejs.Server:main: Started @555ms

and look for it via curl ...

$ curl http://localhost:9090/props/props/foo
[foo] = bar

That demonstrates access of a property that was specified via the command line, now lets look at the other choices.

Example #2: Using start.ini

The /base-startini project contains a simple start.ini which starts jetty on port 9090, and deploys the webapp.

This start.ini also contains a foo.ish property.

Lets start up Jetty and try our props servlet access again ...

[base-startini]$ java -jar /path/to/jetty-distribution-9.2.7.v20150116/start.jar
2015-02-23 09:16:46.088:INFO::main: Logging initialized @290ms
2015-02-23 09:16:46.222:INFO:oejs.Server:main: jetty-9.2.7.v20150116

and request it via curl ...

$ curl http://localhost:9090/props/props/foo.ish
[foo.ish] = bar

Example #3: Using start.d optional ini

The /base-startd project contains a simple start.ini which starts jetty on port 9090, and deploys the webapp.

This start.ini also contains no extra properties that we are interested in.

The start.d/myconf.ini contains a property called foo.d that we are interested in.

Lets start up Jetty and try our props servlet access again ...

[base-startd]$ java -jar /path/to/jetty-distribution-9.2.7.v20150116/start.jar
2015-02-23 09:19:46.088:INFO::main: Logging initialized @290ms
2015-02-23 09:19:46.222:INFO:oejs.Server:main: jetty-9.2.7.v20150116

and request it via curl ...

$ curl http://localhost:9090/props/props/foo.d
[foo.d] = over here

Example #4: Using --include-jetty-dir optional config

The /base-jettyinclude project contains a new start.ini which starts jetty on port 9090, and deploys the webapp.

This start.ini also contains no extra properties that we are interested in.

However, the start.ini uses the --include-jetty-dir=../jettydir optional configuration that points to an entirely new interrim jetty.base configuration source.

The ../jettydir/start.ini contains a property called foo.jetty.dir that we are interested in.

Lets start up Jetty and try our props servlet access again ...

[base-jettyinclude]$ java -jar /path/to/jetty-distribution-9.2.7.v20150116/start.jar
2015-02-23 09:24:46.088:INFO::main: Logging initialized @290ms
2015-02-23 09:24:46.222:INFO:oejs.Server:main: jetty-9.2.7.v20150116

and request it via curl ...

$ curl http://localhost:9090/props/props/foo.jetty.dir
[foo.jetty.dir] = more of the same

---

Related Topics