Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Tim Wagner
    @wagnert
    It'll be very nice to have that feature but its quite a bit complicated to implement it :-( Ok, so what's the reason?
    jefkin
    @jefkin
    It's very much still in the idea stage, but there are several things we're doing to support our work that are done with standalone servers/services, that could probably all be migrated to live under the appserver.io, however, several of these are dependent on one another, and single service updates without impacting the others would be a pretty easy sell, whereas "oh and we have to restart all of our services at the same time" is not so easy.
    Tim Wagner
    @wagnert
    Hm, i understand that, but you've plans to let all those standalone services run as applications in one appserver.io instance? Maybe it'll be a good idea to start each in a separate appserver.io instance ...
    jefkin
    @jefkin
    Ah, well that would be fine too, however, the impression I got from the sys admin team was "one appserver.io to rule them all" ... :-/ not sure, but that may be a failure in understanding how to set up parallel appserver.io instances, would be nice if I could point them to the docs or a blog that showed how to get that done :)
    to extend that thought; service appserver restart is pretty monolithic :)
    Tim Wagner
    @wagnert
    There are several options, but depending on your requirements this can be the better one. We call it appserver-runner and it only starts one application. I'll extend the documentation the next days, so you'll get an better understanding what i'm talking about :-)
    jefkin
    @jefkin
    nice :) and thanks
    jefkin
    @jefkin
    and regarding the issue we were having, we have unambiguously identified the problem the run() function we were calling from the servlet side, ... on the service side was defined with a signature of public function run(&$args = array ( ), &$dates = array ( )) ... the '&' references killed it, removed them and got dial tone again. So we'll have to do a bit of data stuffing to pass the updated info we needed in $args and $date, into our return result. Lesson learned is you can't use reference arguments across the two sides of the equation :D
    jefkin
    @jefkin

    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
    {

    ... clipped out

     /**
      *  The Argument Handler for DB queries.
      *
      * @var Vendor\Project\Utilities\ArgHandler;
      * @EnterpriseBean(name="ArgHandler")
      */
     protected   $argHandler;

    ... clipped out

    protected function run($args   =   array ( ),  $dates  =   array ( ))
    {

    ... clipped out

        $this->argHandler->default_handle($dates);

    ... clipped out

    }

    ... clipped out

    }

    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

    jefkin
    @jefkin
    that seemed to solve the hassle, I imagine I have to do something to tell appserver.io to look in the common subdirectory instead of META-INF.
    Tim Wagner
    @wagnert
    Hi, i‘ll have a look at it tomorrow 🙂
    jefkin
    @jefkin
    If I have an application 'project' then it's easy to make all servlets respond to queries at 127.0.0.1:9080/project/something/other/stuff; I can easily change the port if needed, but what if I want servlets in project to respond to 127.0.0.1:9080/something/other/stuff; e.g. without the 'project' string appearing in the route, is that doable?
    jefkin
    @jefkin
    my point is I want another parallel servlet in project to respond to 127.0.0.1:9080/that-thing/other/stuff, and a third, etc up to 17 of these guys, built for another platform that respond to disparate urls on the old platform, that lack a unique 'project' element in the url. I mean I guess we could have 17 projects on the appserver.io, but that seems inefficient.
    jefkin
    @jefkin
    I suppose we could do some url rewriting to make that work?
    jefkin
    @jefkin
    also, while I'm on it, if I have 127.0.0.1:9080/project/something/other/stuff as a query, to make it work in appserver.io right now I'm adding '.do' on the end manually, so my Servlet has a route annotation like: @Route(name="StuffService", urlPattern={"/something/other/stuff.do"}) -- If I change it to @Route(name="StuffService", urlPattern={"/something/other/stuff"}) appserver.io fails to find the servlet, I read a doc that said something like "we use '.do' to signal a servlet" ... can we just pop an arbitrary pattern into the works some how and have it land on the servlet? I'm leary to try and mess with the redirects directly, without a firmer understanding of what I'm meddling with.
    jefkin
    @jefkin

    I did try adding a WEB-INF/web.xml with :

    <servlet-mapping>
        <servlet-name>helloWorld</servlet-name>
        <url-pattern>/happyday</url-pattern>
    </servlet-mapping>

    but that didn't work. I think the rewrite might be my only option, but I can't seem to find a good example to go by.

    Tim Wagner
    @wagnert
    @jefkin Sorry for my late answer, but i was really busy on weekend :-( Yes, Enterprise Beans have to be located in the META-INF directory in general, but this can be overwritten in configuration (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.
    jefkin
    @jefkin
    I think despite all my text here that I was confusing the matter, I sent an email with the actual problem and what I think might be a solution.
    Tim Wagner
    @wagnert
    Rewriting is the special topic of @wick-ed, so i'll discuss that tomorrow morning with him, hope that is o. k.?
    jefkin
    @jefkin
    sure thing, thanks
    Bernhard Wick
    @wick-ed
    Hi there @jefkin
    I had a look at your rewrites
    looks good to me
    jefkin
    @jefkin
    Oh, good news, I will try it out later today and let you know if something seems amiss :)
    Bernhard Wick
    @wick-ed
    I only see an issue with the order of the conditions?
    Is it ok to discuss it here?
    jefkin
    @jefkin
    sure
    but we could take it to private to prevent clutter, unless you think it's better here
    Bernhard Wick
    @wick-ed
    I assume the first condition will always match, and the second one will never apply
    lets make it private
    jefkin
    @jefkin
    I have a logger question, my app defined a few logger entries in META-INF/context.xml the first was a servlet logger, and my servlet has been able to use it with a dependency injected -> protected $application; and a simple access function like: return $this->application->getLogger('servlet');
    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?
    Tim Wagner
    @wagnert
    @jefkin Hm, did you register the soapLogger int the context.xml file? If yes, please post the XML with the registration here :-)
    jefkin
    @jefkin
    ok here:

    <?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>

    note that I just coppied the lines for servlet that work to soap, if there was something more I was supposed to add, it eluded me.
    Oh I do see a difference, the name tag in soap is name="Soap", so should i be trying to get the loger by the channelName? or the name?
    Tim Wagner
    @wagnert
    Did you test to set the name from uppercase Soap to soap as you use soap to load the logger :-D
    I think it's the name :-)
    jefkin
    @jefkin
    trying that now ;)
    Tim Wagner
    @wagnert
    Yea, keep us updated :-)
    jefkin
    @jefkin
    shweeet! that was the ticket.
    so we load by name="" so 'Soap' in this case
    Tim Wagner
    @wagnert
    Perfect, like to hear that :-)
    jefkin
    @jefkin
    nice
    jefkin
    @jefkin
    I see that app.io 1.1.4 is still PHP 5, is there a pathway to upgrading to PHP 7? My team found this link: appserver-io/webserver#202 which hints it's possible, but it would be a very big boon if we had a known path to follow for this.
    Tim Wagner
    @wagnert
    Yes, it's still PHP 5.6 and we actually have no concrete plan for upgrading to PHP 7 as Joe Watkins is actually working on a new extension called parallel and he recommends to use it in a recent blog post when thinking about multithreading and PHP. We'll evaluating it during the next weeks regarding appserver.io requirements and how we can use it for our purposes ... so it'll take a while for sure to upgrade it to PHP 7
    Troy Rudolph
    @troy-rudolph

    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.

    Tim Wagner
    @wagnert

    Hi @troy-rudolph,

    I'm happy to see that you're interested in appserver.io. I'll answer your questions as follows:

    1. 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)
    2. 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
    3. Not too much I think, although we've 10.000+ downloads on Github which doesn't mean anything
    4. No, we don't have a STOMP implementation, appserver.io comes with its own client implementation
    5. 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
    6. 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 ;)

    Troy Rudolph
    @troy-rudolph
    Do you guys have a list of things that must be done to make the server run on PHP 7? If so, I might be able to do some of it for you in my spare time. Thanks.
    Tim Wagner
    @wagnert
    The problem is, that we‘llneed a replacement for pthreads 🙁 We‘re thinking of pht or something like this. We need to evaluate functionality before we can start refactoring for sure. So your help will be appreciated very much 🙂