Laravel-swoole: Reset Event Listeners

[aftabnaveed]

In my project, I have event listeners which subscribe to certain events in the application. Because service providers register only once during the application boot the dependencies in Listeners constructors gets injected at boot time. Is there a way to reset the Listeners and reattach it somehow on each request?

class MyEventListener
{
  public function __construct(Request $request)
  {
    //Some code
  }
}

The request injected in above listener is always empty.

I tried to reset the provider in swoole.http.providers but that too did not work.

Thanks

[lezhnev74]

I bet this is something we need to do upon new request received.
We need some examples of where and how to inject our re-initialization logic (just like this section in an alternative package).

[aftabnaveed]

I am going to try and register my events inside another listener which listens to $this->app['events']->fire('swoole.request'); Let's see what happens.

[albertcht]

Hi @aftabnaveed ,

All the listeners are registered when the application boots up and all the injections are injected based on the original app container, injected request will be empty for sure.

The simplest way to get newest request instance is by app('request') or request(). It's not recommended to reset event instance because all your listeners registered in other places will be lost unless you register them manually.

[albertcht]

Hi @lezhnev74 ,

Not sure what kind of re-initialization logic you need? You can simply reset your instances by setting instances and providers in swoole_http.php config file.

[albertcht]

Hi @aftabnaveed ,

Is this because you need to get the request and do some log stuff like what you described in #72 ? If yes, the swoole.request will be fired very early before setting the request to newest app container, so what I said above can't resolve your problem.

I will consider to fire a swoole.request event with processed illuminate request to make it easier.

[aftabnaveed]

Is this because you need to get the request and do some log stuff like what you described in #72 ?

@albertcht no I am not its something different that I need for caching. I am basically generating a unique cache identifier for my page based on the request.

I will consider to fire a swoole.request event with processed illuminate request to make it easier.

If you send a processed illuminate request object with swoole.request that would be awesome.

Coming back to the original issue when I checked the Illuminate\Events\EventServiceProvider it registers a singleton, in that case, it makes sense that the listeners are registered only once. I am thinking of a possibility of categorising the events:

1. Global events/listeners which registers during the boot time.
2. Local events which are valid only for request/response lifecycle.

For option 2 I may need to create a separate event instance in the container and then destroy it after the response has returned. What are your thoughts on this?

[albertcht]

Hi @aftabnaveed ,

For option 2 I may need to create a separate event instance in the container and then destroy it after the response has returned. What are your thoughts on this?

I think this is difficult to make it. Is there any reason you need to register the listeners in each request cycle if you can get correct request instance via app('request')?

[aftabnaveed]

I just wanted to keep my code clean, testable and not clutter my listeners by bounding it only to a specific object, in this case, the Request. The other reason is why have something in memory if it's not needed?

[albertcht]

Hi @aftabnaveed ,

I come up with a solution that can make specific events registered on every request. There's a function in Event Dispatcher called public function forget($event). So you can force some listeners cleared and register them again. But you need to reset the protected $container in event instance, and params injected to newly registered listeners will be correctly resolved with the sandbox app container.

[albertcht]

Hi @aftabnaveed ,

I found there's an event which will be triggered Illuminate\Foundation\Http\Events\RequestHandled($request, $response) after dispatching request in Http kernel, so it looks like you can listen to this event directly if you need the request.

[aftabnaveed]

@albertcht it would be nice to have two events fired one which already exists onRequest and the second after a request has been dispatched and swoole is about to return it to the browser. I need the 2nd event to do some cleanup after the request has been dispatched. Is it something you think worth it?

Thank you.

[albertcht]

Hi @aftabnaveed ,

What do you think if you do your cleanup before the request? Does it make any difference in your use case?