appserver-io / appserver Goto Github PK

The appserver MUST create a SSL certificate on first startup.

UAC:

• SSL MUST work on default port after first startup
• There SHOULD be a possibility to already provide a certificate

It would be helpful, to have a command line tool that enables a developer to start in a really minimal bootstrap that allows easy creation of all containers to execute a
PHP script like node.js for example.

To implement a simple ServletContainer (HttpServer) instance you can implement the following script:

$server = $this->createContainer('ServletContainer', function ($req, $res) {
    $res->addHeader('Status', 200);
    $res->addHeader('Content-Type': 'text/plain');
    $res->setContent('<p>Hello World</p>');
});

$server->listen(8586, '0.0.0.0');

after that someone can start the script directly from the commandline by typing

/opt/appserver/bin/node example.php

The script will automatically executed again if the file was edited, like the watch behavior compass has.
Optional: The users system default browser will be opened if the script starts a HttpServer Container.

Currently apps delivered with built packages are taken from their respective instances stored within the TechDivision_Runtime project and are therefor not up to date at times.
This has to change.

UAC:

• There MUST be an automatic mechanism to make appserver builds contain a current version of the included apps
• The version of the included app MUST be lockable as well so only a certain version gets included if this is wished

Would be nice to have an integration like node-webkit for that server as well:

https://github.com/rogerwang/node-webkit

Regards
Kay

By now HTTP digest authentication does only work within the ServletEngine. This authentication method should be usable within the WebServer as well.

UAC:

• HTTP digest authentication MUST be provided by the WebServer to the client
• The behavior MUST be configurable within the appserver.xml

The current configuration is very monolithic. That MUST be changed by refactoring its structure and usage.

Also see: DOMDocument:xinclude

UAC:

• Configuration MUST be splitable based on different components (e.g. containers or servers)
• Node structures SHOULD be represented by traits on PHP level to enhance reusability
• There COULD be a CLI based test command for configuration validation without appserver restart

Every application MUST have the possibility to configure its own context.
This context is unique to the application and MUST be independent from that of any other application.

UAC:

• All following configurations MUST be able to be made using XML
• These XML files CAN be placed outside of the application, but it COULD come as a default with the application itself
• Every application SHOULD be able to register additional autoloaders
• The application type MUST be configurable
• It MUST be possible to configure the application pool size
• This configuration CAN be acknowledged within every container

We SHOULD be able to use DHT to integrate cluster functionality to our DataGrind component.

• See LemCacheContainer.
• See http://en.wikipedia.org/wiki/Distributed_hash_table
• See https://github.com/fiorenzo-rutschmann/PHP-K-DHT

As a potential user I want the WebServer to be able to pick up the .htaccess configuration contained in an application I want to run.

UAC:

• The WebServer MUST be able to work with .htaccess files based on their sole existence within the WebServer document root
• Changes to these files MUST be reflected without a restart of the WebServer (or parent container)
• The related behavior MUST be compatible to the Apache webserver

I have installed indeyets/appserver-in-php and am exploring implementation.

I have fished around as to how appserver.io compares. I have not found any docs outlining installing on Ubuntu Server. Any suggestions?

Thank You

would also like to use it, also without installation, just by running it with the php binary ..

the documentation of usage is currently a bit ... to short 😄

Log files should be rotated like they are in numerous other services.

UAC:

• Log files MUST be rotated based on certain criteria
• These criteria MUST be configurable within the appserver configuration
• There MUST be a default configuration for this rotation criteria
• Non-active log files MUST be compressed in some way

By now Windows builds do not include the same feature set as *nix builds.

UAC:

• Windows builds MUST have the same grade of automation as other builds
• Builds MUST include Windows services for bundled daemons
• All dependencies MUST be satisfied in an automated way e.g. building PECL extensions (or download it if it is built within the extensions build process)

UAC:

• The latest appserver build MUST be installable using the brew install appserver command

I'm running appserver 0.6beta build 100
I have an application that works in apache and I am running it unmodified under appserver. To be fair I am running both apache and appserver on the same server, from the same directoryIndex
Under httpd the application works as normal.
Under appserver, after login I redirect to /controller/action but the user/authentication is not kept, so I get redirected back to /site/login
Where can I look to start debugging this?

The init scripts for the different daemons have slightly different names within different OS releases.
This naming has to be unified as proposed below:

• appserver: The main process which will start the appserver itself
• appserver-php5-fpm: php-fpm + appserver configuration. Our default FastCGI backend. Others might be added the same way
• appserver-watcher: A watchdog which monitors filesystem changes and manages appserver restarts

0.x releases point to an unstable state and your 1.0 version looks a bit random chosen, do you know that after 0.9 does come 0.10?

Also such things as cluster support mostly need some internal rewrite, means a few BC Breaks. Such a big changeset is better separated into a major release, so 2.0 would be a better releasepoint for this.

It should be possible for components to fire events which are picked up by listening components in an observer/observable way.

General thoughts:

• Components must be able to fire events
• Components must be able to listen to certain events
• There must be a transparent way to overview listening components

The appserver project currently lacks an usable admin backend.

UAC:

• The admin app MUST reflect the complete appserver configuration
• There MUST be functionality to control the appserver over the GUI as by using init system scripts

As an user of an rpm-using Linux distribution I would like to install the appserver using an online repository.

UAC:

• Installation MUST be possible using the yum install appserver command, provided the repository was added to the sources
• Any other rpm compatible package manager MUST be able to use the same repository
• The central documentation MUST featured an installation description
• Updating the repository sources MUST be done using the automatic CI process

It seems that the site app can not find the templates on windows

We need a basic timer service to execute certain bean methods at certain points in time. This SHOULD be loosely based on cron syntax.

UAC:

• Developers MUST be able to specify an execution time or period for certain bean methods
• This specification SHOULD be within the bean annotation
• This MUST be available to all stateful beans
• This MIGHT be available to other structures

UAC:

• A potential user MUST be able to use the appserver within every Docker compatible container infrastructure
• This container MUST be compatible to the Docker container interface
• Creating a Docker container SHOULD be part of the automatic CI process

It seems that other implementations of web servers like Apache have a modules to cache at least the static files they deliver.
See http://httpd.apache.org/docs/2.2/mod/mod_cache.html

Something like this should be implemented for the appserver as well.

UAC:

• There MUST be a module which speeds up the request-response cycle of static files
• This module MUST follow common module interfaces

after deplying the magento app via command line it could only be accessed by using http://127.0.0.1:8586/magento-x/index.php.

It should be possible to access magento app via
http://127.0.0.1:8586/magento-x/

By now the php-by-contract library is a dependency but is not used as a default solution.

UAC:

• PBC MUST at least be usable within all applications
• There MUST be other means of configuration than via config file
• PBC AutoLoader is the default appserver.io autoloader implementation

Yesterday I tried to configure the FirePHPHandler in appserver.xml
and is was not working. I think it would be wonderful if I could use many Monolog features out of the Box within my Application.

Do you plan to implemented this Feature in the near future?

By now the Mac OS X builds are not automated on CI level.

UAC:

• All Mac OS X related builds MUST be available using CI infrastructure
• Creating a Jenkins slave to integrate a build machine (virtual or physical) into the internal CI process

According to http://www.yiiframework.com/wiki/214/url-hide-index-php/ there are specific rules for Rewrite in Apache httpd.

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)\?*$ index.php/$1 [L,QSA]

I have opted for

<rewrites>
    <rewrite condition="-d{OR}-f{OR}-l" target="" flag="L" />
    <rewrite condition="^/([^/]+/)?(.*){AND}!index\.php" target="/index.php/$1" flag="L,QSA" />
</rewrites>

Could you please assist with the corresponding config in appserver.xml ?

Fresh install, trying to access http://127.0.0.1:9080/demo/ and got the following exception:

exception 'TechDivision\WebServer\Exceptions\ModuleException' with message 'Requested directory or filename '/opt/appserver/webapps/demo/' not found.' in /opt/appserver/app/code/vendor/techdivision/webserver/src/TechDivision/WebServer/Modules/CoreModule.php:243
Stack trace:
#0 /opt/appserver/app/code/vendor/techdivision/http/src/TechDivision/Http/HttpConnectionHandler.php(422): TechDivision\WebServer\Modules\CoreModule->process(Object(TechDivision\Http\HttpRequest), Object(TechDivision\Http\HttpResponse), 2)
#1 /opt/appserver/app/code/vendor/techdivision/http/src/TechDivision/Http/HttpConnectionHandler.php(362): TechDivision\Http\HttpConnectionHandler->processModules(2)
#2 /opt/appserver/app/code/vendor/techdivision/webserver/src/TechDivision/WebServer/Workers/ThreadWorker.php(194): TechDivision\Http\HttpConnectionHandler->handle(Object(TechDivision\WebServer\Sockets\StreamSocket), Object(TechDivision\WebServer\Workers\ThreadWorker))
#3 /opt/appserver/app/code/vendor/techdivision/webserver/src/TechDivision/WebServer/Workers/ThreadWorker.php(139): TechDivision\WebServer\Workers\ThreadWorker->work()
#4 [internal function]: TechDivision\WebServer\Workers\ThreadWorker->run()
#5 {main}

The system load of a thread, that looses the connection to a PHP-FPM because PHP-FPM has been restarted is 100 %.

This is reproducable with the following PHP script, we'll name it system-load.php:

<?php sleep(60);

Open a browser with URL http://127.0.0.1:9080/system-load.php and restart the PHP-FPM with:

$ /opt/appserver/sbin/phpfpmctl restart

The system load produced by one of the threads is 100 %.

It would be great to have a Behat based functional testing of appserver core functionality.
This can be implemented using a test webapp which reflects this functionality and can therefor be tested in a simple way.

UAC:

• There MUST be a complete Behat test suite for functionality the appserver might provide to a webapp
• There SHOULD be a specific testing app, otherwise the example app might be used
• These tests MUST be used in an automated manner, so builds will be tested against them

Hello,
I have open the example project into PhpStorm, but all the TechDivision namespaced files not found. Of course, I have to add it e.g. as external library, but where I can find it? What is the correct include path for a local IDE? Or which settings are the best to develop an application for the appserver?

Maybe we could collect some hints here or better in the wiki?

By now we have a monolithic build process. Therefore we have to separate functionality and operating system specific build files and properties.

UAC:

• The build process represented by the build.xml should be separated based on OS and other environmental dependencies
• Appserver specific configuration MUST be moved to techdivision/TechDivision_ApplicationServer repository and separated from techdivision/TechDivision_Runtime
• Builds MUST be provided in a nightly manner ... builds are invoked on changes of the RT
• There MUST be an automated long-time-testing environment ... moved to issue #194

Hi,

seems that it's currently quite hard for me to find a build that is working ...
With the latest package from the Debian repos I always get following message when trying to use my own persistance proxy class:

/etc/init.d/appserver: Zeile 28: 11523 Speicherzugriffsfehler  start-stop-daemon $START_OPTS

while getting a well looking RemoteProxyObject

TechDivision\PersistenceContainerClient\RemoteProxy Object
(
    [session:protected] => TechDivision\PersistenceContainerClient\ContextSession Object
        (
            [connection:protected] => TechDivision\PersistenceContainerClient\ContextConnection Object
                (
                    [transport:protected] => tcp
                    [address:protected] => 127.0.0.1
                    [port:protected] => 8585
                    [appName:protected] => myproject
                    [sessions:protected] => ArrayObject Object
                        (
                            [storage:ArrayObject:private] => Array
                                (
                                    [0] => TechDivision\PersistenceContainerClient\ContextSession Object
                                        (
                                            [connection:protected] => TechDivision\PersistenceContainerClient\ContextConnection Object
 *RECURSION*
                                            [sessionId:protected] => 53b6583c7c4de
                                        )

                                    [1] => TechDivision\PersistenceContainerClient\ContextSession Object
 *RECURSION*
                                )

                        )

                    [client:protected] => 
                    [parser:protected] => TechDivision\PersistenceContainerProtocol\RemoteMethodCallParser Object
                        (
                        )

                )

            [sessionId:protected] => 53b6583c7cfce
        )

    [className:protected] => n3rds\MyProject\Services\UserProcessor
)

After updating to the latest dev-master via composer it's not getting better:

TechDivision\PersistenceContainerClient\RemoteProxy Object
(
    [session:protected] => TechDivision\PersistenceContainerClient\ContextSession Object
        (
            [connection:protected] => 
            [sessionId:protected] => 53b65bf980111
        )

    [className:protected] => n3rds\MyProject\Services\UserProcessor
)

In the PHP error log:

PHP Fatal error:  Class 'TechDivision\Servlet\Http\Cookie' not found in /opt/appserver/app/code/vendor/techdivision/servletengine/src/TechDivision/ServletEngine/DefaultSessionSettings.php on line 85

After removing the missing Cookie class usage from the DefaultSessionSettings class:

Call to a member function send() on a non-object in /opt/appserver/app/code/vendor/techdivision/persistencecontainerclient/src/TechDivision/PersistenceContainerClient/ContextSession.php on line 108

what is understandable when looking at the RemoteProxy dump which contains no ContextConnection object.

I know it's a development / non stable build and there is no guarantee, but currently I don't know how to proceed with my project migration to the appserver.

Your help is really appreciated!

Thanks and regards,
Eddie

Please, use English as default language. It would be appreciated.

Please switch to a license that is GPL compatible.

AGPL 3.0+ should come close if you want to enforce copyleft in the cloud.

The automatic restart on app deployment does not work for Linux systems utilizing systemd (e.g.Fedora).
This is mainly caused by problems with the differentiation of Linux distributions in TechDivision\ApplicationServer\Scanner\DeploymentScanner.

Hello,

I know your project is in an early stage, though I was wondering if you thought about adding .phar support. Like on all the Java application, on which you could deploy a .war-file which is then extracted and all files are copied around and the application is setup to go.

TechDivision\ApplicationServer\InitialContext::setClassLoader expects the passed loader to be an instance of \TechDivision\ApplicationServer\SplClassLoader.
etc/appserver.xml located in techdivision/TechDivision_Runtime package suggests that it can be changed with a different classLoader element.
Introducing a class loader interface would be great or maybe build the possibility to add several classLoader elements into etc/appserver.xml and stack them.

When you use an ampersand (&) in a post parameter (even if url encoded) it gets cut off at the & character.

_Example:_
sender=&message=yadsasd%25C3%25B6asdasd%2526ycxyc%250A

/* @var \TechDivision\Servlet\Http\HttpServletRequest $req */
$parameterMap = $req->getParameterMap();
echo $parameterMap['message'];

Echoes yadsasdöasdasd

There has to be a way of using aspect oriented programming within any webapp without the use of a third party library.

UAC:

• Classes within webapps MUST be able to define basic pointcuts
• Basic AOP MUST work within a clean appserver installation

Tested in example app and admin app

This is a dummy epic

After a clean install the server fails.

==> appserver-errors.log <==
[2014-05-09 11:58:24] system.INFO: Server successfully started in basedirectory /opt/appserver [] {"file":"/opt/appserver/app/code/vendor/techdivision/appserver/src/TechDivision/ApplicationServer/Server.php","line":393,"class":"TechDivision\ApplicationServer\Server","function":"start"}

==> php_errors.log <==
[09-May-2014 11:58:25 Europe/Berlin] PHP Fatal error: Class 'TechDivision\PersistenceContainerClient\Context\Connection\Factory' not found in /opt/appserver/webapps/example/WEB-INF/classes/TechDivision/Example/Handlers/BaseHandler.php on line 89

Hi,
would it be possible to add the path info to the inspected servlet path?

Currently the loaded servlet class completely depends on the given *.do in the url, potential parameters are not evaluated. I'm wondering if the asterisk signs make even sense in the example web.xml

So I would like to propose to change
$servletPath = $servletRequest->getServletPath();
in
$servletPath = $servletRequest->getServletPath() . $servletRequest->getPathInfo();
in TechDivision\WebContainer\ServletLocator::locate() to enhance routing.

Best regards,
Eddie

Could you please shortly describe how the WebSocket implementation works in the example webapp? I found the event handler methods in the BaseHandler class, and already noticed the handler configuration in handler.xml. But I'm still missing the connection between the running WebSocket server configured in appserver.xml and the example app.

I'm currently trying to run a Symfony 2 application with integrated Ratchet WebSocket on the appserver. In this application I'm passing the instance implementing the MessageComponentInterface to the WsServer constructor, but I can't see how this is done in the example app.

Thanks in advance, your support is really appreciated!

Kind redgards,
Eddie

Integrate DI

There is an issue where the appserver process might hang during restart by init script.
This faulty behavior was observed on Mac OS X and an over-average number of applications.
The startup seems to hang before changing the user context.