META-INF/context.xml) if needed. Regard the URL rewriting have a look at our documentation. By default, we use the .do suffix to let the webserver identify if the request has to be handled by the webserver or the servlet engine. This can be configured in the <APPSERVER-ROOR>/etc/appserver/appserver.xml file. It should be no problem to add an additional suffix if needed. Beside this, you can define wildcards in the pattern, to do this use the * character. I'm not completely understand what you want to achieve, but the URL rewriting feature in combination with the wildcard pattern and the file suffix i think nearly everything should be possible.
This created my log file and I was able to happily log to it. So I wanted to do the same thing on the service side, specifically to seperate out soap logs from the rest of the logs so I added a soap logger to META-INF/context.xml. Now, I extend all my services from a copy of the Example App's AbstractProcessor class, and each service has an entry in META-INF/epd.xml for injecting the application interface .. I've used this application interface for system logging with $this->getInitialContext()->getSystemLogger()->info($text); and this worked fine, but to the system log. getInitialContext() is defined as: return $this->getApplication()->getInitialContext(); and getApplication() is defined as return $this->application; So I figured I could get to my configured 'soap' log with public function getSoapLogger() { return $this->getApplication()->getLogger('soap'); }
SO then my AbcService has $this->getSoapLogger()->info($soap_request);
However this generates the application error log entry
[2019-05-27 21:27:48] - host.com (error): PHP Fatal Error: Call to a member function info() on null in /opt/appserver/var/tmp/localhost/mno/cache/Provider_Project_Services_AbcService.php on line 231 []
Is there something I have to do to get the Service side Application to be aware of the Log files?
<?xml version="1.0"?>
<context xmlns="http://www.appserver.io/appserver" name="wssap" type="AppserverIo\Appserver\Application\Application">
<loggers>
<logger channelName="soap" name="Soap" type="\AppserverIo\Logger\Logger">
<handlers>
<handler type="\AppserverIo\Logger\Handlers\CustomFileHandler">
<formatter type="\AppserverIo\Logger\Formatters\StandardFormatter"/>
<params>
<param name="logFile" type="string">var/log/${webapp.name}-soap.log</param>
<param name="logLevel" type="string">info</param>
</params>
</handler>
</handlers>
</logger>
<logger channelName="servlet" name="servlet" type="\AppserverIo\Logger\Logger">
<handlers>
<handler type="\AppserverIo\Logger\Handlers\CustomFileHandler">
<formatter type="\AppserverIo\Logger\Formatters\StandardFormatter"/>
<params>
<param name="logFile" type="string">var/log/${webapp.name}-servlet.log</param>
<param name="logLevel" type="string">info</param>
</params>
</handler>
</handlers>
</logger>
</loggers>
</context>
Hello. At Alchemy Systems, we are looking for a message queuing/handling solution for our LAMPR-based applications. Appserver seems to fit our needs. Before we can introduce it into our stack, we need some additional information.
1) It sounds like Appserver does not run on PHP 7. I do see some references to PHP 7 in the code, but the threads here indicate that Appserver still required PHP 5.6. Is that correct?
2) We would like to find, if possible, some people to ask about the use of AppServer in high-volume production environments. Do any of you know of someone we can speak with?
3) Roughly how many users (companies) are using Appserver?
4) Is there a working example of using STOMP in an external application to post messages to the Appserver queues?
5) Is there a product roadmap?
6) When will the next release be?
I know this is a long list, but we do need to "sell" this idea to our architecture team before proceeding.
Thank you in advance for your help.
Hi @troy-rudolph,
I'm happy to see that you're interested in appserver.io. I'll answer your questions as follows:
- Yes, appserver.io only supports 5.6 actually (only the webserver itself should also run with PHP 7.2, last tested a year ago - https://hub.docker.com/r/appserver/webserver)
- We've some customers that run appserver.io in production like https://www.proffile.de/app/ or https://lab.report/app/#/account/login and both have some traffic but it's for sure not a high-volume production environment. Besides that, we're not really aware who is using appserver.io
- Not too much I think, although we've 10.000+ downloads on Github which doesn't mean anything
- No, we don't have a STOMP implementation, appserver.io comes with its own client implementation
- It's an Open Source project and we don't have a concrete roadmap. Actually, we're working on an internal project that is based on appserver.io and we plan to update it during the next year, but we don't have a concrete plan for that
- We release patch releases (actually only in form of Docker containers https://cloud.docker.com/u/appserver/repository/docker/appserver/dist) when we need an update for our own project, but within the next month there should also be updates on our Debian repositories as well as a Mac version (hopefully on Homebrew)
I think this is not what you want to hear, but I hope it gives you a brief impression of what you're dealing with ;)
@wagnert Indeed it works with PHP 7.4. But not for future versions of PHP because of the design as he said in his closing note issue: https://github.com/krakjoe/pthreads/issues/929#issue-410636734
However, he is the project owner of "parallel" and he said that this is the future replacement of pthreads. But personally for me it doesn't feel like a replacement, because many functions and features of the C pthreads API are missing here