HEY - ANOTHER MESSAGE. AND GUESS WHAT?

You were right. This website uses cookies, and we are obliged to inform you about:

1. technically necessary cookies, e.g. to make the grav cms work or to enable disqus
2. "evil" tracking cookies from Google Analytics (IPs anonymized, of course) sometimes combined with "Optimize A/B Testing", so that we can adapt our website to your needs

Approximately 9 months after we released appserver version 1.0.0 and 10.000+ downloads later, we're proud to announce the GA release of our next major point release of appserver. Version 1.1.0 "Iron Knight". This new version contains many bug fixes and a number of new and very interesting features.

The following list is a short overview of the great additions you will get with version 1.1.0 "Iron Knight":

Powered with PHP 5.6.x

Runlevels

Management Console (Terminal) - Currently Experimental

A CRON system

Multiple SSL Certificates possible per IP

A Proxy Module

An AutoIndex Module

A Headers Module

New Application Configuration

Complete Doctrine Integration (@PersistenceUnit annotation)

Lifecycle Callbacks for SFSB (@PostDetach, @PreAttach)

You can find a detailed overview of all the fixed bugs and closed issues on our Github Releases page.

Platform

Since appserver is a full stack platform, we define the PHP runtime version and the main daemon, which starts all other services, servers and finally the applications. The following updates and features are part of 1.1.0 "Iron Knight" platform.

PHP 5.6.x

Version 1.1.x is, as defined in issue #683, now based on PHP 5.6.x and contains many security patches and performance improvements, as well as a whole bunch of new PHP functionality.

Runlevels

The latest version of appserver.io also comes with a completely refactored and improved boostrap process, which is now separated in seven modes of operation, called Runlevels. Below is a list of the different levels:

ID

Name

Description

0

Shutdown

Stop the Application Server

1

Administration

Start the Base System

2

Daemon

Start the Core Daemons

3

Networking

Start the Containers

4

Secure

Secure the Application Server

5

Full

Initialize and Start the Applications

6

Restart

Restart the Application Server

When appserver.io is started, by invoking service appserver start on a Linux system's console, Runlevel 5 will be executed. But, prior to this initial server start, all previous Runlevels are actually synchronously executed, whereas

runlevel 4 secures the servers by switching to the configured group and user

runlevel 5 finally bootstraps and start's the deployed applications

This new boostrap process now uses events, which allows developers, who want to create their own startup functionality, to hook into the runlevel processes to execute their code within the required runlevel. These events can be easily configured through the etc/appserver/conf.d/bootstrap.xml file. Additionally, there are separate configuration files for the watcher daemon etc/appserver/conf.d/boostrap-watcher.xml and the setup command etc/appserver/conf.d/bootstrap-command.xml.

Management Console (Experimental)

You may be asking yourself, is it possible to switch between the runlevels? Yes, it is! With version 1.1.0, the OS specific init scripts only allowed you to start/stop or restart appserver.io. Now, the Management Console enables developers or admins to login to an instance and allows them to execute various commands, like switching between the runlevels.

This feature had been planned in issue #763 and specifies a Management Console that allows the execution of commands on an internal commandline.

The Management Console is currently experimental and in a pre-alpha stage. This means switching between the runlevels using the init command, along with the exit command, are the only functionality available currently with version 1.1.0. The Management Console supports different protocols, however only the Telnet based implementation is operational. We plan to integrate an SSH console in one of the future releases. We will also be extending the functionality. The list below shows a few examples of some of the up and coming commands, which will be made available over the Management Console:

su: Switching the user

top: Overview all threads with required memory and CPU time

status: Textual overview about the server status

service: Start and stop container, servers and applications

The Management Console can be configured through the main configuration file etc/appserver/appserver.xml. By default, the Telnet based implementation is activated

In the configuration above, the Management Console will listen to local port 9023. This can be deactivated or customized, as the Management Console is currently for testing purposes only.

CRON

The new CRON functionality can replace the regular system CRON. It allows admins to configure CRON jobs globally. The main advantage of the appserver CRON is to allow developers to deliver their CRON job configuration along with their appserver applications. The global CRON job configuration can be found and modified under etc/appserver/conf.d/cron.xml, whereas the application specific CRON configuration files will be located under META-INF/cron.xml.

Below is a simple example showing a CRON configuration, which writes the actual PHP version to the var/log/php_errors.log:

Webserver improvements

In addition to the improvements made to the general appserver platform, we've also invested a good bit of work to offer a fully featured HTTP 1.1 compliant webserver with appserver.

Multiple SSL Certificates per IP

Since PHP 5.6.x allows to bind Multiple SSL Certificates to a single IP, we've passed on this functionality to you. With version 1.1.x appserver.io, you can enable this feature through a simple configuration option. Simply add the following lines to a server configuration:

Proxy Module

The Proxy Module provides full proxy functionality by supporting user defined logic in upstream types, which can be used for implementing custom behavior (e. g. load-balancing, HTTP caching, etc.).

The proxy configuration consists of two parts. The first part is within the container configuration. As an example, if you want to proxy a local Apache instance, you have to configure the upstream server as follows:

The second part of the proxy configuration is found in the server configuration, which uses the configured upstream server. So, if your application has a folder test, and the requests should be handled by the Apache instance we configured before, you simply need to add a location with a file handler, which will forward the requests. Something like this:

Auto Index Module

The Auto Index Module, defined with issue 700, enables auto generation of directory index on server, virtual host level or location level. The configuration is pretty simple, as only one parameter needs to be set to true. If, for example, the auto index functionality has to be enabled for a complete server, simply set the parameter autoIndex in the etc/appserver/appserver.xml file to true. This is what it would look like:

Headers Module

The Headers Module allows admins and developers to append or override the response headers. This feature can be, as is the case with the configuration for most of the other modules, be done on server, virtual host or location level. To change the response header with the server signature, simply add the following lines to the server configuration:

For a more detailed description about the Headers Module configuration, please refer to our webserver documentation.

Application Server

Finally, we released some important enhancements for the application server itself. These new and important features have a major impact on how applications can be built and what configuration options are available.

Application Configuration

A frequently requested and helpful new option is the possibility to access nearly all of the server or virtual host configuration parameters within the application itself. This means applications can define their own servers and virtual hosts, as well as override existing ones. This feature is enabled by default, but can be deactivated with a simple flag in the main server configuration, e. g. for a production environment.

These new configuration options have to be declared in new XML files (containers.xml and cron.xml) and are located in the application’s META-INF directory.

To deliver a simple virtual host configuration with an application, the file containers.xml in the applications META-INF directory needs the following content

Doctrine Integration (@PersistenceUnit annotation)

Version 1.1.0 introduces a seamless Doctrine integration. The integration consists of three parts. The first part entails the Datasources, which describe the connection to a database. The second part entails the Persistence Units, which describe the Entity Manager and the Datasource to be used. The third part entails the Annotations used to inject the Entity Manager instance into the application's components.

As Datasources have already been available since version 1.0.0, there was no clear concept when and how to use it. In our example application we demonstrated one possible way to use a Datasource to instantiate a Doctrine Enitity Manager instance. Since version 1.1.0, Persistence Units can be configured to reference datasources. This allows us to declare a Persistence Unit in an XML file META-INF/persistence.xml. This can be used by DI, via the @PersistencUnit annotation, to let the container inject an Entity Manager instance into an application's components.

The short example below gives a brief introduction on how things will work. First, we define a Datasource describing a connection to a SQLite database, located in a file META-INF/test-ds.xml with the following lines:

The next step is to define the Persistence Unit. The file also has to be located under the application's META-INF directory and MUST have the name persistence.xml. This file could have the following content

The Persistence Unit references the Datasource with the value of the attribute name of the datasource node. These simple steps are all that is needed to build an Entity Manager instance and make it available within an application. In order to use the EM instance, e. g. in a Stateless Session Bean, a simple annotation is added to the bean, as shown below:

Lifecycle Callbacks for SFSB (@PostDetach, @PreAttach)

Last, but not least, we've added two new Lifecycle Callbacks for Stateful Session Beans, which enables a developer to execute code, before a Stateful Session Bean (SFSB) is re-attached to the Persistence Manager or after it is unloaded.

The Lifecycle Callbacks can be annotated with the @PostDetach and the @PreAttach annotations on one of the a SFSBs methods. These methods are useful, when a developer want to use non serializable resources in an SFSB, for example, a database connection.

Conclusion

We're proud of the work done to the newest version of appserver, "Iron Knight". It provides easy to use solutions for some of the most discussed problems of version 1.0.x. We will continue to be focused on giving developers the best tools available to build high performance and rock solid PHP web applications.

Since this blog post only gives a short introduction to the new features and because we know reading and understanding documentation isn't everyone's cup of tea, we've extended our example application with examples of all the new functionality described above. So, if you're looking for best practices or how to's, please have a look at the example application, which is also installed with our 1.1.0 Iron Knight release.

If you have any additional questions or feedback, feel free to contact us on our well frequented Gitter chat room. We'd love to hear from you!