You can make your own XML based configuration file and pass it along with the startup command:
java -jar start.jar /path/to/your-jetty-conf.xml.
Or those who are impatient, can just start up their instance with JVM arg settings passing in additional config. Also, it is possible to pass multiple configuration files to Jetty like configuration for HTTP and HTTPS, which is very useful for sharing snippets of config around a team.
Jetty’s XML based configuration is reflection-based. This means that all options in XML are actually corresponding to the Java class fields.
The biggest downside with this reflection-based (not so well documented) approach is that you need to understand how Jetty works under the covers and learn some of its internals. But hey – if you know your server well, you’ll never run into anomalies and won’t let the server to go out of control, right?
Reason: Able to create Jetty config but need to know Jetty internals, restarts often required, JVM args to override config is a nice feature, config is small.
Configuration in Tomcat is scattered across a number of files in the tomcat/conf directory but mainly resides in the server.xml file. This file can be modular to allow reuse and sharing across a development team. If you wanted to make a quick change, perhaps one that needed to be undone on next restart for a test, the best way is to add a system property when starting the JVM up as system properties override xml configuration.
The default configuration file is quite verbose, but this is actually mostly comment lines with ‘how-to’s. If you look at the active lines of xml, it’s actually a very small file.
Every server.xml file will require you to recycle the server as the configuration files are only checked by the core runtime during server startup.
Reason: Restarts required for config changes, scattered across multiple files, small file, easy to update, nice examples in comments.
The domain model is quite understandable and straightforward, so getting the setup of your dreams is easy. Here is how one would enable ssl connections on some arbitrary port. Locate the following part of the standalone/configuration/standalone.xml and add a connector element for “https” (bold line in the following table).
<subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false"> <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/> <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" enable-lookups="false" secure="true"></connector> <virtual-server name="default-host" enable-welcome-root="true"> <alias name="localhost"/> <alias name="example.com"/> </virtual-server> </subsystem>
This will enable connector, but if you also want to change the port where https binds, change “
[jboss-as-7.1.3.Final]$ bin/jboss-cli.sh --connect :reload This will do the thing for you without restarting the server.
Reason: Single file, 300 lines of xml :( Easy to config, well structured “subsystems” configuration, CLI reloads rather than restarts (manual process), several examples out-of-the-box.
The Liberty Profile has a single config file called server.xml. This file can include other config files if desired, so that the config can be logically separated or shared across a team. The default config file is tiny and the most interesting part is the feature manager:
<featureManager> <feature>jsp-2.2</feature> </featureManager>
This allows a user to construct their application server with the features they want to run, so initially, only the jsp-2.2 feature is enabled and running. Oh and by the way, you can change and update the server.xml and see the changes reflected in the running server. Neat!
Reason: Top class config model, dynamic updates mean there’s no need to restart, small file, simple config.
Everything that is needed to manage and maintain a GlassFish server is put into the asadmin utility. It is even possible to manage remote servers with it, which is cool!
One thing that asadmin does well at is scripting. Yeah – it is possible to write various asadmin scripts for managing your deployments and servers. These scripts can be executed inside asadmin as if you are running regular shell scripts.
For those who are still real fans of XML files, it is possible to configure everything in the domain.xml file too:
<network-listener port="8800" protocol="http-listener-1" transport="tcp" name="http-listener-1" thread-pool="http-thread-pool"></network-listener>
Some configuration changes require that you restart the DAS or GlassFish Server instances for the changes to take effect. Other changes are applied dynamically without requiring that the DAS or instances be restarted.
You can determine whether a domain or instance requires a restart from asadmin
asadmin> list-domains domain1 running, restart required to apply configuration changes Command list-domains executed successfully. asadmin> list-instances pmd-i1 pmd-i1 running; requires restart Command list-instances executed successfully
With dynamic configuration, changes take effect while the DAS or instance is running. The following configuration changes of developer interest do not require restart:
Adding or deleting add-on components
Adding or removing JDBC, JMS, and connector resources and pools (Exception: Some connection pool properties affect applications.)
Changing a system property that is not referenced by a JVM option or a port
Changing logging levels
Enabling and disabling resources and applications
Deploying, undeploying, and redeploying applications
Reason: Config is hard to get at, hard to read xml file, asadmin is the recommended approach, but it’s hard to get started with, need docs and experience.