So now a completely different type of error, I have a stateless enterprise bean class, that my service needs access to. The stateless class is defined in the common location (./common/Vendor/Project/Utilities/ArgHandler.php) of my app, and I'm declaring it like
use Vendor\Project\Utilities\ArgHandler;
class PingService extends AbstractProcessor
{
/**
* The Argument Handler for DB queries.
*
* @var Vendor\Project\Utilities\ArgHandler;
* @EnterpriseBean(name="ArgHandler")
*/
protected $argHandler;
protected function run($args = array ( ), $dates = array ( ))
{
$this->argHandler->default_handle($dates);
}
}
This is throwing an error with a backtrace to this point that reports:
[2019-05-17 19:30:40] - host.com (error): PHP Exception: exception 'Exception' with message 'Requested value php:global/combined-appserver/project/ArgHandler has not been bound to naming directory php:' in /opt/appserver/src/AppserverIo/Appserver/Naming/NamingDirectory.php:213
Stack trace:
#0 /opt/appserver/src/AppserverIo/Appserver/Application/Application.php(804): AppserverIo\Appserver\Naming\NamingDirectory->search('php:global/comb...', Array)
#1 /opt/appserver/src/AppserverIo/Appserver/PersistenceContainer/BeanManager.php(497): AppserverIo\Appserver\Application\Application->search('ArgHandler', Array)
#2 /opt/appserver/vendor/appserver-io/rmi/src/AppserverIo/RemoteMethodInvocation/LocalContextConnection.php(123): AppserverIo\Appserver\PersistenceContainer\BeanManager->invoke(Object(AppserverIo\RemoteMethodInvocation\RemoteMethodCall), Object(AppserverIo\Collections\ArrayList))
#3 /opt/appserver/vendor/appserver-io/rmi/src/AppserverIo/RemoteMethodInvocation/ContextSession.php(189): AppserverIo\RemoteMethodInvocation\LocalContextConnection->send(Object(AppserverIo\RemoteMethodInvocation\RemoteMethodCall))
#4 /opt/appserver/vendor/appserver-io/rmi/src/AppserverIo/RemoteMethodInvocation/RemoteProxy.php(134): AppserverIo\RemoteMethodInvocation\ContextSession->send(Object(AppserverIo\RemoteMethodInvocation\RemoteMethodCall))
#5 /opt/appserver/vendor/appserver-io/rmi/src/AppserverIo/RemoteMethodInvocation/RemoteProxy.php(121): AppserverIo\RemoteMethodInvocation\RemoteProxy->invoke(Object(AppserverIo\RemoteMethodInvocation\RemoteMethodCall), Object(AppserverIo\RemoteMethodInvocation\ContextSession))
#6 /opt/appserver/var/tmp/localhost/project/cache/Vendor_Project_Services_PingService.php(990): AppserverIo\RemoteMethodInvocation\RemoteProxy->call('default_handle', Array)
#7 /opt/appserver/var/tmp/localhost/project/cache/Vendor_Project_Services_PingService.php(990): AppserverIo\RemoteMethodInvocation\RemoteProxy->default_handle(Array)
#8 /opt/appserver/var/tmp/localhost/project/cache/Vendor_Project_Services_PingService.php(2065): Vendor\Project\Services\PingService->runDOPPELGAENGEROriginal(Array, Array)
...
I have a few ideas about this, but the first thing I'm going to try is moving it out of the common directory and into META-INF
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.
<?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:
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