Post startup actions?

[davidgiga1993]

I have a use case where I need to run a one-shot action after the http listener is app (aka the app has been fully started).
Is there a hook for this? The @Start does only happen before jetty responds to http requests

[raphaelbauer]

I think that @start is anyway not needed (and that we should remove it).
You should be always able to @Inject a class "after which" your class should be initialized.

class MyClass
  @Inject NinjaServletDispatcher; // <--- not sure if this the correct class to "inject". But at that stage the  NinjaServletDispatcher should be up and running which (I guess) means Jetty is up and running

  public MyClass() {
    // at this point Jetty should be up and running...
  }
}

I did not try it... But it would be great to know wether that approach'd work for you...

[jjlauer]

Doesn't conf.Ninja have a method you can plug into that means the app is 100% fully started?

…

On Fri, Feb 19, 2021 at 2:44 AM Raphael A. Bauer ***@***.***> wrote: I think that @start <https://github.com/start> is anyway not needed (and that we should remove it). You should be always able to @Inject <https://github.com/Inject> a class "after which" your class should be initialized. class MyClass @Inject NinjaServletDispatcher; // <--- not sure if this the correct class to "inject". But at that stage the NinjaServletDispatcher should be up and running which (I guess) means Jetty is up and running public MyClass() { // at this point Jetty should be up and running... } } I did not try it... But it would be great to know wether that approach'd work for you... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#705 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEPAAXE67WD6FAPDBZP243S7YJFJANCNFSM4X33QXSA> .

[davidgiga1993]

@raphaelbauer But where/when do I create the first instance of MyClass? Would I just register it as module in that case?
If I just add an Inject it won't do anything since no one is creating MyClass in the first place.

I also tried conf.Nina.onFrameworkStart but it's too early in the chain, the listener is not up at that point.

[zmeggyesi]

Sorry to hijack this discussion (and @raphaelbauer feel free to tell me to open a new issue), but could you elaborate on this:

I think that @start is anyway not needed (and that we should remove it).

I use the Start annotation to do post-launch configuration and schedule migrations if needed. This approach is because I'm running Ninja in Google App Engine, so the standard scheduler is not workable, because there might not be an instance running at the scheduled time. Effectively, my system needs to remain stateless across requests, so I do my configuration at startup time, keeping the time taken to a minimum.

[raphaelbauer]

I am running Ninja on the App Engine as well, and I am using ninja-db which does not use any @start annotation.

Example code is here: https://github.com/ninjaframework/ninja-db/blob/master/ninja-db-flyway/src/main/java/ninja/flyway/NinjaFlyway.java

Hikari of ninja-db, however, uses the @dispose method to shutdown the connections.

[zmeggyesi]

I must confess that I don't quite understand the example application...

Yes, I understand that you bind the migration handler as an eager singleton, and put the migration logic in the class constructor (though Guice best pratices state to keep your constructor small, fast, and side effect-free, even though it's a singleton). What I'm hung up on is the ninjaDatasourceConfigs object, what that is, where it's coming from (since it's not referenced in the module), how it interacts with Google Datastore (does it do that through Objectify, like Ninja Core does?).

The way I'm handling it now, with @start annotations, I have a few methods that take care of basic configuration, like setting ObjectMapper configs, calling home to monitoring, and loading an entity from the Datastore to check if there are migrations already running or if the current instance needs to launch them.

I'm kind of apprehensive that removing the lifecycle annotations would be a big hit for me, I think that's what I'm trying to say in too many words.

[raphaelbauer]

• NinjaDatasourceConfigs is coming from one of the other modules => https://github.com/ninjaframework/ninja-db/blob/master/ninja-db-core/src/main/java/ninja/jdbc/NinjaDatasourceConfig.java
• The app is not using the Google Datastore, but Google Cloud SQL (hence Flyway and Jdbi)

ObjectMapper config can be done in a similar way using eagerSingletons... You can easily "simulate" a start sequence by depending on other modules. The injector builds a graph and initializes the classes based on a defined sequence after all.

But to be honest - there are no plans right now to abandon @start. And if we'd do it there'd be a way to add them easily as a library. Ninja did not have many breaking changes in the past :) All good!

[raphaelbauer]

And - many thanks for your feedback. Always good to hear what people are using 👍

[zmeggyesi]

Thanks, that does put my mind at ease. I can take an additional library, but I'd rather not start using heavy constructors in the Guice modules to simulate startup actions.